W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2010

[Bug 9757] Group By Clause: Equivalence: "atomic" is incorrect

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Jun 2010 22:28:55 +0000
To: public-qt-comments@w3.org
Message-Id: <E1OJwQh-0002tM-1F@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9757


Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com




--- Comment #1 from Michael Kay <mike@saxonica.com>  2010-06-02 22:28:54 ---
My proposal for this is as follows:

1. Delete the definition of "equivalence of two atomic values".

2. In 3.8.7, change list item 2 of the "process of group formation" to read as
follows:

   <new>

2. The input tuple stream is partitioned into groups of tuples whose grouping
keys are /equivalent/. Two tuples T1 and T2 have /equivalent/ grouping keys if
and only if, for each grouping variable GV, the atomized value of GV in T1 is
deep-equal to the atomized value of GV in T2, as defined by applying the
function fn:deep-equal using the appropriate collation.

Note: the atomized grouping key will always be either an empty sequence or a
single atomic value. Defining equivalence by reference to the fn:deep-equal
function ensures that the empty sequence is equivalent only to the empty
sequence, that NaN is equivalent to NaN, that untypedAtomic values are compared
as strings, and that values for which the eq operator is not defined are
considered non-equivalent.

3. The appropriate collation for comparing two grouping keys is the collation
specified in the pertinent _GroupingSpec_ if present, or the default collation
from the static context otherwise. If the collation is specified by a relative
URI, that relative URI is resolved to an absolute URI using the base URI in the
static context. If the specified collation is not found in statically known
collations, a static error is raised [err:XQST0076]. 

  </new>

3. In 3.11 Switch, change the two paragraphs starting "The first step.." and
"[Definition: The effective case..." to:

  <new>

The first step in evaluating a switch expression is to apply atomization to the
value of the switch operand expression. If the result is a sequence of length
greater than one, a type error is raised [err:XPTY0004].

The resulting value is matched against each _SwitchCaseOperand_ in turn until a
match is found or the list is exhausted. The matching is performed as follows:

1. The _SwitchCaseOperand_ is evaluated.

2. The resulting value is atomized.

3. If the atomized sequence has length greater than one, a type error is raised
[err:XPTY0004]

4. The atomized value of the switch operand expression is compared with the
atomized value of the _SwitchCaseOperand_ using the fn:deep-equal function,
with the default collation from the static context.

[Definition: The effective case in a switch expression is the first case clause
that matches, using the rules given above.] The value of the switch expression
is the value of the return expression in the effective case.

   </new>

OBSERVATION: This reflects the current rules. However, I can't really see a
good case here for not raising a type error if the switch operand and switch
case operand have non-comparable types. This would seem to be a programming
mistake that we should report to the user. Personally, I think it would be
better to do the comparison using "eq" rather than fn:deep-equal(), and to
disallow () for both the switch and case operands. This situation is quite
different from grouping, where grouping a heterogeneous collection of values
makes sense.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 2 June 2010 22:28:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:31 UTC