RE: Interpretation of (preceding::foo)[1]

Michael Kay wrote:

> > If they are considered as expressions, then preceding::foo[1] is a
> > location path treated as an expression while (preceding::foo)[1] is
> > directly an expression consisting of the parenthesized expr
> > (preceding::foo) narrowed by the predicate[1], and the child axis
> > isn't applied, despite what the note says.
> >
> The spec is really trying to exercise your brain in this area, it says in
> 3.3 that "the predicate filters the node-set with respect to the child
> axis", purely as a device for ensuring that every predicate has an
> associated axis and therefore an associated direction. It's a peculiar way
> of saying that the nodes are filtered in document order, and has nothing to
> do with the nodes being children of any common parent.
>
> Took me a while to work out!

So the reference to the child axis is really a kind of dummy reference whose only
relevant property is the associated direction, right?  Would it be equivalent if the
text of 3.3 had said ``the Predicate filters the node-set with respect to the
following-sibling axis''?  That would replace a misleading reference by an utterly
mystifying one <s>, which might or might not be a change for the better.

If any of the spec-writers are listening, please hear the message that an explanatory
note here would be very helpful.  Even better would be to replace the reference to the
child axis by a straightforward statement that the proximity positions are calculated
using document order rather than reverse order no matter how the node-set itself is
obtained.

Congratulations on deciphering this particular rune, Michael!

Paul Abrahams



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list