This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: preceding-sibling reversed ?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]