[xquery-talk] XQuery error codes and rewriting

[Peter Coppens]

Was it never considered to remove that paragraph altogether? 

I am sure that in that case some implementations will never be able to
fully comply, but at least to me that seems preferable over what you
have now.

I am pretty sure the market place would accept those implementations
anyway, much like the marketplace would not accept implementations that
return 42 for 1 div 0.

Peter


> -----Original Message-----
> From: talk-bounces at xquery.com [mailto:talk-bounces at xquery.com] On
Behalf
> Of Michael Kay
> Sent: Thursday, February 02, 2006 2:53 PM
> To: 'John Snelson'; 'David Carlisle'
> Cc: talk at xquery.com
> Subject: RE: [xquery-talk] XQuery error codes and rewriting
> 
> 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
> >
> 
> 
> _______________________________________________
> talk at xquery.com
> http://xquery.com/mailman/listinfo/talk