Hi Lars,
I have gotten it to work now. I think (haven't run through all the
tests to see, but the attributes etcs. work) by controlling the output
to the invoice element of the namespace.
I will attempt later to backtrack my code and generate the bad form
again if you are interested for testing.
Cheers,
Bryan Rasmussen
On 3/23/07, Lars Oppermann <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
