- From: <bugzilla@jessica.w3.org>
- Date: Wed, 21 Sep 2016 16:13:53 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29853 --- Comment #1 from Michael Kay <mike@saxonica.com> --- Thinking about this more carefully, I think there may be a problem here. We say: collation-key($K1, $C) eq collation-key($K2, $C) if and only if compare($K1, $K2, $C) eq 0 and we also say in a note The result of the function can be of any atomic type that permits ordering. But what if the collation key has a type whose "eq" operator is context-sensitive? For example, if it depends on the default collation, or on the implicit timezone? This clearly isn't intended: the whole idea is that collation keys should be comparable in a predictable context-free manner. The XQuery use case we give for collation-key() order by fn:collation-key($e/@key, $collation) doesn't work if the ordering semantics for collation keys are context-dependent. To achieve this I think we need to ban the use of xs:string, xs:untypedAtomic, and untimezoned dates/times as collation keys. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 21 September 2016 16:14:03 UTC