Re: XPTr bare names and XPATH id()

For the benefit of the xmldsig mailing list who are joining this
thread in midstream, first some background:

I replied to a message from Joseph Reagle as follows:

> Joseph Reagle writes:
> > DanC/DanV: the document capturing concern about XPTr's bare name is [1].
> > Can you look at it quickly and tell me if the concern if unfounded. If
> > founded, we will fowrad to XML Linking comment list.
>> [1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0213.html
> 
>  The correspondence referred to there is one which addresses the
>  question of exactly what pattern is required to pick out a node list
>  which has one member for every node in a document.
> 
>  That's an entirely separate question from whether the single node
>  identified by #foo == #xpointer(id(foo)) is complete, or in some sense
>  exfoliated (stripped of its attributes and content).  I see nothing
>  either in the referenced correspondence or elsewhere in XPath/XPointer
>  to suggest the exfoliated view.
> 
>  ht

Joseph sent my reply to John Boyer, who replies as follows.

> From: "John Boyer" <jboyer@PureEdge.com>
>
> Hi Joseph,
> 
> Firstly, the correspondence cited was not restricted to having a node-set
> containing one node for each element of the document, as claimed by the
> author of the response below.  It had to do with the fact that the result of
> id() is indeed 'exfoliated' and, because of a syntactic limitation of XPath,
> one must create an expression which generates one node for every node in the
> document, then filter down to element E and its descendants (including
> namespace and attribute nodes).
> 
> More importantly, the author is also incorrect in his assertion that there
> is no evidence in XPath to support the assertion of an 'exfoliated' node-set
> result from the id() function.  My opinion is based on [1] as well as email
> received from James Clark and Steve DeRose (the editors of the XPath
> specification).
> 
> [1] http://www.w3.org/TR/xpath#function-id
> 
> The Xpath specification is quite clear about the meaning of the id function
> [1].  According to [1], the result of the id function is a node-set
> containing the element(s) matching the identifier(s) given by the function's
> input parameter.  A single identifier results in a node-set containing a
> single element.  The output node-set does not contain the element node plus
> its descendants plus all of the namespace and attribute nodes of these
> elements.
> 
> In conclusion, the problem remains one of how to think about and hence
> process a node-set.  If a node-set is a set of nodes, then the result of
> id("E") is insufficient to indicate the desire for a textual rendering of E
> and all of its content, namespace declarations and attributes.  Only by
> interpreting a node-set as something other than a set of nodes--
> specifically, a subtree-root-set-- does id("E") become sufficient.
> 
> John Boyer
> Software Development Manager
> PureEdge Solutions Inc. (formerly UWI.Com)
> Creating Binding E-Commerce
> jboyer@PureEdge.com

There is no debate that the referent of a barename XPointer == XPath
id() function is a nodeset consisting of a single element node (or
none).  It would be incoherent for it to be otherwise -- the nodeset
refered to by an expression consists of those nodes which satisfy the
expression, and e.g. the children of a node with id 'foo' cannot also
have id 'foo', so by definition cannot be part of the referent of id(foo).

What _is_ at issue is what the meaning of this single-element nodeset
is.  In the first instance, it means that element node is the referent
of the relevant XPointer.  The spec. is at pains to point out that
XPointers don't _return_ anything, they _point_ to things.  And in the
XPath data model, just like the Infoset, when you point at something,
you implicitly point at everything you can access from it.  The
language and the principle are no different from e.g. fragment
identifiers for text/html -- they point to the element with the
relevant 'name' attribute, but if you GET them you get the subtree
rooted there.  It's open to DSig to specify the DSig operational
semantics of XPointers similarly, as far as I can see.

I think for me to help further with this, I need to see the referenced
correspondence from James and Steve -- is it in the dsig archive?

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Wednesday, 7 June 2000 10:32:15 UTC