Bug #6467
closedxsl:merge error when using Tlevel:high but not with other Tlevel values (Saxon HE12.5 Java)
0%
Description
I have a simple xsl:merge test case that fails with this error when I run it with Tlevel:high. It works fine with Tlevel:normal or low or not set.
Error at xsl:merge on line 17 column 18 of Merge.xslt:
XTDE2210 Corresponding xsl:merge-key attributes in different xsl:merge-source elements do
not have the same effective values
In template xsl:initial-template on line 4 column 45 of Merge.xslt:
Corresponding xsl:merge-key attributes in different xsl:merge-source elements do not have the same effective values
The code merges the data from the 2 variables and the xsl:merge-source elements are basically the same:
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="xsl:initial-template">
<root>
<!-- 2 data sets to be merged -->
<xsl:variable name="mergeSourceA">
<node>100</node>
<node>300</node>
<node>500</node>
</xsl:variable>
<xsl:variable name="mergeSourceB">
<node>200</node>
<node>400</node>
<node>600</node>
</xsl:variable>
<xsl:merge>
<xsl:merge-source select="$mergeSourceA/*">
<xsl:merge-key select="." />
</xsl:merge-source>
<xsl:merge-source select="$mergeSourceB/*">
<xsl:merge-key select="." />
</xsl:merge-source>
<xsl:merge-action>
<node>
<xsl:value-of select="current-merge-key()"/>
</node>
</xsl:merge-action>
</xsl:merge>
</root>
</xsl:template>
</xsl:stylesheet>
Adrian
Files
Updated by Michael Kay 4 months ago
The comparison of merge keys is done using Expression.equals(), which is not implemented for the class TraceExpression
, and therefore different instances of TraceExpression
compare not equal.
In fact the comparison is done at two different stages. At compile time we check whether the sort expressions are "fixed" (that is, collation, order, case-order, etc are all known statically), and if they are both fixed, we produce a static error if they are not equal. This isn't happening here, because an expression that includes a call on tracing isn't considered to be "fixed".
There is then another check done at execution time. After evaluating the values of collation, order, case-order, etc, the sort key definitions are now fixed, and we compare the fixed values. This check is failing because there is one property of the sort key that we fail to fix, namely the "stable" attribute. In fact xsl:merge-key doesn't have a stable
attribute, but we are reusing the logic of xsl:sort-key
which does.
There are quite a few ways we could improve this. We could try to avoid injecting trace expressions where they are obviously pointless, like for sort key properties that have been defaulted. We could provide an equals() method for trace expressions. We could plug the fact that the "stable" attribute doesn't get fixed. Any or all of the above would fix the immediate problem.
Updated by Michael Kay 4 months ago
- Category set to Diagnostics
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 12, trunk added
- Fix Committed on Branch 12, trunk added
- Platforms .NET, Java added
I have made the following changes:
(a) Provide an equals() method for trace expressions.
(b) In SortKeyDefinition.fix(), fix the stable
subexpression.
Please register to edit this issue