Re: intent to squat on xpointer() -- normative reference issue (ACTION-66)

On 2007-07-17 11:05:21 -0400, Grosso, Paul wrote:

>> The existing XML-Signature Syntax and Processing recommendation
>> normatively (and intriguingly) references the 2001 CR for
>> XPointer, and RECOMMENDS use of xpointer(/) and
>> xpointer(id('...')) for certain use cases.

> The 2001 CR for XPointer failed.  It should not be referenced.
> The latest for XPointer at http://www.w3.org/TR/xptr-xpointer/ is
> just a working draft, so it should probably not be normatively
> referenced by a Recommendation.

Indeed.  Just to be clear, it is currently being referenced
normatively by a Recommendation for which we are in the process of
preparing a 2nd Edition.  We are trying to clean up the existing
mess as good as we can without changing conformance requirements.

>> The XML Security Specifications Maintenance WG intends to drop
>> the reference to the 2001 CR, and instead explicitly define
>> behavior for these two idioms of xpointer() scheme XPointers as
>> follows:

>>>  '#xpointer(/)' MUST be interpreted to identify the root node
>>>  [XPath] of the document that contains the URI attribute.
> 
> Why?  You don't need the #xpointer scheme to reference the root node.
> You don't need any scheme--just say a reference to an XML resource 
> identifies the root node.  If you wanted to refer to the top level
> element of an XML document, you could use the XPointer element() Scheme
> (http://www.w3.org/TR/xptr-element/) where #element(/1) identifies 
> the top level element.

That won't work, see below for the implicit semantics that full /
scheme-based XPointers have in Signature.

> > >  
> > >  '#xpointer(id('ID'))' MUST be interpreted to identify the element
> > >  node identified by '#element(ID)' [XPointer-Element] when
> > >  evaluated with respect to the document that contains the URI
> > >  attribute.
> > 
> 
> Why?  The XPointer Framework Rec at http://www.w3.org/TR/xptr-framework/

> provides the established Recommended way to access an element by ID.

> I do not believe it is a good precedent for one spec to try to
> redefine what another spec says, even if that other spec is stuck
> at WD stage.  I think you should give up on #xpointer as an
> XPointer scheme.  From what you say above, it looks like you
> don't need any new schemes.

Well, XML signature actually has special semantics for full
(scheme-based) vs. barename (shortname) xpointers.  

scheme-based xpointers are defined to keep comments, whereas comment
nodes are discarded for barenames and null URI references.  This is
relevant when the canonicalization algorithm that is used treats
comments as significant.  (Yes, the wisdom of these implicit
semantics is debatable; however, they have been in an existing and
implemented Rec for a long time, and I don't expect the WG will want
to change them.)

Therefore, we actually need a way to identify the root (not
document!) node with a full-name XPointer.

That said, there is a strong suspicion that existing implementations
actually follow the RECOMMENDED clause in xmldsig-core as far as
xpointer(/) and xpointer(id(ID)) are concerned.

>> This approach would not change material conformance
>> requirements for XML Signature implementations, but would
>> technically define conformance requirements for these
>> particular styles of XPointers in a Recommendation, even though
>> the xpointer() scheme is, strictly speaking, under review and
>> only defined in a Working Draft (though apparently abandoned).

>> The alternative would be to continue referencing a rather stale
>> Candidate Rec from a Recommendation, which appears even more
>> undesirable, or to change conformance requirements to use (or
>> define!) different XPointer idioms, which would appear to be
>> even more undesirable.

> But the xpointer scheme doesn't exist in any referenceable form, 
> and the capabilities you need do exist as W3C Recommendations, so
> that would seem the obvious solution to me.

See above: The failed XPointer Candidate Rec has been part of a
normative requirement in a successful Rec for the past five years.
That's where we're starting from.

Cheers,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Tuesday, 17 July 2007 15:19:43 UTC