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

RE: Paper on symmetry of XPath axes

From: Holger Meuss <meuss@cis.uni-muenchen.de>
Date: Tue, 26 Feb 2002 14:04:02 +0100 (CET)
Message-ID: <15483.34754.255107.273752@loihi.cis.uni-muenchen.de>
To: "Kay, Michael" <Michael.Kay@softwareag.com>
Cc: Holger Meuss <meuss@cis.uni-muenchen.de>, www-xpath-comments@w3.org

Kay, Michael writes:
 > 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. 

In fact there are two levels: The syntactic and the processing
level. On a syntactic level it is easy to see that e.g.


is equivalent to


How this is evaluated is not really our cup of tea, but you are right,
one needs a rolling buffer. This may result in a little computational
overhead compared to the evaluation of the original qualifier.  But,
consider the location path


which can be rewritten to


Here, the situation is exactly vice versa, because the second
qualifier [position()<=3] can be evaluated without a rolling buffer
(in contrast to the first qualifier [position()>last()-3]). It seems
to me that the need for a rolling buffer is not raised by the way our
rewritten paths look like.

But the integration of positional functions still needs some
considerations: Our algorithm exploits for one of the two sets of
rules the fact that qualifiers commutate,
i.e. p[q1][q2]=p[q2][q1]. This is only true if the qualifiers do not
contain positional functions. But for the other set of rules (called
"general equivalences") there is no problem. Consider


This can be rewritten to:


Received on Tuesday, 26 February 2002 08:04:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:42 UTC