This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Test case fn-transform-2 should not be dependent on XSLT 3.0, as it makes no use of XSLT 3.0 features. It works with an XSLT 2.0 processor as soon as the member "xslt-version":3.0, is removed from the options map. fn-transform-26 has suspicious assertions. The test produces a boolean value, but the assertions <any-of> <assert>true()</assert> <!-- caching seems to have taken place --> <assert>false()</assert> <!-- caching seems not to have taken place --> </any-of> do not depend on the result of the query. I presume it should have been <any-of> <assert-true /> <!-- caching seems to have taken place --> <assert-false /> <!-- caching seems not to have taken place --> </any-of> fn-transform-27 is similarly odd. The test returns a string, but the assertion is: <result> <assert>true()</assert> </result> which should always succeed regardless of the outcome of evaluation.
The WG agreed the following resolution: ACTION A-657-18: O'Neil to look at tests fn-transform-2, 26, 27 to improve them and actually test the caching, see Bug 29942
(In reply to Tim Mills from comment #0) > Test case fn-transform-2 should not be dependent on XSLT 3.0, as it makes no > use of XSLT 3.0 features. It works with an XSLT 2.0 processor as soon as > the member > > "xslt-version":3.0, > > is removed from the options map. This stylesheet is dependent on XSLT 3.0 because the variable $dateTime has static='yes'. We have fixed-up the assertions accordingly. We also think the caching is sound, therefore removed the misleading comment.
The new expected result for fn-trasform-26 assumes that caching has taken place. But since it is implementation-defined whether the cache option has an effect, false, is also possible. I've fixed that now. I've updated fn-transform-2, which does not depend on XSLT 3.0.