aaaarrrrgggh, another in a long line of embarassments with this xforms implementation. the template someone gave me originally had a default namespace, this was causing problems with output because OO was outputing a colon expecting a prefix, i.e. I was ending up with <:Invoice> as my document element (with namespaces and other stuff added of course) this was of course a bad problem so I made <Invoice to <in:Invoice.... but forgot that there was still a xmlns="..." in the XML instance that the xforms would be working with but not in my various forms, therefore it was an improper binding expression.
That said, why the <:Invoice>? Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- Fra: Bryan Rasmussen [mailto:[EMAIL PROTECTED] Sendt: 14. marts 2007 11:28 Til: [email protected] Emne: [xml-dev] Is there a bug with open office Xforms nodeset attribute on bind when instance is larger than average? Probably you're wondering why I ask, well I have the following in my Generated Xform: elements with attributes on them, specifically an element that when I run this stylesheet over the instance xml <?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:CommonAggregateCompon ents-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="/*/cac:InvoiceLine[1]/cbc:InvoicedQuantity/@unitCode"/> </xsl:template> <xsl:template match="@unitCode"> yes </xsl:template> </xsl:stylesheet> I get back the word yes. Note the relevant xpath is /*/cac:InvoiceLine[1]/cbc:InvoicedQuantity/@unitCode inside of my xforms/open office document I have the following A drawn control: <draw:control text:anchor-type="as-char" svg:y="0in" draw:z-index="7" draw:style-name="gr6" draw:text-style-name="P1" svg:width="0.3933in" svg:height="0.1969in" draw:control="control226"/> an open office Form element: <form:text form:name="[EMAIL PROTECTED]" form:control-implementation="ooo:com.sun.star.form.component.TextField" form:id="control226" form:convert-empty-to-null="true" xforms:bind="[EMAIL PROTECTED]"><form:properti es><form:property form:property-name="DefaultControl" office:value-type="string" office:string-value="com.sun.star.form.control.TextField"/></form:properties> </form:text> and an Xforms binding: <xforms:bind id="[EMAIL PROTECTED]" nodeset="cac:InvoiceLine[1]/cbc:InvoicedQuantity/@unitCode" required="false()" type="xsd:string"/> As is common the document element of the XML instance has the context in the Xforms document. but when I run this document I get the following message: This is an invalid binding expression. Now, I am using as far as I can see, the same algorithm to generate attributes in other stylesheets. When I run the this over a small document the bindings to attributes are not a problem, but with this slightly larger document not. Since these are just copies of my generic stylesheets, and since furthermore reading the bindings it looks like everything is correctly declared, I fell like I must assume that the instance document is a little bit too big for OO to handle (the size seems to be OO's problem also, because I keep getting all the namespaces declared in their local scope, i.e. the cbc namespace is declared on every cbc element and this is only the case when I open up the XML to look at in OO. In other words the instance would be less verbose and easier to read in if it maintained the structure I give it, but I suppose that this is probably not the case for how OO maintains its internal memory) The XML instance is pretty small actually, the OO instance is 450 kb unzipped which is well within the limits I have observed in OO in the past. I have also tried the nodeset with //cac:InvoiceLine[1]/cbc:InvoicedQuantity/@unitCode and it did not work. I suppose it could be that position is incorrect, but all the other elements inside of cac:InvoiceLine[1] are not raising errors. If I set my parameters to generate all the attributes in the document, none of the attributes has a correct binding expression (supposedly) but if I generate an OO xform document with all attributes from a small input instance the attributes are no problem. 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]
