Hi Bryan,
I tried to narrow down on the issue you are experiencing. So far, I got
everything to work correctly. I'll explain what I did, and hopefully you
can spot where I did something differently from what you are trying...
I created an XML Forms document in Writer and set up a simple instance
without namespaces, because the XML instance editor in Writer doesn't
really allow for the use of namespaces. I created two form controls that
are each bound to a an element and to an attribute in the instance and I
created a submission and a button bound to that submission.
After that, I modified the content XML to use namespaces in the XForms
model (note the namespace decl on the model element). Here is what I
came up with:
<xforms:model id="Model 1" xmlns:inv="urn:my-invoice-namespace">
<xforms:instance id="Instance 1">
<inv:invoice>
<inv:line inv:attr="attribute-content">
element conetnt
</inv:line>
</inv:invoice>
</xforms:instance>
<xforms:bind id="Binding 1" nodeset="inv:line"/>
<xforms:bind id="Binding 2" nodeset="inv:line/@inv:attr"/>
<xforms:submission id="testfile" ref="/"
action="file:///d:/submission.xml"
method="put" indent="false" omit-xml-declaration="false"
standalone="false" replace="none"/>
</xforms:model>
I opened the new odt file in Writer and everything looked good. I
modified the control contents and submitted the form. The resulting XML
was this:
[d:\]type submission.xml
<?xml version="1.0"?>
<inv:invoice xmlns:inv="urn:my-invoice-namespace">
<inv:line inv:attr="attribute-content modified2">
element conetnt modified2
</inv:line>
</inv:invoice>
This look like what I would have expected, but it does not conform to
the behavior that you have been experiencing.
When I remove the inv:attr attribute from the inv:line element, Binding
2 will indeed become invalid. That is expected, since it does not point
to an existing node.
Maybe you can send me a sample document which exhibits the behavior that
you are describing...
Best rgrads,
Lars
bryan rasmussen wrote:
Hi Lars,
What I do is I generate a document without invoice namespace declared
on the line with the in prefix, thus:
<in:Invoice>
the in prefix and binding is declared further up in the document,
actually on xforms:model element.
This has two problems in my xform:
1. when I push submit and generate the document I get this:
<:Invoice
2. The bindings to attributes in my forms say "This is an invalid
binding" when I mouse over them. This is also weird because
a. the bindings to their elements work, really: ns1:somelement
binding works, but ns1:somelement/@someattribute does not work. This
problem also only seems to exist for attributes that have a drawn form
field, the attributes where I have generated bindings but without form
controls (because the attributes have actual content), the attributes
are output correctly. I do not think this has to do with the drawn
input fields however because when I switch to design mode and look at
the binding described in the dialog it is absolutely the correct
binding.
I can fix these problems manually however by opening up the open
office document with a zip utility extracting the content xml altering
the <in:Invoice> so that it has all the appropriate namespace
declarations on it and my problems are solved. Unfortunately I have to
find a way to do this in my earlier process, which, being XSL-T 1.0
based is difficult because the XSL-T processor has the right to put
the namespaces where it will as long as they are in their proper scope
and well formed. I think I may have a solution to this but nonetheless
it is at best a major irritation.
Cheers,
Bryan Rasmussen
How do I get the document element to always be the correct document
element given this situation. Do I have to make sure that the element
of my Xforms instance is
<in:Invoice xmlns:in="the namespace of invoice"
always? And do I have to make sure that all namespace declarations are
found on the
how can I do that with 100% certainty given that the generation of the
document and its xform is done via an XSL-T process which means that
the processor can determine placement of namespaces on output?
Is there some code I can write in a macro that will force the
placement of a namespace????
3. What form must my binding expression to an attribute take to work.
Is it actually the binding expression or can it be the nodeset
expression that is at fault. Why do these things not work with
attributes but work with elements?!?!?!?!?!
I mean really, why, when I have an expression
cac:PaymentMeans/cbc:InstructionNote will this bind correctly but
cac:PaymentMeans/cbc:InstructionNote/@anyAttribute (If there were
attributes on this element which there aren't just an example) won't
(note this seems to be only the case when the attribute is empty.) nor
will any variation of this I have tried so far work, it is as you said
obviously because the namespace does not seem to be in scope for the
process, but that can't be the reason either because the namespace
most definitely seems to be in process for other stuff. I know the
element binding works because if I write a value in the field it comes
out. even if the document element comes out as
<:Invoice
Why when I have a binding to an attribute with no drawn form field
(not that there is a matching oo form field for the xforms:bind
element) and the attribute has a value the attribute will be output
with its value?!?!
On 3/22/07, Lars Oppermann <[EMAIL PROTECTED]> wrote:
Well, it looks like the actual implementation is closer to what I just
described than I was actually aware of. In my test, a binding correctly
used the namespaces defined further up in the document. I tried
declaring the namespace at xforms:model and office:document and both
could be used correctly in a binding as expected...
<office:docuemnt xmlns:my="urn:myurn">
...
<xforms:model>
<xforms:instance>
<root>
<my:test>hello</my:test>
</root>
<xforms:instance>
<xforms:bind name="binding1" nodeset="/root/my:test"/>
</xforms:model>
The same also worked with attributes as in
...
<my:test my:attr="test">hello</my:test>
...
<xforms:bind name="binding1" nodeset="/root/my:test/@my:attr"/>
...
This suggests, that I haven't actually understood your scenario
correctly. Can you see where what you are trying to do isn't covered by
what I described here?
Bests,
Lars
Lars Oppermann wrote:
> I had a look at the code that creates the instance DOM during import
> (when the .odt file is read) and did some tests to see what happens to
> the namespaces.
>
> What I found is, that contrary to my earlier assumptions, namespaces
are
> indeed propagated to the xforms instances and become part of the DOM
> that is build for the data instances.
>
> The remaining problem is, that the bindings only register namespaces
> that are declared directly on the xforms:bind element with the xpath
> evaluation context.
> Changing the code so that the xpath evaluation context also honors any
> namespace declarations at the instance's root element is easy. However,
> it is not be a solution to all the problems because the namespace
> declaration in the DOM happens at the point where the namespace is
first
> used.
>
> Here is what happens, say we start with a document like this:
> <office:document xmlns:myns="urn:something" xmlns:office...>
> ...
> <xforms:model>
> <xforms:instance>
> <root>
> <myns:element>Hello World</mynselement>
> </root>
> <xforms:instance>
> <xforms:bind nodeset="/myns:element"/>
> ...
>
> In the current implementation, the myns namespace will be correctly
> passed to the DOM created for the xforms:instance's content. However,
> the binding will not work. The binding will only work if it is declared
> as follows:
> <xforms:bind nodeset="/myns:element" xmlns:myns="urn:something"/>
>
> The change that I described above, where namespace declarations at the
> instance DOM root can be registered for XPath evaluation doesn't help
> either. Because of the DOM handles namespace declarations
> (createElementNS())
>
> The instance will actually look like this:
>
> <root>
> <myns:element xmlns:myns="urn:something">Hello World</mynselement>
> </root>
>
> Hence, the namespace is not known at the root of the document
because it
> is not used there.
>
> Furthermore, it is not possible to register all the namespaces up to
the
> node referenced in the binding, because in order to evaluate the
> binding, you need to know about those namespaces first.
>
> Thus, the real fix seems to be, that namespaces that are declared up to
> the xforms:model element must be made available to the bindings. And
> also be exported in some useful way again when the document is saved.
>
> From what I could see so far (and this is now mostly a note to myself)
> that the strategy to implement this would be as such:
> - On import, when the XFormsModel is constructed, add to it a map of
all
> the namespaces declared so far say NamespacesFromDocument.
> - Whenever a binding needs to be evaluated, register the namespaces
> mappings from this map at the evaluation context.
> On export, when the namespaces are written to the document root
element,
> ask the XFormsModel for all namespaces it knows, so that they are
> written out.
>
> This would not maintain the exact location of namespace declarations
but
> that is not of relevance.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
