Possible bug Saxon EE 10.6 (bool in xpath value)
We have our app working on both linux and windows environments. An we are facing issues with the way saxon behaves in case of linux.
In xml source file we have bool value (BoolValue node below). Its being using in various expressions.
In case then its a simple expression all is fine - bool value automatically being converted to bool type: <xsl:value-of select="not(1 > 2) = /root/BoolValue"/> - result is "true", "/root/BoolValue" being used as bool type. Same behaviour both, in linux and windows.
But if the same expression is in xpath - it behave differently. For example: <xsl:value-of select="sum(/root/items/*[not(data > 0) = /root/BoolValue]/Amount) != 0"/> In this case we have "true" in case of windows. Here "/root/BoolValue" is bool (true). But in case of linux its "false". Here "/root/BoolValue" is text or something.
If its directly converted to boolean - it works similar. <xsl:value-of select="sum(/root/items/*[not(data > 0) = boolean(/root/BoolValue)]/Amount) != 0"/>
Is it possible to log this issue as a bug and fix in the next version of saxon? Thanks
(2 xsl files are attached, first one is actually an xml file, our app executes xsl in a chain. Each with the result from previous one. So test-0.xsl should be executed first, with any xml, and then test.xsl should be executed with the result of test-0.xsl)
<root> <BoolValue>true</BoolValue> <items> <item> <data> 10</data> <Amount> 100</Amount> </item> <item> <data> 0</data> <Amount> 999</Amount> </item> <item> <data> 11</data> <Amount> 101</Amount> </item> <item> <data> 12</data> <Amount> 102</Amount> </item> <item> <data> 13</data> <Amount> 103</Amount> </item> </items> </root>
Please register to reply
I suspect that one one of your two platforms you are unintentionally running this with an XSLT 1.0 processor.
In the comparison
not(data > 0) = /root/BoolValue, you are comparing a boolean with a node-set.
Under XSLT 1.0 rules, this effectively means
not(data > 0) = exists(/root/BoolValue), that is, the node-set is converted to a boolean - true if the node-set is non-empty, false if it is empty. The actual value of the BoolValue element is irrelevant: the result is the same whether the element's value is "true" or "false".
Under XSLT 2.0 rules, the expression is true if the result of atomising the BoolValue element and converting to a boolean matches the other operand.
So the 1.0 rules and the 2.0 rules are quite different, and you can see that you get different results if you force it to use 1.0 rules by setting version="1.0" in the stylesheet.
But at this stage I'm still puzzled, because given that the value of BoolValue is "true", we would expect the RHS operand to be "true" under either rule.
In fact the predicate evaluates to (false, true, false, false, false) for the five items in both cases. But the sum() is 0 under XSLT 3.0, 999 under XSLT 1.0.
So it looks like there is actually a Saxon bug here: it's an optimization bug in evaluating a filter expression where the predicate is an equality comparison between booleans. The optimization doesn't happen (and therefore the bug isn't visible) when you run the stylesheet in 1.0 mode, or when you run an old release of Saxon that only implements 1.0.
I think my original conjecture is correct, that you are running the wrong version of the Saxon software (or perhaps not even Saxon) on one of the platforms, and that this accounts for the difference between platforms. But it seems like there's a Saxon bug as well.
You should be able to work around the optimisation bug by setting -opt:-k.
I've raised the bug at https://saxonica.plan.io/issues/5187?issue_count=32&issue_position=1&next_issue_id=5186
Please watch that issue to track progress. (You can click on a "star" icon at top right to be notified of changes).
Come to think of it, it might not be different Saxon versions on the two machines, it might be that one is running Saxon-EE (licensed) and the other is running Saxon-HE (or Saxon-EE unlicensed).
Version of saxon is the same - 10.6 EE Version of XSLT might be 2.0 or 3.0! Can it be the case?
Then I think in one case you're not picking up the license file, so it's running without optimisation enabled, which bypasses the bug.
Please register to reply