Saxon

Thank you for reporting it. As you have found out, this is caused by a bug in the optimizer.

In fact it's caused by two separate optimizations that interfere with each other. The first of these is to use an optimized comparison of untypedAtomic values to numerics that avoids the full cost of number-to-string conversion; the second is to use a hash table lookup for the choose expression because the branches are homogenous and disjoint. Both of these optimizations are known to give very worthwhile performance improvements for some workloads.

Your easiest workaround is to replace the numeric literals in the @test expressions with string literals, that is, change @SaleLock = 1 to @SaleLock = '1'. That's assuming you don't need to match alternative representations like '01' or '+1', in which case you could do the conversion explicitly.

I'm afraid the answers to your questions are somewhat banal:

(1) Bugs happen. Optimization is particularly prone to bugs, because it makes the code less orthogonal and therefore increases the number of test cases needed combinatorially. This bug is very typical of optimization bugs: two conditions which might each be present in 1 out of 50 stylesheets are present in combination only in 1 out of 2500 stylesheets. Although we run hundreds of thousands of test cases, most of them are designed to test features in isolation rather than in combination.

(2) Other bugs. Although 9.9.x is now very stable indeed, and 10.x is also becoming quite stable, in our experience it's not that unusual for a bug to survive in the product for five years before anyone detects it.

(3) Testing. It's a really good idea to have a good test suite for your own stylesheets. A really comprehensive set of XSpec tests would be ideal; but as a minimum, a test suite that simply tests each stylesheet against a small number of input documents and compares the results with expected results to see they haven't changed.

Unless you indicate otherwise, we will take this test case (thanks for packaging it up so cleanly) and add it to the W3C XSLT3 test suite which we run for continuous testing to prevent regressions.

Thanks you the answer Micheal,

Your easiest workaround is to replace the numeric literals in the @test expressions with string literals, that is, change @SaleLock = 1 to @SaleLock = '1'. That's assuming you don't need to match alternative representations like '01' or '+1', in which case you could do the conversion explicitly.

It is hard to check all the transformations because our integrating team created more than 3,5k different ones. Some of them have side effects or create dynamic data (i.e. timestamps) which makes them hard to compare.

Nevertheless, I am considering to disable optimization by default and enable it only for transfromations with a poor performance. Is it a good way?

Unless you indicate otherwise, we will take this test case (thanks for packaging it up so cleanly) and add it to the W3C XSLT3 test suite which we run for continuous testing to prevent regressions.

Feel free to include it as a test case ;-) I will wait for a bugfix.

Bug fix applied in the Saxon 10.3 maintenance release