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

Re: [xsl] document function cached?


Subject: Re: [xsl] document function cached?
From: Michel Hendriksen <michel.hendriksen@xxxxx>
Date: Mon, 11 Feb 2013 10:56:40 +0100

 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.

Nice one by the way: saxon:discard-document()

Have it all sorted out now, up and running!

Thx all!

Michel

On Fri, Feb 8, 2013 at 10:49 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>
> On 08/02/2013 21:31, Liam R E Quin wrote:
>>
>> On Thu, 2013-02-07 at 18:17 +0100, Michel Hendriksen wrote:
>>>
>>> [...]<xsl:value-of
>>> select="$file-nbn-set/nbn-set/nbn[position()]
>>
>> The predicate is evaluated for each node in the list.
>> So, $file-nbn-set/nbn-set/nbn gives a list (for you) of 3 nodes.
>> For the first one, position() will be 1.
>> For the second one, position() will be 2.
>> For the third one, position() will be 3.
>> The predicate will be non-zero in each case, and hence taken to be true,
>> so all three results are taken.
>
> Almost but not quite. When the predicate is an integer, as it is in this
> case, it is compared with the value of position(). The result is true in
> each case not because the integer is non-zero, but because it is equal to
> the value of position().
>
> The mistake (and it's a common one) is in forgetting that position() inside
> the predicate is not the same thing as position() outside the predicate.
>
> Michael Kay
> Saxonica
>
>>
>> I don't know what you were expecting so I'm not sure why this is weird.
>>
>> Liam


Current Thread