On 03/12/2025 17:07, Mukul Gandhi wrote:
Thanks for reporting this issue.
The fix for this has been committed to Xalan-J's xslt 3.0 development branch.
One more issue, I can access the property "number" with the lookup
operator ?number but trying to access the property "next" to call it
fails "?next()".
So with more context, the following works fine:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:mf="http://example.com/mf";
exclude-result-prefixes="#all"
expand-text="yes">
<xsl:function name="mf:random-number-sequence" as="xs:double*">
<xsl:param name="n" as="xs:integer"/>
<xsl:iterate select="1 to $n">
<xsl:param name="rng"
select="random-number-generator(current-dateTime())"/>
<xsl:sequence select="$rng?number"/>
<xsl:next-iteration>
<xsl:with-param name="rng" select="$rng('next')()"/>
</xsl:next-iteration>
</xsl:iterate>
</xsl:function>
<xsl:template match="/*">
<xsl:copy>{mf:random-number-sequence(10)}</xsl:copy>
</xsl:template>
</xsl:stylesheet>
But this fails with Xalan (error fatalError: Could not find function:
{http://www.w3.org/2005/xpath-functions}next()):
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:mf="http://example.com/mf";
exclude-result-prefixes="#all"
expand-text="yes">
<xsl:function name="mf:random-number-sequence" as="xs:double*">
<xsl:param name="n" as="xs:integer"/>
<xsl:iterate select="1 to $n">
<xsl:param name="rng"
select="random-number-generator(current-dateTime())"/>
<xsl:sequence select="$rng?number"/>
<xsl:next-iteration>
<xsl:with-param name="rng" select="$rng?next()"/>
</xsl:next-iteration>
</xsl:iterate>
</xsl:function>
<xsl:template match="/*">
<xsl:copy>{mf:random-number-sequence(10)}</xsl:copy>
</xsl:template>
</xsl:stylesheet>
So in general it seems that the XPath 3.1 parsing or evaluation tends to
fail with more complex expressions. It would be nice if the
implementation could be made more robust to ensure you can use the full
expressivness of the XPath 3.1 language.
