This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I am a bit confused as to what optimizations are permitted by the spec. Could, for example, let $x = codepoints-to-string(12) return $x = $x be legitimately optimized down to true(), despite the fact that codepoints-to-string(12) should throw an FOCH0001 error? Section 2.3.4 of the spec says: "Consider an expression Q that has an operand (sub-expression) E. In general the value of E is a sequence. At an intermediate stage during evaluation of the sequence, some of its items will be known and others will be unknown. If, at such an intermediate stage of evaluation, a processor is able to establish that there are only two possible outcomes of evaluating Q, namely the value V or an error, then the processor may deliver the result V without evaluating further items in the operand E." which seems to imply the above optimization is fine. If this is correct then could the following expression be optimised down to true() as well (which is clearly not the intention of the query)? typeswitch(.) case $a as xs:integer return true() default return error()
Personal response. >I am a bit confused as to what optimizations are permitted by the spec. I think it's generally true that the spec doesn't try to provide a completely black-and-white answer to this question. >Could, for example, let $x = codepoints-to-string(12) return $x = $x >be legitimately optimized down to true(), despite the fact that codepoints-to-string(12) should throw an FOCH0001 error? I think the answer is yes. If you can establish that $x is not empty and is not NaN, that is sufficient to deduce that $x=$x is true; you aren't required to establish that evaluating $x is error-free. >If this is correct then could the following expression be optimised down to true() as well (which is clearly not the intention of the query)?... typeswitch(.) There's currently a special rule for conditionals and typeswitch to the effect that you can't evaluate a branch unless the controlling condition is true. If I recall correctly there's an erratum in preparation that makes this a bit more strict, by saying that if the controlling condition is true you must evaluate the branch, even if the only reason for doing so is to distinguish between an error and a non-error result.
The WG discussed this on 18 Sep 2007 and agreed with the analysis in comment #2; note that the erratum introduced by bug #4446 clarifies the rules for the typeswitch example further. If you agree, please close the bug.