[Bug 4446] [XQuery] 2.3.4 Equivalent expressions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4446

           Summary: [XQuery] 2.3.4 Equivalent expressions
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: chamberl@almaden.ibm.com
        ReportedBy: hrennau@yahoo.de
         QAContact: public-qt-comments@w3.org


Section 2.3.4 „Errors and Optimization“ introduces the notion of equivalent
expressions:

“… implementations are free to rewrite expressions into equivalent expressions.
Other than the raising or not raising of errors, the result of evaluating an
equivalent expression must be the same as the result of evaluating the original
expression.”

If  I understand the text correctly, this amounts to the definition of
“equivalent expressions”.

Subsequent text shows that the expression

$N[@x castable as xs:date][xs:date(@x) gt xs:date("2000-01-01")]

is unsafe, whereas

$N[if (@x castable as xs:date) then xs:date(@x) gt xs:date("2000-01-01")
   else false()]

is safe. But are these not equivalent expressions, according to the definition?
If so, the second expression is not safe, because it might be rewritten! And I
even wonder if the expression:

        if (not(local:isInputOK())) then error((),”blablabla”) 
        else local:doSomething()

is not “equivalent” to the expression

        local:doSomething()

because “other than the raising or not raising or errors”, the result is the
same! I am sure no implementation would do such a rewrite, but the example
points to the basic uncertainty.

Please consider explicit clarification of the notion “equivalent expression” so
as to ensure fully predictable query results.

Regards,
- Hans-Juergen

Received on Monday, 2 April 2007 21:27:41 UTC