- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Jun 2010 22:28:55 +0000
- To: public-qt-comments@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