[Bug 28795] [F+O] 3.1 Non-transitive equality for numerics in maps

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

Josh Spiegel <josh.spiegel@oracle.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josh.spiegel@oracle.com

--- Comment #3 from Josh Spiegel <josh.spiegel@oracle.com> ---
I agree that the specifications should not make it difficult (or impossible)
for implementations to use off-the-shelf components.  Do you think this
proposal could be implemented by a hash table?

> If we define a new equality relation then we could also consider using it, of course, for distinct-values() and grouping. I'm not proposing that at the moment - it has compatibility implications, though I find it impossible to believe anyone is actually relying on the current non-transitive behaviour.

XQTS is relying on it.  For example, I think the result of fn-distinct-values-1
would change.  I am not in favor of backward incompatible changes to
distinct-values() or group by. 

> Is the problem for maps worse than the existing problem for distinct-values and for grouping? 

Here are the relevant lines from distinct-values:

"In the situation where the input contains three values A, B, and C such that A
eq B, B eq C, but A ne C, then the number of items in the result of the
function (as well as the choice of which items are returned) is
·implementation-dependent·, subject only to the constraints that (a) no two
items in the result sequence compare equal to each other, and (b) every input
item that does not appear in the result sequence compares equal to some item
that does appear in the result sequence."

I think it is worse for maps because of the associated values.  When merging
maps, I think the intuition is that the last value in the input sequence makes
it to the result.  This gets awkward when A, B, and C are the keys of map
entries.

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

Received on Monday, 15 June 2015 17:17:47 UTC