[XQuery Talk Mailing List Archive Home] [By Date] [By Thread] [By Subject] [By Author] [Recent Entries] [Reply To This Message]

XQuery error codes and rewriting

Michael Rys mrys at microsoft.com
Thu Feb 2 13:40:08 PST 2006

  XQuery error codes and rewriting
Dana is correct. Except for that the latest optimizing hardware
processors actually do stuff that make C and Java programs result in
wrong results according to the language semantics....


> -----Original Message-----
> From: http://xquery.com/mailman/listinfo/talk [mailto:http://xquery.com/mailman/listinfo/talk] On
> Of Daniela Florescu
> Sent: Thursday, February 02, 2006 1:21 PM
> To: Michael Kay
> Cc: http://xquery.com/mailman/listinfo/talk; 'Peter Coppens'; 'David Carlisle'; 'John Snelson'
> Subject: Re:  XQuery error codes and rewriting
> Michael,
> this has nothing to do with SQL and databases per se. It has
> something to do with do optimizations.
> The kind of optimizations and rewritings a database does for
> its declarative languages (and that make this entire industry so
> useful) are inherently in tension with a 100% specified semantics
> of such languages.
> Imperative programming languages like Java and C have a
> very clear semantics, tightly controlled, but as a result
>   they are limited in terms of the rewritings and optimization
> they can do while being strict about the semantics.
> In XQuery we defined the semantics in such a way that it leaves
> the door open for some optimizations that we knew in advance
> that will be useful (like shortcircuiting quantifiers).
> But there are hundreds of other rewritings that people will invent
> for XQuery over time, that we didn't anticipate when we wrote the
> semantics.
> Such implementations will not be conformant at 100%. But that's fine.
> If they give users an order of magnitude better performance they'll
> buy it despite that.
> The tension is between determinist semantics and optimization,
> and I am not aware of a good answer for this tension.
> Best regards,
> Dana
> On Feb 2, 2006, at 12:39 PM, Michael Kay wrote:
> >> Was it never considered to remove that paragraph altogether?
> >>
> >> I am sure that in that case some implementations will never be able
> >> fully comply, but at least to me that seems preferable over what
> >> have now.
> >
> > There are one or two people on the working group who incline to this
> > kind of
> > position, that when it comes to the complicated edge cases, it
> > matter what we say because implementors will do their own thing
> > anyway. This
> > kind of thinking tends to come, I think, from people from the
> > community where the expectations that products will conform 100% to
> > SQL or
> > any other standard are historically quite low. On the whole, though,
> > the
> > level of conformance of products in the XML space is much better,
> > if you
> > look at the core specs such as XML itself and XSLT, even the most
> > infringements of the spec give a product a lot of flak. For many of
> > therefore, it's very important that the spec spells out exactly what
> > allowed and what isn't, even if this sometimes means being more
> > liberal than
> > one would like for 100% interoperability.
> >
> > Michael Kay
> > http://www.saxonica.com/
> >
> >
> > _______________________________________________
> > http://xquery.com/mailman/listinfo/talk
> > http://xquery.com/mailman/listinfo/talk
> _______________________________________________
> http://xquery.com/mailman/listinfo/talk
> http://xquery.com/mailman/listinfo/talk


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.