RE: Simple subtree() function for Xpath transform and c14n

John Boyer wrote:
> Actually, no.  We do not have to go back to clean-URIs.  If the XPtr
> barename meaning does not change, then we only need to tweak our definition
> of what we intend to do with the result of the barename.

  The definition of the XPtr barename is equivalent to a single call
to the id() function with the value of the barename as explained in:
  http://www.w3.org/TR/xptr#bare-names

  This mean that the selection returns one node. However this node
is expected to be used in its document context for XPointer applications,
for example if the XPointer is used to design the anchor of a link,
we expect application to actually allow activation of the link for
the whole subtree under this node. XPointer - like XPath - offers 
an element selection mechanism, applications using XPointer may
actually use the result in different ways. Another example is 
the suggestion made to add XPointer based selection in the DOM API,
I would expect in that case to use the result of the bare name as 
the single element returned by the query. Hence I can see two use
case of XPointer, one using the subtree of the result
and the other one just using the node resulting from the query.
Both are acceptable because they don't change the meaning of an 
XPointer query, though they use it in different ways.

> The current dsig spec says that the text we generate for URI="#E" is
> equivalent to what the XPath transform would produce as the result of
> id("E").  This was under the incorrect assumption that id("E") meant the
> whole subtree rooted at E (i.e. the whole SignedInfo).  The addition of a
> subtree function means that you can say that URI="#E" is equivalent to what
> the XPath transform would produce as the result of subtree(id("E")).
> 
> Alternately, we could simply say that the result of the Xptr barename is an
> XPath node-set equivalent to calling id("E").

  yes that's the normative definition at
    http://www.w3.org/TR/xptr#bare-names

> We then use this node-set as
> an initial evaluation context to an implicit XPath transform with the
> expression "subtree()".

  I agree that subtree() would be a useful addition in a new version
of the XPath specification. I note that you posted this to the 
www-xpath-comments list:

http://lists.w3.org/Archives/Public/www-xpath-comments/2000AprJun/0020.html

  So this should be examined by the XSL and the Query Working Groups
when they work on the next version of XPath, in the meantime, the way
to express the full set of nodes of a subtree won't be very nice I agree
but XPath wasn't really designed to handle this. The addition of the
subtree() function seems a very clean way to augment XPath language 
to cover this use case.

  yours,

Daniel

-- 
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
 http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe

Received on Thursday, 8 June 2000 06:42:01 UTC