W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > July 2007

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

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 17 Jul 2007 16:24:34 +0200
To: w3c-xml-cg@w3.org
Cc: public-xmlsec-maintwg@w3.org
Message-ID: <20070717142434.GE31669@raktajino.does-not-exist.org>

(To XML CG subscribers: This message is cross-posted to a public

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

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.

We would welcome feed-back on this approach from other Working
Groups that might be concerned (XML Core comes to mind), and would
be happy to discuss this on one of the upcoming XML CG calls.

For background, see this analysis:


Thomas Roessler, W3C  <tlr@w3.org>
Received on Tuesday, 17 July 2007 14:24:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:40 UTC