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:

>
> 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.

cheers,
Burak




 

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

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