RE: Paper on symmetry of XPath axes

Hi,

sorry for the late answer, I was really busy last week...

Kay, Michael writes:
 > 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]? I suspect these can be tackled by an extended
 > version of your algorithm, but it seems to me they aren't handled correctly
 > by the rewrite rules you currently define.
 > 

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). But this can be easily treated in
the host language using XPath, or in the XPath interpreter itself (if
the rules we propose are wired into an interpreter). Unfortunately
XPath 1.0 provides no syntactical construct to access the order of a
node set, therefore we can not cope with this (minor) problem in our
set of rules.

- Positional predicates are sensitive to the order of a node set. 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. The major problem we are confronted with is
again a syntactical one since XPath 1.0 lacks the means to explicitly
control the order of a node set. But, nonetheless, we are optimistic
to solve this inside XPath 1.0 itself by rewriting the positional
functions and their arguments. 

 > I'm also uncertain about the extent of applicability of these rewrite rules.
 > Certainly one can envisage a scenario in which it's valuable to be able to
 > evaluate a single XPath expression in a single forwards scan of a document.
 > I'm not sure how well this extrapolates to a scenario like XSLT, where there
 > are many XPath expressions, each one starting at nodes selected by previous
 > XPath evaluations.

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).
 
Yours,
Holger

Received on Monday, 25 February 2002 09:15:15 UTC