W3C home > Mailing lists > Public > www-xpath-comments@w3.org > January to March 2002

RE: Paper on symmetry of XPath axes

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Mon, 25 Feb 2002 17:29:25 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E6210602933DF4@daemsg02.software-ag.de>
To: Holger Meuss <meuss@cis.uni-muenchen.de>, www-xpath-comments@w3.org
> -----Original Message-----
> From: Holger Meuss [mailto:meuss@cis.uni-muenchen.de]
> Sent: 25 February 2002 14:15
> To: www-xpath-comments@w3.org
> Subject: RE: Paper on symmetry of XPath axes
> 
>  > Am I right in thinking that you don't address the problem 
> of positional
>  > predicates on a reverse axis, the typical example being
>  > preceding-sibling::h2[1]? ...
>  > 
> 
> Yes, in the current version we are not treating positions. We are
> currently formalizing our ideas on treating them. An expanded version
> shall also cover positional predicates. There are two closely related
> issues of interest concerning order and positions:
> 
> - The order of the result set returned by a location path. In XPath
> 1.0, this can be document order or reverse document. If we rewrite a
> location path into one containing no reverse location steps, it is
> possible that the new location path returns the result in a different
> order (namely in document order)....

Actually, XPath 1.0 node-sets are unordered. They are sets, not sequences.
Some operations on node-sets treat the nodes in a particular order
(especially XSLT operations; but also XPath operations, for example string()
gives the string-value of the node that is first in document order). But
this does not mean that the node-set itself is ordered. Node-sets are never
processed in reverse document order; the only time reverse document order is
relevant is for a positional predicate on a reverse axis: so
preceding-sibling[position()<=3] returns the *last 3* preceding siblings,
which are then typically processed in *forwards* document order.

This changes, of course, in XPath 2.0, where the result of an XPath
expression is always a sequence. In the case of a path expression, the
result will always be in document order.
> 
> - Positional predicates are sensitive to the order of a node set.

More accurately, they are sensitive to the direction of the axis that was
used with the predicate. The node-set is unordered.

> We
> are working on an expansion that shall also cover positional
> predicates. This is to a great extent straightforward, since the first
> node in a document-ordered node set is the last node in a
> reverse-ordered node set, etc. 

I look forward to seeing your solution. I think it will inevitably have the
property that you have to break serial processing to some extent: you can't
decide whether a particular <head> element will be selected by the
expression preceding-sibling::head[position()<=3] at the time you read the
<head> element, at best you have to keep a rolling buffer containing the
last three <head> elements encountered, and the final result is the contents
of this butter at the time the original context node is reached. 

> 
>  > I'm also uncertain about the extent of applicability of 
> these rewrite rules.
> 
> We think that even in an XSLT scenario it is of advantage to evaluate
> forward steps only. But surely, this needs profound tests and possibly
> even more rewritings (on the level of XSLT rather than XPath).
>  
Yes, I do appreciate that your rewrite rules are just one part of the story
and that other parts need to be develop to take advantage of them.

Thanks again,

Mike Kay
Received on Monday, 25 February 2002 11:42:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2007 16:05:54 GMT