This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current draft says: [1] A special rule applies to propagation of dynamic errors by switch expressions. [2] The case clauses of a switch expression do not raise any dynamic errors except in the effective case. [3] Dynamic errors raised in the operand expressions of the switch or the case clauses are propagated. [4] An implementation must not raise errors in the operand expressions of case clauses that occur after the effective case. Some comments: (a) it's not entirely clear exactly what it means by "operand expressions" and "case clauses", though one can make reasonable guesses (b) In sentence [1], I think the significance of "special" is that this rule overrides the general provisions in "Errors and Optimization". Perhaps this should be spelled out. (c) In [2], I think "case clause" is probably referring to the return expression and not the operand expressions, but this is not made clear. (d) Rule [4] is stating an exception to rule [3]. Reading rule [3] on its own suggests that an error in any operand expression should be propagated, whether or not it comes after the effective case. (e) Stylistically, it's odd that the subject of the four sentences is in each case a different kind of thing: respectively "a rule", "a case clause", "an error", and "an implementation". (f) None of this applies to static errors or type errors, and this should perhaps be explicitly stated. In [1..3] the rule does say that it refers only to "dynamic errors", but there is no such qualification in rule [4]; a reader might infer that type errors in cases after the effective case are not to be reported. This does raise a question about when type errors could/should/must be reported, for example in switch ($x) case "string" return "a" case 42 return "b" default return "c"
With regard to the last remark, it seems by following the link to "equivalence of atomic values" that the unstated intent is perhaps: * Both the "switch operand" and the "case operands" should be atomized, and cast to string if they are untypedAtomic. * In both cases, a type error is raised if the value contains more than one item. * No type error is raised if the values are not comparable; they are treated as not equal. The referenced rules for "equivalence of atomic values" don't really fit properly, because they assume the rules are being used in the context of grouping. For example, there's nothing that explicitly states what collation is used; it's left to the reader to work out that it can only possibly be the default collation from the static context of the switch expression. Presumably it's reasonable to raise a warning if there is a case clause that can never fire because the types are disjoint.
I believe these are all editorial changes rather than substantive changes - is that correct?
I think the changes proposed are probably uncontroversial, but it's entirely possible that someone else is reading the text differently, so I think it's safest to treat it as a substantive change.
In today's telcon, we agreed to adopt the comments in #0 and #1, allowing the editor "considerable editorial license".
I am reopening this because there are one substantive issue that needs to be decided by the WG: From the original bug report - what are the rules for reporting static errors? > (f) None of this applies to static errors or type errors, and this should > perhaps be explicitly stated. In [1..3] the rule does say that it refers only > to "dynamic errors", but there is no such qualification in rule [4]; a reader > might infer that type errors in cases after the effective case are not to be > reported. This does raise a question about when type errors could/should/must > be reported, for example in > > switch ($x) > case "string" return "a" > case 42 return "b" > default return "c" Comment #1 raises another issue that looks substantive: > Presumably it's reasonable to raise a warning if there is a case clause that > can never fire because the types are disjoint. However, warnings in XQuery are entirely implementation-defined, so this is not something the specification can or should address.
At the Oxford face-to-face, the Working Group decided the following: We don't want to prohibit raising errors before the effective case but we also don't want to require them (in operands). We do want to prohibit errors in the operands _after_ the matching case.