<xsl:sort select="..." xmlns:xs=http://www.w3.o

[rrliu]

In Xalan <xsl:sort select="..." xmlns:xs=http://www.w3.org/1999/XSL/> seems to cause a NullPointerException.

In a template being called by name I have this:

<xsl:template name="makeSortedChoices">
...
<xsl:variable name="choices">
<choices xmlns="">
<xsl:for-each select="...">
<choice>
<originalvalue><xsl:value-of select="..."/><originalvalue>
<returnvalue>...</returnvalue>
<sortvalue>...</sortvalue>
<name>...</name>
<namelang>....</namelang>
</choice>
</for-each>
</choices>
</xsl:variable>
<choices xmlns="">
<xsl:for-each select="com:node-set($choices)/choices/choice>
<xsl:sort select="sortvalue" lang="{$sortLang}" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"/>
<choice xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<originalvalue><xsl:value-of select="originalvalue"/></originalvalue>
<returnvalue>...</returnvalue>
<sortvalue>...</sortvalue>
<name>...</name>
<namelang>...</namelang>
<index><xsl:value-of select="position() - 1"/></index>
</choice>
</xsl:for-each>
</choices>
</xsl:template>

I realize that associating the xsl: prefix with the XSL namespace for the elements inside the xsl:for-each is superfluous; however those elements are really "included" in the template using an unparsed entity. I seem to recall at least one parser which needed the namespaces to be defined in the entity.

Xalan throws a NPE when creating the transformer for this template. If I remove the namespace associate from the xsl:sort, however, then the NPE disappears, even though I retain it on the other elements.

Question: Is this a bug in Xalan, or is there some logical explanation? In Saxon retaining the namespace associations is not a problem.

Regards,
Richard

[rrliu]

Sorry for the unindented code snippet. I'll have to get used to using the Code tags.

[sorin_ristache]

Hello,

It is a bug in Xalan. Binding a prefix to a namespace URI when the same binding is already in scope is allowed. I reported the bug to the Xalan project. The NullPointerException can be obtained by validating the following stylesheet with Xalan:

Code: Select all

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

 <xsl:template match="/">

   <xsl:for-each select="*" >

     <xsl:sort select="a" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"/>

   </xsl:for-each>

 </xsl:template>

</xsl:stylesheet>

Removing the second binding of the xsl prefix is a workaround for the NullPointerException.

I realize that associating the xsl: prefix with the XSL namespace for the elements inside the xsl:for-each is superfluous; however those elements are really "included" in the template using an unparsed entity.

You should do the transformation with Saxon. If you must use Xalan then you have to edit the included unparsed entity and remove the duplicated namespace prefix binding as it is not necessary. The stylesheet is valid without it.

Regards,
Sorin

[rrliu]

Sorin,

Thanks for the confirmation that this is a Xalan bug. I believe I originally added the namespace bindings to the unparsed entities when I was developing with xmlspy and MSXML. Since the environment for which I'm now modifying those templates in Xalan, I use Saxon for day-to-day development and test regularly with Xalan.

Regards,
Richard

[sorin_ristache]

Hello Richard,

Yesterday (July 12) it was suggested in a comment to the Xalan bug for the NullPointerException to move the namespace declaration from the xsl:sort element to the parent element of the xsl:sort element as a workaround until the bug is fixed in Xalan.

Regards,
Sorin

[rrliu]

Hello Sorin,

I actually don't have the option to put the namespace binding in the parent element of the xsl:sort, because the xsl:sort and another sibling element are actually in an entity, and their parent is in an XSLT stylesheet where the xsl: namespace prefix is already defined. The reason for putting the definition in the entity as well was, if I recall correctly, that MSXML was making one pass through the XSLT, instead of first resolving the entities, then parsing the XSLT. At any rate, that behavior would seem to be non-standard, and the only reason for using MSXML was XML Spy, which I no longer use – not only because it doesn't run on OS X

Regards,
Richard