[Bug 29931] New: collation tests allow fallback behavior but the expected results do not

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29931

            Bug ID: 29931
           Summary: collation tests allow fallback behavior but the
                    expected results do not
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3 & XPath 3 Test Suite
          Assignee: oneil@saxonica.com
          Reporter: josh.spiegel@oracle.com
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 11 October 2016 18:36:51 UTC