This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30231 - [XSLT30] In grouping, items are atomized before comparison, though maps can be compared and potentially grouped, but not atomized
Summary: [XSLT30] In grouping, items are atomized before comparison, though maps can b...
Status: RESOLVED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 major
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-18 18:29 UTC by Abel Braaksma
Modified: 2018-03-21 13:05 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2018-03-18 18:29:20 UTC 
In 14.1 we say in the 4th definition:

"the expression contained in the group-by or group-adjacent attribute is evaluated; the result is atomized; and any xs:untypedAtomic values are cast to xs:string"

Later we explain that comparison is done through the deep-equal function.

By extension, this suggests that maps are comparable, because deep-equal can compare them, but per the description of the definition, this is not possible, since atomization will throw a FOTY0013 or FOTY0012 error for function items and maps (not for arrays).

This may very well be "by design", but it seems reasonable that the actual intent of the text was that maps are allowed here. I don't see any inherent reason why maps could not be grouped.

A potential fix might be that the text "the result is atomized" is removed. The description of fn:deep-equal deals with both atomizable and non-atomizable items correctly.

Such a fix would probably lead to other errors being raised, instead of FOTY0012/13, FOTY0015 is raised for function items.
Comment 1 Michael Kay 2018-03-18 18:51:03 UTC 
I don't think there was ever any intention that grouping on map values should be possible.

The reason deep-equals() is used for comparing keys is that it has the desired behaviour when comparing atomic values of different types, e.g. integer and string.

deep-equal() is used in a similar way in the specification of operations such as fn:distinct-values(), fn:sort(), and op:same-key() - in each case the context makes it clear that we are only using the capability of deep-equal() to compare atomic values. The fact that only part of its capability is being used is irrelevant.

Because we atomize before comparing, the effect of grouping the two elements

<p>H2O</p>

<p>H<sub>2</sub>O</p>

using group-by="." is that both these elements go in the same group. If we didn't atomize, and compared the nodes using deep-equal(), they would go in different groups.
Comment 2 Abel Braaksma 2018-03-19 00:57:44 UTC 
> I don't think there was ever any intention that grouping on map values should 
> be possible.
Thanks, when reading it in the spec, it felt like an oversight, but then there isn't any problem.

> If we didn't atomize, and compared the nodes using deep-equal(), they would 
> go in different groups.
I didn't realize that but it makes sense. I didn't mean to suggest *not* using deep-equal, but I thought that we deliberately wanted to include its possibilities with maps (after all, grouping is on equality, not ordering, and as such it doesn't sound too far-fetched to me). 

I would like to move forward and close this bug report as "works for me" or something similar, it's clear now and my reading of the spec (as in: maps throw an error) seems right, so there isn't any ambiguity (apart from the one in my head ;).
Comment 3 Abel Braaksma 2018-03-21 13:05:27 UTC 
(In reply to Abel Braaksma from comment #2)
> I would like to move forward and close this bug report as "works for me" or
> something similar
To keep the list of open bugs as small as possible, I did just that, and closed this as "INVALID", I don't think it needs extra discussion. If you disagree, please reopen.