[Bug 29853] [FO31] fn:collation-key() does not depend on implicit-timezone

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

--- Comment #2 from Michael Kay <mike@saxonica.com> ---
I think the requirements are:

* The eq operator on collation keys must give the same result as the
op:same-key() relation

* The type must be ordered, and the ordering must be context-free and must
reflect the order of strings in the collation

* The value space must be infinite (in the sense that the value space of
strings is infinite)

* The value space and ordering must be such that for any two values A and B
where A<B, there is an infinite set of values between A and B. 

I think this pretty well leaves the two binary types as the only possible
candidates. (One can imagine other theoretical possibilities, e.g. infinite
precision decimal or infinite precision duration, but they don't seem very
practical choices).

I therefore propose that we define the collation key to be xs:base64Binary. (We
could choose either binary type, but it's messy to allow both, and base64Binary
is the one that the EXPath binary project chose, so it's better supported. The
two types are identical unless you convert the collation key to a string, and
there's no real use case for doing that.)

A minor difficulty is that XSLT 3.0 defines the fn:collation-key() function to
be usable with XPath 3.0 implementations, and xs:base64Binary is not an ordered
type in XPath 3.0. But the use cases for wanting collation keys to be ordered
came primarily from XQuery (XQuery "order by", unlike xsl:sort, does not allow
a dynamic collation URI), and it's no great loss if for this particular case
(XSLT 3.0 + XPath 3.0) the collation keys aren't ordered.

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

Received on Thursday, 22 September 2016 07:43:50 UTC