This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From what I can tell, the following query succeeds to compile: typeswitch(1) case xs:integer return 1 case xs:integer return 2 default return -1 What it evaluates to, I find more tricky to determine. I think this sentence is supposed to tell: <quote> [Definition: The effective case in a typeswitch expression is the first case clause such that the value of the operand expression matches the SequenceType in the case clause, using the rules of SequenceType matching. </quote> I find the sentence phrased in a tricky way("the first case clause such that the value of"). I assume that the "first case" refers to the first case clause in terms of occurrence in the "physical" query, not whatever the implementations happens to match "first". I think the above query should fail to compile because it is vague what is the result, and it is unclear what the user wants should happen. Other languages, such as C++, treats identical case conditions as errors. Perhaps this applies extraordinarily due to the declarative nature of XQuery and its lack of "order of execution". More specifically, I propose two things: * That the following paragraph is added: "It is an error if two or more case clauses specifies sequence types that are identical to one another[new error code].", or something in that direction. I don't know what to refer to in order to define sequence type equalness(probably something in 2.5.4). Perhaps one should keep an eye on that it is clear that types can still have the same parent types(it sounds perhaps obvious since all types are derived from item() if one thinks about it, but then one have to think about it). * Reword the definition of effective case to be a bit simpler(or is it just me?) However, I do suspect I've missed something glaringly obvious.. Regards, Frans
Proposed wording of the definition for effective case: [Definition: The effective case in a typeswitch expression is the case whose SequenceType matches the value of the operand expression, using the rules of SequenceType matching. If more than one SequenceType matches, the matching case appearing first in the query is the effective case.] It can surely be improved. Nevertheless, I think it makes it clear that the query: typeswitch((1, 2, "a string")) case item+ return 1 case xdt:anyAtomicType+ return 2 default return 3 evaluates to 1. One could add the query as an example; it illustrates what that is chosen in case multiple cases matches, and that the value of the operand expression is treated as a whole, not on a per-item basis. Another possibility is to require implementations to determine the closest matching case. But I ruled it out because it hinders exit-early optimizations for the gain of the in practice rare case(my speculation) where the user specifies multiple matching cases, in an order where the first matching would be wrong, from the user's perspective. One could make it an error if a case specifies a sequence type that is a sub type of a sequence type appearing before it, because it will never match(the user's code makes no sense, it is buggy). The advantage is that it wouldn't be possible to write a typeswitch where it is in any way vague what case branch is taken. It would be a typical warning an implementation could issue, but perhaps it is useful enough for making the spec require it. But, the additional implementation burden and that the user's code is dealt with on such a low level, makes it doubtful. But I mention it. Frans
I have some sympathy with making this an error, however I don't think it's trivial to do. It would be odd to have an error where the types are identical and not where the first type subsumes the second. Neither identity nor subsumption of types are trivial to define (is element() identical to element(*)?); at present this is done only in the formal semantics, and need only be implemented by products that implement the static typing option. It might be better to leave this as one of the many places where we allow implementations to raise a warning. Michael Kay (personal response)
The XQuery Working Group discussed this comment at its meeting on 14th March 2006. We decided to follow the reasoning in comment #2 and not introduce a new error for this case, although implementations are, as always, free to generate warnings for this situation if they wish. I am therefore closing the bug report as "won't fix", indicating that we propose to make no change to the specification. If you are content with this response, please mark the bug report as closed; otherwise please supply further explanation as to why the change needs to be made. If we don't hear from you, we will close the bug report at the end of March. Mary Holstege for the XQuery Working Group
I, as probably many others, doesn't like how the language turns out in this area, but I think it's (unfortunately) the best solution given the practical circumstances, as explained in motivation of the resolution. However, I think that it still can be improved editorially, see new bug report #3011[1]. I am satisfied with the resolution of this bug report and therefore change its status to CLOSED. (btw, I would consider element() and element(*) identical, because "2.5.4.3 Element Test" says "1. element() and element(*) match any single element node, regardless of its name or type annotation.") Regards, Frans 1. http://www.w3.org/Bugs/Public/show_bug.cgi?id=3011