Re: xforms attributes binding in OO problem caused by serious bug in OO namespaces with Xf

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 <lars.oppermannsun.com> 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: dev-unsubscribexml.openoffice.org
>> For additional commands, e-mail: dev-helpxml.openoffice.org
>>
>>
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribexml.openoffice.org
> For additional commands, e-mail: dev-helpxml.openoffice.org
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribexml.openoffice.org
For additional commands, e-mail: dev-helpxml.openoffice.org

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 <lars.oppermannsun.com> 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 <lars.oppermannsun.com> 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: dev-unsubscribexml.openoffice.org
> >> For additional commands, e-mail: dev-helpxml.openoffice.org
> >>
> >>
> >
> >
------------------------------------------------------------
---------
> > To unsubscribe, e-mail: dev-unsubscribexml.openoffice.org
> > For additional commands, e-mail: dev-helpxml.openoffice.org
> >
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribexml.openoffice.org
> For additional commands, e-mail: dev-helpxml.openoffice.org
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribexml.openoffice.org
For additional commands, e-mail: dev-helpxml.openoffice.org