This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The new collation-key() function states: This specification does not mandate that collation keys should retain ordering. This is partly because the primary use case is for maps, where only equality comparisons are required, and partly to allow the use of binary data types (which are currently unordered types) for the result. The specification may be revised in a future release to specify that ordering is preserved. However, we have introduced support for ordering in hexBinary and base64Binary, and UCA defines an algorithm for generating binary collation keys that respect ordering. So we should review this decision.
This proposal was accepted in principle by the WG on 2014-04-29, subject to approval of detailed wording. The substantive change proposed is to replace the second paragraph of the rules of fn:collation-key() with: The function returns an ·implementation-defined· value with the property that for all pairs of strings ($K1, $K2): (a) collation-key($K1, $C) eq collation-key($K2, $C) if and only if compare($K1, $K2, $C) = 0, and (b) collation-key($K1, $C) lt collation-key($K2, $C) if and only if compare($K1, $K2, $C) < 0 The remaining changes are purely editorial, e.g. changing the summary, deleting the last paragraph of the Notes, adding examples.
I have anticipated acceptance by updating the master text (the changes are all tagged at="B-bug25446" so they can be rolled back if necessary).
I don't see the change. Did you check in yet?
I've committed the XML but haven't yet rebuilt the HTML.
The proposal in comment 1 was accepted, noting also that collation keys should be implementation-dependent rather than implementation-defined.