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

[Stephen D Green <stephengreenubl@gmail.com>]

Many thanks, Ken,

You have very well answered all my objections, especially with your statement:

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

There might be a little more that could be done in future versions of UBL
regarding the following, though

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

Like Roberto, I think, agreed, maybe a future BBIE could be defined to cover the
need for all the explicit information about an XPath expression such as bindings
and versions (and maybe modes such as 1.0 compatibility mode) so that any
future understanding of the document (e.g. by third parties such as accountants
and governmental auditors, etc) would be unambiguous, much as there is for
codelists - probably just needs a qualified datatype with suitable supplementary
components.

Anyway, many thanks for answering all of this  - so 'definitively' :-)

Best regards

Steve
----
Stephen D Green



On 13 May 2011 12:58, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> 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.> 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.
>
> 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.
>

>
>> (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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>