This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: Re: limiting preceding axis by ancestor
- From: Joerg Heinicke <joerg dot heinicke at gmx dot de>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Thu, 09 May 2002 02:02:00 +0200
- Subject: Re: [xsl] Re: Re: limiting preceding axis by ancestor
- References: <20020508074616.4134.qmail@web14508.mail.yahoo.com>
- Reply-to: xsl-list at lists dot mulberrytech dot com
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