[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] document function cached?

Subject: Re: [xsl] document function cached?
From: Louis-Dominique Dubeau <ldd@xxxxxxxxxxxx>
Date: Mon, 11 Feb 2013 10:46:31 -0500

On Mon, 2013-02-11 at 10:56 +0100, Michel Hendriksen wrote:
>  That is exactly what I find kinda weird. As I understand
> it[position()] is short for [position() = position()]. And [3] will be
> short for [position() = 3]. This would explain the behavior. So its
> actually the shorthand notation that makes things kinda
> weird/confusing.

There are two things working against [position()] being useful, one is
the meaning of having a predicate expression evaluating to an integer
(which means [position()] is equivalent to [position() = position()].
But even when this is taken into account there's another thing which
makes [position()] problematic. 

The second one, which Michael mentioned in his previous email is the
meaning of position(), generally speaking. Let's ignore the shorthand.
If someone wants "foo[position()]", then when the XSLT processor is
looking at the first element in the list of foo elements, position()
evaluates to 1, when the processor looks at the 2nd, position()
evaluates to 2, when it looks at the 3rd, position() evaluates to 3,
etc. So as the processor walks the list, the position which the user
asked changes with each element and happens to be exactly the position
of the element the processor is looking at. So when the processor looks
at the nth element, it sees the user requesting the nth element and thus
selects it, which makes "foo[position()]" equivalent to "foo".

And this is why when someone has "foo[position()]" in their code,
typically the problem is that they are thinking about some *other*
position than what position() means in the predicate above. This
position they want would be a "position outside the predicate", to use
Michael's language.


Current Thread