29931 2016-10-11 18:36:11 +0000 collation tests allow fallback behavior but the expected results do not 2016-10-25 14:10:28 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Candidate Recommendation PC All RESOLVED FIXED P2 normal --- 1 josh.spiegel oneil andrew_coleman mike public-qt-comments oldest_to_newest 127737 0 josh.spiegel 2016-10-11 18:36:11 +0000 A number of recently submitted UCA collation tests assume the implementation is not using the fallback behavior. For example consider this test: <test-case name="compare-031" covers="uca-collation" xmlns="http://www.w3.org/2010/09/qt-fots-catalog"> <created by="Michael Kay" on="2016-09-23"/> <test><![CDATA[fn:compare("database", "Database", "http://www.w3.org/2013/collation/UCA?lang=en;strength=tertiary;caseFirst=upper")]]></test> <result> <assert-eq>1</assert-eq> </result> </test-case> The default value of fallback is "yes" but the expected results do not account for this: <quote> If the fallback parameter is present with the value no, then the implementation must either use a collation that conforms with the rules in the Unicode specifications for the requested tailoring, or fail with a static or dynamic error indicating that it does not provide the collation (the error code should be the same as if the collation URI were not recognized). If the fallback parameter is omitted or takes the value yes, and if the collation URI is well-formed according to the rules in this section, then the implementation must accept the collation URI, and should use the available collation that most closely reflects the user's intentions. ... if it does not recognize the keyword or value then if the fallback parameter is present with the value no it should reject the collation as unsupported, otherwise it should ignore the unrecognized parameter. </quote> The following tests are affected: compare-031 compare-034 compare-035 compare-037 compare-039 compare-040 compare-041 compare-043 fn-contains-32 fn-contains-33 fn-contains-34 fn-contains-36 fn-contains-38 fn-starts-with-32 fn-starts-with-33 fn-substring-after-42 fn-substring-after-43 fn-ends-with-32 fn-substring-before-42 fo-test-d3e6934 fo-test-d3e6940 fo-test-d3e6946 fo-test-d3e7085 fo-test-d3e7091 fo-test-d3e7097 fo-test-d3e7246 fo-test-d3e7252 fo-test-d3e7258 fo-test-d3e7405 fo-test-d3e7546 fo-test-d3e7552 fo-test-d3e7558 One solution would be to set fallback=no and then allow the error as an alternate result. 127745 1 josh.spiegel 2016-10-11 21:19:00 +0000 Also: collation-key-009u 127841 2 mike 2016-10-18 16:41:47 +0000 MK suggested that a better resolution might be to mark these tests with a dependency. 127888 3 andrew_coleman 2016-10-20 18:34:19 +0000 The WG agreed the following resolution: ACTION A-657-14: O'Neil to look at bug 29931 on collations to add dependencies for these tests 127954 4 oneil 2016-10-25 14:10:28 +0000 created new dependency feature= advanced-uca-fallback. Updated text in the test-suite documentation (see running.html): "Indicates that the test uses a UCA collation URI with the option fallback=yes (or fallback omitted), and the test results assume that the implementation has a reasonably high level of support for uca collation semantics even if it is not 100% conformant. Unlike simple-uca-fallback these tests assume support for a wider range of uca collation features: including different collation strengths, different case ordering options and other options, such as numeric collations." tests cases highlighted in comment #0 and #1 updated with the new dependency feature.