[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] XPath expressions in UBL / Signatures
At 2011-05-16 21:59 +0100, Florent Georges wrote: > I am not really a member of the UBL community, but I keep an >eye on this list and on ubl-comment as I am interested in keeping >on eye on UBL. Thanks, Florent! >On the above message, you say (I am not sure I >should respond here or rather over there, as you speak about a >"formal comment"): Formal comments are submitted using the "Send a comment" button on: http://www.oasis-open.org/committees/ubl/ Formal requests of the committee must be made through that mechanism in order to cover off IPR issues. But that comment list is not the place for discussions ... only submissions. > The XPath 2.0 specification is clear, there is a "default >element namespace" in the static context, which "if present, is >used for any unprefixed QName appearing in a position where an >element or type name is expected." (quoted from the spec at >http://www.w3.org/TR/xpath20/#context). Absolutely. When it comes time for addressing the design of this I was anticipating reviewing the static context to ensure I didn't miss anything. The default namespace association is but one aspect. > UBL, as a host language, can and should define how the default >element namespace is initialized in the static context. UBL doesn't express processing. It is but a serialization of a collection of business objects. Applications choose to do what they want with the business objects found in a UBL document. >The same >way it can define that the statically known namespaces in one >expression are the in-scope namespaces on the element holding >that one expression. > > This is for instance what XSLT 2.0 does (you know, a prefix >used in an XPath expression in an xsl:value-of/@select must be >in-scope on that xsl:value-of element). This is defined in >http://www.w3.org/TR/xslt20/#static-context (except that the >default namespace is defined explicitly with the attribute >@xpath-default-namespace). Well understood, Florent, thank you. But as a serialization of business objects, an application acting on a UBL document cannot (or may not; I don't want the committee to force this) distinguish the business object named <XPath> from other business objects. Thus, I feel strongly that the application need not rely on in-scope namespace declarations for the interpretation of the XPath address found in the business object. By the time the application sees the content of the business object, the XML syntax may be long gone. Therefore, I suggested that we augment the business objects in UBL to describe the default namespace URI association and all prefixed namespace URI associations as other business objects in UBL elements. Then, an application having decided that it needs to interpret the business object that contains an XPath address will have in other business objects everything it needs to use to interpret that XPath address, that being the set of namespace URI associations, the version of XPath, etc. And it can do so without having to revisit the XML syntax of the UBL document. Especially because that document syntax may not even be around anymore. It may have been completely processed in order to blindly create a programming language representation of the content. I say "blindly" because it can unmarshall the XML syntax into the programming language objects without awareness of the "specialness" of the element named <XPath> that has dependencies on in-scope namespaces that no other business object in UBL has. Of course this isn't an issue with the XSLT language, or XQuery language ... being based on the XDM in-scope namespaces are implicitly in the data. But this is not the case when the programming language is acting on a collection of unmarshalled XML at arm's length from the source XML syntax. Or was I being too cautious in my suggestion? . . . . . . . . . . Ken -- Contact us for world-wide XML consulting & instructor-led training Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]