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.

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.

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.

(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

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."

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.