RE: [xsl] preceding-sibling reversed ?

Subject: RE: [xsl] preceding-sibling reversed ?
From: TSchutzerWeissmann@xxxxxxxxxxxxxxxx
Date: Thu, 29 Aug 2002 11:49:37 +0100
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


Current Thread