Re: exslt:node-set differs between Xalan-J and XSLTC

Julian Reschke <[email protected]> Thu, 21 Oct 2010 14:27:31 +0200
Newsgroups gmane.text.xml.xalan.java.user
Message-ID <[email protected]>
On 19.10.2010 23:17, Michael Ludwig wrote:
> Julian Reschke schrieb am 18.10.2010 um 16:58 (+0200):
>>
>> I see some strange behavior with Xalan-J (as opposed to other
>> engines, such as XSLTC or Saxon). It happens when an RTF is passed
>> as a template parameter, and is converted to a node-set (using
>> exslt:node-set).
>
>> <xsl:template match="/">
>>
>>    <xsl:variable name="t">
>>      <root>
>>        <x>1</x>
>>        <x>2</x>
>>        <x>3</x>
>>      </root>
>>    </xsl:variable>
>>
>>    <xsl:variable name="tns" select="exslt:node-set($t)/root/x"/>
>
> Should be three element nodes here.

Yes.

>> select="count($tns)"/></xsl:message>
>
>> <xsl:template name="foo">
>>    <xsl:param name="t"/>
>>    <xsl:param name="i"/>
>>    <xsl:variable name="tns" select="exslt:node-set($t)"/>
>
> Second template, declaring its own variable. Should be one element node.

Why? I would think it should be three, and XSLTC/Saxon/xsltproc agree on 
that.

>> select="count($tns)"/></xsl:message>
>>    <xsl:message>In template - $tns[2]:<xsl:value-of
>> select="$tns[2]"/></xsl:message>
>>
>>    <xsl:if test="$i&lt; count($tns)">
>
>> With Xalan-J (2.7.0), this happens only two times; in the first recursion,
>>
>>    count($tns)
>>
>> evaluates to 1 instead of 3.
>
> Here's the (stripped) output I'm getting using Xalan 2.7.1:
>
> Type of t: RTF
> Type of tns: node-set
> Name of tns: x
> Nodes in tns: 3
> $tns[2]: 2
> In template - i: 1
> In template - Type of t: node-set
> In template - Type of tns: unknown
> In template - Name of tns: x
> In template - Nodes in tns: 3
> In template - $tns[2]: 2
> In template - i: 2
> In template - Type of t: unknown
> In template - Type of tns: unknown
> In template - Name of tns: x
> In template - Nodes in tns: 1
> In template - $tns[2]:
>
> Don't know if this is right or wrong for your test case.

This is consistent with what I see in 2.7.0, and is, as far as I can 
tell, showing a bug.

Should I follow up somewhere else, or raise a bug in JIRA directly?

Best regards, Julian