Saxon

This issue is not a bug. The use of xsl:value-of within xsl:with-param of the recursive calls returns a document with a text node (ref: http://www.w3.org/TR/xslt20/#element-value-of). At runtime we do not know the types of the parameter values. Hence, when calls are made on the parameters in the the comparison of xsl:if they are deemed as an untypedAtomic value.

As a result, according to the XPath 2.0 specification, if both atomic values are instances of xs:untypedAtomic, then the values are cast to the type xs:string. This means our comparisons is based on string values and not as integers. (Ref: http://www.w3.org/TR/xpath20/#id-general-comparisons) giving unpredictable results.

Transferring to "Support" category so it doesn't come up in a bug search.

I would strongly recommend using the select attribute of xsl:with-param (and xsl:variable) etc wherever it's possible. At best, the use of an xsl:value-of causes a significant overhead because of the need to convert a number to a string, then to a text node, then to create a document wrapper, then to atomize this to untyped atomic, then to convert this back to a number. At worst, as shown here, it gives wrong results.