[xquery-talk] XQuery error codes and rewriting

[Michael Kay]

The spec as written certainly allows implentations a great deal of freedom,
and I think it's true in theory that an implementation that returns 42 as
the result of (1 div 0) is conformant.

It's hard to see how to rule out such nonsense without also ruling out
perfectly sensible and reasonable optimizations like returning true as the
result of

some $x in (10, 20, 30, 40, 0) satisfies (10 div $x eq 1) 

If anyone has any good ideas on how to distinguish the sensible from the
ridiculous, other than letting the market decide, please send your answers
on a postcard...

One approach, of course, is to use the test suite as the discriminator.

Another approach is the XPath 1.0 philosophy that errors don't happen, you
always get a defined result even if it's a blank screen. That of course has
the drawback that it's very hard to find out why you got a blank screen.

The rule about allowing rewrites that don't have the same error behavior is
mainly there for vendors who translate XQuery into SQL. There's a pragmatic
judgement here that users would rather have a query that executes in 1
second and gives the right answer in non-error cases, than a query that
spends 24 hours searching for possible errors before giving the same answer.


Michael Kay
http://www.saxonica.com/



> -----Original Message-----
> From: talk-bounces at xquery.com 
> [mailto:talk-bounces at xquery.com] On Behalf Of John Snelson
> Sent: 02 February 2006 13:30
> To: David Carlisle
> Cc: talk at xquery.com
> Subject: Re: [xquery-talk] XQuery error codes and rewriting
> 
> David Carlisle wrote:
> > http://www.w3.org/TR/xquery/#id-errors-and-opt
> > says
> > 
> >     For a variety of reasons, including optimization, 
> 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. 
> 
> Similarly, I have wondered about this clause in the XQuery spec. For 
> instance, if I choose to rewrite "/" into "fn:root()" instead of 
> "fn:root(self::node()) treat as document-node()", all I have 
> changed is 
> the error cases. The expression "/" now gives results in more 
> cases than 
> it did before (when the result is not a document node), and gives an 
> alternate error code if the context item is undefined.
> 
> Is this acceptable? What if I rewrite an expression to give the same 
> non-error answers, but complete gibberish when the spec says there 
> should be an error - is that still conformant to the spec?
> 
> John
> 
> -- 
> John Snelson, Berkeley DB XML Engineer
> Sleepycat Software, Inc
> http://www.sleepycat.com
> 
> Contracted to Sleepycat through Parthenon Computing Ltd
> http://blog.parthcomp.com/dbxml
> _______________________________________________
> talk at xquery.com
> http://xquery.com/mailman/listinfo/talk
>