[Bug 4441] [XQuery] 2.3.4 Optimization rules unclear?

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

           Summary: [XQuery] 2.3.4 Optimization rules unclear?
           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


In my opinion, section 2.3.4 „Errors and Optimization“ does not sufficiently
clearly define the implementor’s freedom in optimizing the evaluation process.
However, full clarity is needed when the query writer wants to enforce the
evaluation of a function the return value of which will not be used afterwards.
The text states:

“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 furher items in the operand E.”

Please consider explicit clarification of the following question: May the
processor skip the evaluation of a function call based on an evaluation of the
function’s return type?

Explanation
===========
For example, consider this code:

declare function local:prepareEnvironment() as xs:boolean {…};

if (count(local: prepareEnvironment ()) lt 1) then error(“NEVER”) else
local:produceResult()

This construction is meant to ensure that ‘prepareEnvironment’ is indeed
evaluated, and that it is evaluated before ‘produceResult’. But can one be sure
that ‘prepareEnvironment’ will be evaluated? The answer hinges on the
clarification requested above.

Postscriptum
============
If the processor may indeed perform such skips, these were the consequences:
- functions with return type empty-sequence() never need to be evaluated
- it becomes a serious problem to enforce the evaluation of a function call the
result of which must be discarded (namely, is neither part of the result nor is
it allowed to influence the result) 

Regards,
- Hans-Juergen

Received on Saturday, 31 March 2007 12:35:19 UTC