RE: XPTr bare names and XPATH id()

Hi Henry,

Yes, what is very much at issue is how to interpret a node in a node-set.
However, the assertion that a node in a node-set is meant to indicate "point
at everything you can access from it" is flawed on two counts:

1) every node in the entire document is accessible from any node in the
document.
2) your intent in making this statement is to have each node be
representative of the subtree for which it is the root.  This is a subset of
what is reachable from the node, but more importantly it defies the use of
the term 'set'.  The XPath spec is quite clear about the fact that a
node-set contains no duplicates.  If the intended meaning of 'node' is 'self
plus all descendants including namespaces and attributes', then it should be
impossible for me to produce a node-set containing an element and a child of
that element since the child is already implicitly included by virtue of
including its parent.  Current implementations permit a child to be a
node-set with its parent, substantiating the view of node-set as a 'set of
nodes', not a set of subtree roots.

Moreover, the view that xpointers 'point to things' rather than 'return
things' has little to do with the problem and serves only to cloud the
issue.  Nonetheless, the XPath specification says "Each function in the
function library is specified using a function prototype, which gives the
return type...", which substantiates the view that the id() function
*returns* a node-set. So, XPointer's claim that "XPointers don't _return_
anything, they _point_ to things" simply means that they return a node-set
that 'points to' or indicates certain nodes (locations in the case of
Xpointer).

However, the problem is and has always been about what do you do with the
'pointer'?  What does it mean to 'dereference' the pointer.  Applications of
XPath and XPointer are free to define what they intend to do with the output
result of the XPath or Xpointer expression. In the case of XPath, I have
interpreted the node-set as a set of nodes because that's what the W3C chose
to call it and because that's how XPath expression evaluators act.  So,
within XPath serialization and c14n, the act of dereferencing a node-set
produces the text of precisely and only those nodes that are actually in the
node-set.

There is no substantiation within XPath to interpret a node-set as a
subtree-root-set because a node and its child can appear in the node-set.

Finally, the emails from DeRose [1] and Clark [2] are in the dsig archive.

[1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0170.html
[2]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0166.html

They are about the interpretation of an expression like

id("E")/descendant-or-self::node()

which will only produce a node-set containing E and its descendant elements,
PIs, comments, and text, but will exclude the namespace and attribute nodes
of E and its descendant elements.  In your prior email [3], you used the
term 'exfoliated', by which one must assume you meant that you found no
evidence that id("E") would produce a result that was devoid of the
descendants, namespaces and attributes of E.  My reference those emails from
Clark and DeRose was intended to substantiate the point that indeed the
result of id("E") is 'exfoliated' and further that, by design, the namespace
and attribute nodes are omitted from descendant class axes (which also
implicitly substantiates the viewpoint that one should create a node-set
indicating a node AND its descendants when one INTENDS TO indicate or 'point
to' the node AND its descendants).

[3]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0224.html

John Boyer
Software Development Manager
PureEdge Solutions Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com

Received on Wednesday, 7 June 2000 12:34:42 UTC