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

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

Please forgive me for coming late to this thread.  If I'm not 
mistaken, I think it may have gotten off on a tangent 
unnecessarily.  But perhaps it is just I'm missing the point being made.

At 2011-05-12 08:28 +0100, Stephen D Green wrote:
>One of the upshots of this was that I put forward a view and supported it
>and it didn't get completely shot down that XPath expressioons aren't yet
>fully portable across different applications/implementations.

Ummmmm ... if the context is well-enough defined, then assuming a 
subset such as, say, XPath 1.0, would be sufficient.

>The problem
>is mainly with XPath expressions used without any formally defined binding
>of the namespaces, i.e. if standalone and with an underspecified binding
>of a) default namespaces and b) any prefixes/namespaces. The XPath
>spec does not define how applications must cater for this as it expects this
>to be specified in other standards which make use of XPath (such as XSLT).

Fine.  But XSLT defines context well enough to manage expectations 
unambiguously across different implementations.

>Does this have ramifications for UBL and its use of XPath, particularly in
>the XML signatures / signature extensions to UBL?

I don't think so.  According to the digital signature specification, 
both XML-aware and non-XML aware applications are covered because 
canonicalization redundantly "attracts" redundant in-scope namespace 
declarations to the apex element of the signature information:

   http://www.w3.org/TR/xmldsig-core/#sec-NamespaceContext

(note such namespace attraction isn't relevant in an XML-aware 
processor but a convenience for non-XML-aware processors)

>Is it clear enough what
>an application has to do about any default namespace in such an expression
>and about prefix and namespace bindings?

Yes.  The specification explicitly calls out the XPath 1.0 
interpretation of prefixes, thus unprefixed elements in the XPath 
address are for elements in no namespace.  Full stop.

The bee in my bonnet is that the designers "threw in" a totally 
foreign function into the implicit function namespace for XPath, but 
that isn't relevant to this discussion.

>If not, I wonder if a comment is in order.

The rest of the thread is, I think, irrelevant since the XPath 
expressions in a UBL signature are totally unambiguous.

>Without anything specific enough about how to execute/evaluate
>an XPath expression, different applications may (validly) return different
>results for the same expression and the same target/context, it seems.

Not for XML Signatures in UBL documents.  UBL 2.1 PRD2 incorporates 
the contributions of the UBL Security SC and I took great pains to 
ensure implementations would unambiguously find everything they need 
in the UBL syntax to securely sign their documents.

>(I note too that UBL uses XPath expressions in elements besides signatures
>but these have been around since before 2.1.)

Indeed ... and I have yet to find a use-case for them, myself.  I'm 
guessing they were thrown in for "completeness".  However, like any 
other UBL element, it is up to two trading partners to agree on its 
use rather than follow dicta from the UBL committee.  Unlike the 
XPath found in a digital signature that must follow the digital 
signature specification ... the DigSig Transform element is an 
element that isn't a UBL business object.

>At the same time, it seems another upshot of the xml-dev discussion was
>the news that XPath 3.0 may go some way to solving portability issues by
>allowing fully qualified element names
>http://lists.xml.org/archives/xml-dev/201105/msg00065.html
>so maybe future UBL specs could recommend these once they become
>standard and adequately supported; but that day might be some way off.

Kewl ... but irrelevant, I think.  Have I missed something?

I think the rest of the thread is academic ... though not uninteresting.

I hope this helps.

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