Re: [xml-dev] xforms attributes binding in OO problem caused by serious bug in OO namespaces with Xforms implementation

[Lars Oppermann]

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.




bryan rasmussen wrote:
Okay, this only seems to manifest as a problem for me when binding to
attributes however. it is finding elements that are bound to, but when
I try to find attributes it needs the namespace binding, in what way
can I do my xpath query or binding so it will match to the correct
element even though the namespace is declared further up in the tree
than the instance?

Cheers,
Bryan Rasmussen
On 3/22/07, Lars Oppermann <[EMAIL PROTECTED]> wrote:
Hi Bryan,

I took some time to look at the namespace handling in the XForms code. I
cannot say that I have the full picture yet. However, it is clear that
there seem to be numerous problems.

First of all, the forms processor does not see the full document as a
DOM tree. Only the actual instances are treated as a DOM. Consequently,
any namespaces that are declared further up in the full document tree
are not available to the processor.

Furthermore the XML editing UI in OOo misses some aspects of namespace
handling. You can only specify namespace declarations on individual
bindings. In my opinion that is very inconvenient. I think it should be
possible to at least specify them in a way where they can be used in all
bindings. So they would for instance be declared on the xforms:model
element. Nevertheless, the fact that only the instance is treated as
generic XML makes the whole namespace handling very cumbersome.

This is not much, but I hope it helps a little bit...

Bests,
Lars

bryan rasmussen wrote:
> Hi,
>
> I am about ready to crack from too much Xforms in Open Office work I
> have to say.
>
> Why the does the  following give a response of 'This is an invalid
> binding expression':
>
>
> The drawn element:
>
> <draw:control draw:style-name="defaultCBCfield"
> draw:text-style-name="P4" svg:width="3.5cm" svg:height="0.498cm"
> text:anchor-type="paragraph"
> 
draw:control="[EMAIL PROTECTED]"></draw:control> 

>
>
> the sun forms element:
>
> <form:text 
form:name="[EMAIL PROTECTED]"
> form:control-implementation="ooo:com.sun.star.form.component.TextField"
> form:id="[EMAIL PROTECTED]"
> form:convert-empty-to-null="true"
> xforms:bind="[EMAIL PROTECTED]"
> xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datas:1.0">
>                         <form:properties>
>                             <form:property
> form:property-name="DefaultControl"
> office:value-type="string"
> 
office:string-value="com.sun.star.form.control.TextField"></form:property> 

>                         </form:properties>
>                     </form:text>
>
> the xforms binding:
>
> <xforms:bind id="[EMAIL PROTECTED]"
> 
nodeset="/in:Invoice/cac:PaymentMeans/cbc:InstructionID/@schemeAgencyID"
> required="false()" type="xsd:string"
> 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datas:1.0"></xforms:bind> 

>
>
> please note that all sorts of variations of this binding does not work:
>
> //cac:PaymentMeans/cbc:InstructionID/@schemeAgencyID
> and
> //cbc:InstructionID/@schemeAgencyID
> and
> //in:Invoice/cac:PaymentMeans/cbc:InstructionID/@schemeAgencyID
> don't work either.
>
> Is it because this element does not exist in the document?
>
> Well no, here is a fragment with it here:
> <cac:PaymentMeans><cbc:ID/><cbc:PaymentMeansCode
> 
listURI="urn:oioubl.codelist.paymentmeanscode-1.0"/><cbc:PaymentDueDate/><cbc:PaymentChannelCode 

>
> listURI="urn:oioubl:id:paymentchannelcode-1.0"/><cbc:InstructionID
> schemeAgencyID=""/>
>
> if I take the whole xml instance out and running it over this xslt:
>
> <?xml version='1.0' encoding='utf-8'?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> xmlns:ns="urn:schemas-microsoft-com:xslt"
> xmlns:fnx="http://rep.oio.dk/funx";
> xmlns:fnc="http://rep.oio.dk/funx/fnc";
> xmlns:att="http://rep.oio.dk/funx/att";
> xmlns:temp="http://tempgenerator";
> xmlns:l="http://tempgenerator/list";
> 
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" 

>
> 
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" 

>
> xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"
> xmlns:s="urn:oasis:names:tc:opendocument:xmlns:s:1.0"
> xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0"
> xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0"
> xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0"
> xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0"
> xmlns:xlink="http://www.w3.org/1999/xlink";
> xmlns:dc="http://purl.org/dc/elements/1.1/";
> xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0"
> xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datas:1.0"
> xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0"
> xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0"
> xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0"
> xmlns:math="http://www.w3.org/1998/Math/MathML";
> xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0"
> xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0"
> xmlns:ooo="http://openoffice.org/2004/office";
> xmlns:ooow="http://openoffice.org/2004/writer";
> xmlns:oooc="http://openoffice.org/2004/calc";
> xmlns:dom="http://www.w3.org/2001/xml-events";
> xmlns:xforms="http://www.w3.org/2002/xforms";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:docu="http://rep.oio.dk/oioxml/stylesheetdocumentation";
>  xmlns:template="http://rep.oio.dk/ubl/templatingsystem";
> version="1.0">
> <xsl:output method="text"/>
> <xsl:template match="/">
> <xsl:apply-templates
> 
select="/in:Invoice/cac:PaymentMeans/cbc:InstructionID/@schemeAgencyID"/>
> </xsl:template>
> <xsl:template match="@schemeAgencyID">
> yes
> </xsl:template>
> </xsl:stylesheet>
>
> the output I get is yes, so that means the binding does exist.
>
> now why is this happening???
>
> Well partially I suppose it has to do with namespace binding, for
> example I can make the binding to my attribute is correct if using the
> complete path /in:Invoice and so forth to the attribute but only if my
> namespace prefix in is declared in the context of the element of the
> element invoice. Thus it does not help at all if my namespace prefix
> is declared on the document element of my open office document. This
> however is a problem because I am generating the XML instance from an
> XSLT processor and despite putting the namespace declaration both
> places the processor can make its own mind up, in this case putting
> the namespace in the document element. Reasons why this might be
> problematic, well, not sure if moving it around or trying to take it
> out of the document element isn't going to lead to a situation where I
> am running around trying to chase bugs for the next week and I am
> supposed to deliver on the 26th, the other reason is that I am not
> sure if all the things I am doing in my program can be made to work
> with namespaces not output on the document element of my Open Office
> document.
>
>
> Cheers,
> Bryan Rasmussen
>
> ---------------------------------------------------------------------
> 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]