Re: [xsl] document function cached?

[Michel Hendriksen <michel.hendriksen@xxxxx>]

Interesting observation;-)

In my case the positions should have the same value, but I would be
using the wrong 'position'.
So indexing would work if I would pass to position the node which
position I would want to match against the position of the node within
the predicate,
like in position(current()).

Its the context switch that makes it weird/meaningless to use
position() as I did.

Michel

On Mon, Feb 11, 2013 at 4:46 PM, Louis-Dominique Dubeau
<ldd@xxxxxxxxxxxx> wrote:
> 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.
>
> Sincerely,
> Louis