Re: XPTr bare names and XPATH id()

"John Boyer" <jboyer@PureEdge.com> writes:

Let's back up and try again -- I feel like I've arrived late to a
party where everyone is already deep in a doom-and-gloom-laden
discussion about the awful consequences of something which hasn't
actually happened.  I think we're not actually very far from a
resolution, with your messages on another thread pointing the way, if
we reconceptualise a bit.

1) Nodesets.  Nodesets are introduced into the XPath data model to
represent the semantics of XPath expressions.  The intrinsic semantics 
of a node set is a _disjunction_.   The interpretation of a nodeset as 
the value of an XPath expression is:  "Each of the members of this set 
satisfies the expression".

This is _really_ important: the value of the XPath expression '//foo'
is the set of all element nodes in a document whose name is 'foo' --
each of them, independently, is an answer to the instruction "Find me
something be starting from the root and looking for a 'foo' element".
Similarly, the value of the XPath expression 'id(baz)' is the set of
all element nodes in a document whose declared-as-type-id attribute
has the value 'foo'.  Now XML validity constraints (which must be in
play or we wouldn't know which attributes are of type id) require that
at most one such element exists, so the nodeset is either empty or
singleton.

It would be seriously incompatible with this fundamental aspect of
XPath to include in result nodesets nodes which did _not_ satisfy the
expression.

2) Nodes as results.  XPath expressions have values, which are
nodesets.  XPointer uses XPath expressions to pick out one or more
points in XML documents.  This is made clear as early as the
introduction [1], which uses words such as 'locate', 'address',
'choice', 'reference', 'target', etc.  It is entirely up to
applications what semantics they attach to such locations: "The
structures located with XPointer can be used as link targets or for
any other application-specific purpose".

In particular, it is clearly open to applications to specify that the
location picked out by an XPointer, whether short-frag, explicit-id or
other XPointer, is used by DSig as the root of a document subtree.
XML Schema, XInclude and XPath itself take this approach, so there's
plenty of precedent.

3) What does an XPointer point to?  The XPath REC introduces a data
model to answer this question [2].  It is clear from this exposition,
in particular from the definition of 'string-value', that the document 
subtree rooted in a particular node is well-defined.

Net: XPointer is just fine for your purposes, all that is required is
to state that the DSig interpretation of an XPointer is as picking out
the entire document subtree rooted at the node identified by that
pointer.  You do _not_ need to do this by defining a further XPath
function such as your suggested 'subtree' -- indeed to do so what be
counterproductive, as that function flattens the tree and loses
information in doing so.

Hope this helps -- if not I suspect a 'phone call is the next step.

ht

[1] http://www.w3.org/TR/xptr#N598
[2] http://www.w3.org/TR/xpath#data-model
-- 
  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 Thursday, 8 June 2000 05:57:30 UTC