Altova Mailing List Archives

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

From: Burak Emir <Burak.Emir@----.-->
To: Bob Foster <bob@------.--->
Date: 6/23/2004 9:10:00 AM
Bob Foster wrote:

> The main advantage of your proposal, OOP orthodoxy aside, seems to be 
> in preventing syntactically incorrect queries. Given that this is an 
> API to XQuery, however, the user probably already has some knowledge 
> of XQuery syntax...and has the benefit of being able to test the 
> queries with specific values in a standalone XQuery implementation. On 
> the con side, building up expressions using individual For, Where, 
> etc. classes is certainly going to be clumsier.
Well, you can also plug queries together like legos - orthodox or not, 
it is not the same as ripping apart and glueing together strings.

> AFAIK, one could implement what you propose on top of the JSR 225 
> proposal (when evaluated, the objects would simply output a string), 
> but I don't think I'd want to use it. That's not a technical 
> judgement, though; just a matter of taste.
I agree it feels clumsy at first. But then, in an application one builds 
queries in a dedicated package, and one will appreciate resuing certain 
"typed" building blocks over the typical cut-and-paste madness.

Do you remember what happens with your SQL statements and queries if a 
column was added or renamed after you wrote your program ?

You will have to scan your entire program for occurrences of this table, 
check whether there was a SELECT * FROM or an INSERT INTO which does not 
work with the old set of column names. A bit of OO abstraction could 
have certainly helped also JDBC.

Evangelism aside, it is not an either-or question. Some library built on 
top of the string-based API (like Squiggle) is not likely to implement 
all functionality you get with XQuery. Rather, some users (if 
knowledgeable of the benefit) will reimplement their own things on top 
of the string-based API *over and over again*. For me this seems like a 
weak design (and here it becomes a technical judgement).

Instead, focussing on trees, and offering a string-based API for 
"compatibility" reasons, seems better since it keeps all doors open - 
hence a good design.



These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.