This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: preceding-sibling reversed ?
- From: TSchutzerWeissmann at uk dot imshealth dot com
- To: xsl-list at lists dot mulberrytech dot com
- Date: Thu, 29 Aug 2002 11:49:37 +0100
- Subject: RE: [xsl] preceding-sibling reversed ?
- Reply-to: xsl-list at lists dot mulberrytech dot com
David,
[...]
> [@class = 'slide' and position() = 1]
>
> selects all (at most one) of those nodes that satisify the stated
> condition.
>
> however if you do it with two filters first
>
> preceding-sibling::div[@class = 'slide']
>
> now the resulting node set is renumbered (still in reverse
> order, as you
> are still in the same step) so now the [1] or equivalenetly
> [position()
> = 1] selcts the first of _these_ elements, ie the first
> element (looking
> back) with class slide.
I'm still a bit perplexed. If you evaluate a nodeset in a string context
then only the first
node in the nodeset is considered. That's why
following-sibling::div[@class = 'slide']/@id is the same as
following-sibling::div[@class = 'slide'][1]/@id.
On the other hand,
preceding-sibling::div[@class = 'slide']/@id is the same as
preceding-sibling::div[@class = 'slide'][last()]/@id.
So it seems as if the reversed axis doesn't come into play - of the entire
nodeset, only the
first is considered, but it's the first in *document order*. Why?
cheers,
Tom
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list