[
Lists Home |
Date Index |
Thread Index
]
Hi Eric,
> Finally a word to say that even though the preceding-sibling is a
> "reverse" axis, a copy-of or apply-templates on
> "preceding-sibling::*" would take the nodes by document order: the
> "reverse order" property only affects the position -as returned by
> the "position()" function- of the nodes, not their physical position
> in the node set...
>
> What I don't find obvious in the recs is why this "reverse order"
> property is lost when you assign the node set "preceding-sibling::*"
> to a variable, but all the XSLT processors seem to behave
> consistently in this respect.
Perhaps you'd find it helpful to compare:
foo/ancestor::*[1]
and:
(foo/ancestor::*)[1]
In the first, the predicate is on the *step* within the location path.
When a predicate is on a step, the order in which the nodes are
counted depends on the axis. You get the nearest ancestor element to
the foo element child (in other words, the element that you're on). I
guess that it works like this because it makes intuitive sense that
my "first ancestor" is my parent.
In the second, the predicate is on the *location path* as a whole, or
rather on the node-set that is the result of evaluating that location
path. There's no single axis associated with the location path -- the
child axis is used for the first step and the ancestor axis is used
for the second step, so that only sensible order that could be used is
document order. You get the first of the nodes in the node set
returned by the location path, in document order (in other words, the
document element).
When you assign "preceding-sibling::*" to a variable $x, you're
assigning the node-set result of evaluating the *location path*
"preceding-sibling::*" to the variable, not the step
"preceding-sibling::*". In other words,
$x[1]
is the same as:
(preceding-sibling::*)[1]
and *not*:
preceding-sibling::*[1]
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
