OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[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]