Since XSL is a declarative language, as I understand it, the only way to simulate a loop (until XPath is modified to support ranges ala XQuery) is through recursion. Unfortunately, looping with recursion on Xalan only goes at most 2046 iterations until a surprising error occurs. I ran the following stylesheet with org.apache.xalan.xslt.Process with D11 (it shouldn't matter what the input xml is):
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="1.0"> <xsl:template match="/" name="test"> <xsl:param name="count" select="5"/> <xsl:message> Count is <xsl:value-of select="$count"/>. </xsl:message> <xsl:call-template name="test"> <xsl:with-param name="count" select="$count - 1"/> </xsl:call-template> </xsl:template> </xsl:stylesheet> and got the following error: ... (from Count = 0 to:) file:///home/pdavis/xsl/recursive.xsl; Line 7; Column 18; Count is -2044. file:///home/pdavis/xsl/recursive.xsl; Line 7; Column 18; Count is -2045. file:///home/pdavis/xsl/recursive.xsl; Line 7; Column 18; Count is -2046. (Location of error unknown)XSLT Error (javax.xml.transform.TransformerException): java.lang.ArrayIndexOutOfBoundsException This seems unrelated to the size of the Java method stack, which IIRC should scale to recursion up to 32xxx iterations. When I tried the same stylesheet with the jd.xslt processor, it ran up to 31411 iterations and then my Sun JDK 1.3.1 on Linux actually segfaulted. My question is, is any effort being expended to address this issue within the XSLT community? As surprisingly unessesary as looping/recursion is with XSLT, it seems that someone should have noticed the limitations, especially when performing string processing without using extensions. Also, is the ArrayIndexOutOfBoundsException actually an indicator of a bug within Xalan? Even if Xalan is limited by the size of the Java method stack, it should still be possible to go to approximately the same number of iterations as jd.xslt does. Also, would it be possible for Xalan to support infinite recursion without the Java stack limitation, say by implementing its own stack to trace template invokations? Thanks in advance for your thoughts on this problem. -- Furthermore, I believe bacon prevents hair loss. Peter Davis
