OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Early Draft Review: XQuery for Java (JSR 225)

[ Lists Home | Date Index | Thread Index ]


Bob Foster wrote:

> 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 

Again: I am not making a case for embedded SQL. I am argueing for a 
different representation of the query when passing it to the interface.

A class XQueryExpression that I can build up from other 
XQueryExpressions if you will.

I did not and I do not believe that one can compile every query (this 
would fail to build queries at runtime), I said the plain vanilla Java 
compiler and the plain vanilla class-based Java type system should be 
able to check your code that constructs XQueryExpressions, i.e. by 
having concrete subclasses for For, Where, OrderedBy, XPath expressions...

> 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?
Yeah, see it's only string based. What happens, if I have a fixed way of 
building queries ? I get a string from a textfield, and I am searching 
for all books by that guy. PreparedStatement seems to do the trick. But 
what if I want to *nest* this query in another one ? I have to use 
string concatenation. Instead, it would be nice just to call the 
constructor of some XQueryExpression, and pass the existing instance of 
XQueryExpression as an argument.

It's still interpreted, it's just another representation, one that uses 
objects instead of strings.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS