Re: [ubl-dev] XPath expressions in UBL / Signatures

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2011-05-14 00:02 +0200, Roberto Cisternino wrote:
>DocumentReference is an official location where UBL uses XPath, but we
>found xpath could be used in other location into a UBL document instance.

Not in UBL 2.0 or UBL 2.1.  And what users do in extensions is up to them.

>I retain the version of xpath is a processing information not an xml
>parsing information or a business information so we could best use a
>processing instruction for providing such information without changing UBL
>models.

I disagree.  There are some XPath expressions whose end result of 
evaluation differs from XPath 1.0 to XPath 2.0 (which is why there 
was a major version and not a minor version; though I believe that 
won't be true from XPath 2.0 to XPath 3.0 as the version number is 
being harmonized amongst multiple specifications).  So, someone 
writing an XPath expression may be implicitly be assuming one version 
or another.

Therefore, if the committee is going to equip users with the ability 
to express version information (rather than have such simply being an 
agreement between trading partners), then I feel strongly the 
information has to be first-class and realized as an element.

I feel that a processing instruction is a second-class annotation in 
an XML document.  It cannot be constrained by a document model.  It 
cannot, therefore, be validated using a document model and is obliged 
to be processed by an application in order to be interpreted.

Also, in an editor doing a cut-and-paste of a fragment of UBL that 
includes the XPath elements is obvious and straightforward.  Where in 
the content would the processing instruction be placed?  It might not 
get copied if the processing instruction were not in amongst the 
elements (and even then an editor might have problems with the 
cutting and pasting).

And what would be the scope of such a processing instruction?  If 
there are two XPath elements in a UBL document and one of them had to 
be in XPath 1.0 and the other had to be in XPath 2.0, how would the 
processing instructions be used?

And, finally, it would introduce a new aspect of acting on a UBL 
document unlike all of the other information expressed in a UBL 
document.  Thinking of our users I would weigh that heavily and 
discourage introducing meaningful information in processing instructions.

But, no-one has yet raised in committee that we need to qualify XPath 
addresses.  Perhaps Steve or you or someone else will use the 
official comment list to identify a use-case that will trigger this 
discussion in committee for inclusion in an upcoming version of UBL.

Truthfully, I don't think we'll get a lot of uptake for XPath 
addresses in UBL documents until we get applications and languages 
with an eval()-like functionality.  As it stands in XSLT 2.0 and 
XQuery 1.0, one cannot dynamically evaluate a string as an XPath 
address ... it has to be hard coded.

I hope this is considered helpful.

. . . . . . . . . . . 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