XQuery error codes and rewritingMichael Rys mrys at microsoft.com
Thu Feb 2 13:40:08 PST 2006
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.... Michael > -----Original Message----- > From: http://xquery.com/mailman/listinfo/talk [mailto:http://xquery.com/mailman/listinfo/talk] On Behalf > 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 to > >> fully comply, but at least to me that seems preferable over what you > >> 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 doesn't > > 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 database > > 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, and > > if you > > look at the core specs such as XML itself and XSLT, even the most minor > > infringements of the spec give a product a lot of flak. For many of us > > therefore, it's very important that the spec spells out exactly what is > > 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format