893 fn:compare: Support for arbitrary atomic types

[ChristianGruen]

No description provided.

[michaelhkay]

A very pendantic reader might say that the sentence "If both $value1 and $value2 are instances of one of xs:string, xs:anyURI or xs:untypedAtomic" is ambiguous; it could mean that they both have to be instances of the same one of these three types. The phrase "one of" does not help to remove the ambiguity. A possible resolution would be to define that a value is "string-like" if it is an instance of one of these three types; we could use this defined term in quite a few places.

It's not a good idea to convert untypedAtomic to the type of the other operand. It leads to non-transitivity, which makes the function unsuitable as a callback to fn:sort.

I think base64Binary and hexBinary should be mutually comparable.

[ChristianGruen]

Revised, thanks.

A very pendantic reader might say that the sentence "If both $value1 and $value2 are instances of one of xs:string, xs:anyURI or xs:untypedAtomic" is ambiguous; it could mean that they both have to be instances of the same one of these three types. The phrase "one of" does not help to remove the ambiguity. A possible resolution would be to define that a value is "string-like" if it is an instance of one of these three types; we could use this defined term in quite a few places.

I’ve now listed the corresponding types twice, once for each input value; same for xs:base64Binary and xs:hexBinary, which I have combined.

For pedantic readers, we might also need to rephrase the rules of fn:min and fn:max, which currently read:

If each value is an instance of one of the types xs:string or xs:anyURI, then all the values are cast to type xs:string.

[michaelhkay]

The example "compare(xs:date('2001-01-01'), xs:untypedAtomic('2001-01-01'))" needs to change.

[ndw]

The CG agreed to merge this PR at meeting 060