30386 2018-12-27 02:14:41 +0000 [XSLT30] xsl:sort with collation and data-type="number" should throw an error, but this is not made explicit 2019-03-08 15:55:43 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Recommendation PC Windows NT NEW P2 normal --- 1 abel.online mike public-qt-comments oldest_to_newest 129466 0 abel.online 2018-12-27 02:14:41 +0000 Section 13.1.3 Sorting Using Collations describes the use of collations with sorting and explicitly states that the input must be xs:string/xs:anyURI or derived thereof. Since the previous section describes that xs:untypedAtomic is converted to xs:string and empty-sequence is ordered before anything else, this seems fine. But the input is converted to xs:float when data-type="number". This combination gives a sort keys that: 1) exists of items that are xs:float 2) must use collation on xs:string I'd be inclined to consider this an error scenario as written, though it can also be an oversight (i.e., should collation be ignored in that case?). There's a test that currently expects this to work: sort-012, but my processor thrown an error XTDE1030, which has the surprising message that xs:float cannot be compared to itself. I'm leaning towards making this indeed an error, it seems illogical to have both collation and data-type="number". Though at the same time, there's something to say for ignoring the data-type attribute completely, but this isn't in the spec. I have split the test in a version without collation (though as not to raise an error) and with collation (to throw the error). I'd be interested in any thoughts on this. 129467 1 mike 2018-12-27 10:18:00 +0000 My instinct is that the collation, case-order, and lang attributes should be ignored when comparing values other than strings (or untyped atomic). Firstly, I think all three attributes should be treated the same way. Secondly, if it's going to be a static error when it can be detected statically then I think it should be a dynamic error when it can't: it's effectively a type error. But that leads to complications, e.g. what if the sequence is a singleton xs:date and a collation is specified? Do we have to detect that and raise an error? Thirdly, I think the spec, by omission, says that this is not an error. If you follow the rules in the spec as written then you will not raise an error, and that means that it isn't. (It's probably a good case for a warning). Fourthly, XSLT 1.0 explicitly says that lang is ignored if data-type=number, which creates a backwards compatibility issue. You say that "§13.1.3 explicitly states that the input must be xs:string/xs:anyURI or derived thereof." I don't think that's the case: there is no MUST here, no condition that must be satisfied, which would implicitly define an error if it isn't. Rather the section says "The rules given in this section apply when comparing values whose type is xs:string or a type derived by restriction from xs:string, or whose type is xs:anyURI or a type derived by restriction from xs:anyURI." which to my mind says that the whole section is simply ignored when comparing non-string values. 129481 2 mike 2019-01-16 18:01:40 +0000 The removal of the collation attribute from test sort-012 makes the results implementation-defined, because the spec says: If none of the collation, lang, or case-order attributes is present, the collation is chosen in an implementation-defined way. 129494 3 mike 2019-02-13 14:32:40 +0000 Drafted erratum E45 to say that collation, case-order, and lang are ignored when there are no string-valued sort keys, including the case where data-type="number". If the attributes are ignored, then implementations may or may not report any errors in their values. 129517 4 abel.online 2019-02-19 19:42:50 +0000 (In reply to Michael Kay from comment #3) > Drafted erratum E45 to say that collation, case-order, and lang are ignored > when there are no string-valued sort keys, including the case where > data-type="number". If the attributes are ignored, then implementations may > or may not report any errors in their values. Agreed, thanks. I noticed a possible typo: "implementation may report errors in the value of these attributes" s/in/on/ (at least, I think) s/value/values/ For reference, deep-link: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E45 129543 5 abel.online 2019-02-20 10:57:56 +0000 Giving this some more thought, I see now the problem with any other than the current solution. The test sort-012 dynamically switches between data-type="text" and data-type="number". Code would become a lot harder to write if data-type number could not be combined with collations. Saying that collations etc are ignored in such cases fixes this. I'm wondering if we could improve one more line in this section. The opening says: "The rules given in this section apply when comparing values whose type is xs:string or a type derived by restriction from xs:string, or whose type is xs:anyURI or a type derived by restriction from xs:anyURI. " It is highly implicit and not immediately clear that xs:untypedAtomic applies as well. Could we add this, for instance by referring to the atomization/conversion process in 13.1.2: "The rules given in this section apply when comparing values whose type is xs:string or a type derived by restriction from xs:string, or whose type is xs:anyURI or a type derived by restriction from xs:anyURI, after conversion as explained in 13.1.2 Comparing Sort Key Values." 129625 6 abel.online 2019-03-08 15:55:43 +0000 For posterity: Michael Kay removed test sort-012err in rev #2046, which was there initially as a case for testing the here discussed error scenario, which proved to be no error scenario. Leaving this open for discussion of the erratum.