[Bug 11547] [XQuery3] Scope of try-catch.

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

--- Comment #2 from Oliver Hallam <oliver@cbcl.co.uk> 2010-12-14 15:23:47 UTC ---
I support Michael's suggestion in comment #2.  This formalisation is necessary
to tighten up another area of the specification (4.17):

When rewriting expressions into equivalent expressions, as described in 2.3.4
Errors and Optimization, a conforming XQuery implementation must ensure that
each run-time invocation of a nondeterministic function in the original
expression results in exactly one run-time invocation of the function in the
rewritten expression.

This sentence assumes that the number of "run-time invocations" of a function
is well defined, but in many cases it isn't.  If you have an order-by clause on
a single tuple then do you evaluate the order specifier?

A large part of the XQuery Scripting Extensions specification contains a
similar formalism, although with the main aim of describing a well defined
evaluation order.  Would it be worth defining an evaluation order at the same
time?  The evaluation order would be ignored in XQuery but would save a lot of
work when Scripting is updated!

On a side note does the above condition not make evaluation order important,
for example in the following query:

(for $x in 1 to f() return g()) = (for $x in 1 to f() return h())

The order in which the arguments to the equals operator is evaluated affects
the order in which the calls to f() are evaluated.  This again affects the
number of times the functions g and h are evaluated, and so by the constraint
above, the processor is not allowed to change the order the arguments are
evaluated!  This is a surprising consequence of condition in the spec, and so
is either a bug in the condition, or should be spelled out explicitly.

I am increasingly of the opinion that any attempt to formalize
non-deterministic functions makes them more like sequential functions.  Maybe
it would be best just to define an evaluation order for non-deterministic
functions and merge the two concepts.  Beyond random(), are there any real use
cases for this middle ground?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 14 December 2010 15:23:50 UTC