Support #1629
closed
Strange recursive behaviour in stylesheet
0%
Description
Reported by Jesper Tverskov:
This error can be reproduced with the attached stylesheet.
- If the row count, "rcount", is lower than 9, the recursion works.
If it is 9 the number of rows returned explodes. If it is higher than
9 no rows are returned.
- It is easy to fix the templates, I can do one of two:
If I change:
<xsl:value-of select="$i + 1"/>
</xsl:with-param>
to:
<xsl:with-param select="$i + 1"/>
Everything is ok.
It is also ok if I change it to:
<xsl:with-param as="xs:integer">
<xsl:value-of select="$i + 1"/>
</xsl:with-param>
Files
Updated by O'Neil Delpratt about 12 years ago
- File stylesheet.xsl stylesheet.xsl added
- Subject changed from NoSuchMethodException thrown by call to AtomicValue method getItemType to Strange recursive behaviour in stylesheet
- Description updated (diff)
- Category changed from Byte code generation to Internals
- Status changed from Resolved to In Progress
- % Done changed from 100 to 0
Updated by O'Neil Delpratt about 12 years ago
- Status changed from In Progress to Rejected
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.
Updated by Michael Kay about 12 years ago
- Tracker changed from Bug to Support
- Priority changed from High to Normal
- Found in version deleted (
9.4)
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.
Please register to edit this issue
.