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: Re: Re: limiting preceding axis by ancestor


Hello Dimitre,

I thought that this is true, *because* it's a reverse axis. I used [1] 
because I wanted the nearest ancestor. The question for me is "Why is 
the returned nodeset ancestor::foo upside down, so back in document 
order again?"

So, while thinking is rarely being, the [1] is not implicit, it's a 
must. Sorry for the confusion.

Joerg

Dimitre Novatchev schrieb:
> Joerg Heinicke <joerg dot heinicke at gmx dot de> wrote:
> 
> 
>>The [1] is implicit and not needed, because generate-id() on a 
>>nodeset returns the id of the first element in this nodeset. I wrote 
>>it for maybe better understanding.
>>
>><xsl:if test=". = preceding::bar[generate-id(ancestor::foo[1]) = 
>>generate-id(current()/ancestor::foo[1])]">
> 
> 
> This is one case where the established belief that 
> 
> generate-id(someXPathExpression) = generate-id(someXPathExpression[1])
> 
> is *not* true.
> 
> This is clearly not so, because "ancestor" is a reverse axis.
> 
> generate-id(ancestor::foo[1]) 
> 
> will be applied on the nearest ancesstor (the last in document order)
> 
> while
> 
> generate-id(ancestor::foo)
> 
> will be applied on the outermost ancestor (the first in document
> order).


 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]