Re: Early Draft Review: XQuery for Java (JSR 225)
Burak Emir wrote: > There are tons of things that one would like to do with an XQuery > expression in Java, not just ship them to the database. In some sense, > the discussion about analyzers, optimizers, debuggers all makes a case > for a having a high-level model of queries. Your argument seems to boil down to the idea that compilation will always have certain advantages over interpretation, a widely held view. People who lived through the history of embedded SQL are unlikely to be convinced, as you are just echoing the arguments made decades ago in the SQL context - and string APIs by and large won out - in part because they can proliferate most rapidly in a wide variety of host languages. But even in the abstract, the counterpoint is that interpretation will always have certain advantages over compilation. For example, a query engine is by nature an interpreter, no matter what you put in front of it. Engines that require time-consuming optimization passes tend not to succeed commercially, so providers learn to deliver good performance in real time. The best argument for compilation is strong typing and early error detection, but the relative value of this vs. good, continuous testing is still debated in circles that favor interpreted languages. And strong typing doesn't address the real problem at all - that the database schema can change, invalidating existing programs that use it. Recompilation and/or retesting of all such programs is required in either case. Last but not least, JSR 225 presents a proposal for a string-based API. Where is the proposal for an API requiring language changes? Bob Foster http://xmlbuddy.com/
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