[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Early Draft Review: XQuery for Java (JSR 225)

• To: Bob Foster <bob@o...>
• Subject: Re: Early Draft Review: XQuery for Java (JSR 225)
• From: Burak Emir <Burak.Emir@e...>
• Date: Wed, 23 Jun 2004 11:13:16 +0200
• Cc: xml-dev@l..., jsr-225-comments@j...
• In-reply-to: <40D8B2F6.3020900@o...>
• References: <20040620080246.RJLE21846.mta08-svc.ntlworld.com@Turtle> <40D6D10F.8010705@e...> <40D720B2.7050004@o...> <40D7FE45.5090808@e...> <40D8B2F6.3020900@o...>
• User-agent: Mozilla Thunderbird 0.5 (X11/20040208)

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

• References:
  • RE: Early Draft Review: XQuery for Java (JSR 225)
    • From: "Michael Kay" <michael.h.kay@n...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Bob Foster <bob@o...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Bob Foster <bob@o...>

• Prev by Date: Re: Early Draft Review: XQuery for Java (JSR 225)
• Next by Date: RE: Early Draft Review: XQuery for Java (JSR 225)
• Previous by thread: Re: Early Draft Review: XQuery for Java (JSR 225)
• Next by thread: RE: Early Draft Review: XQuery for Java (JSR 225)
• Index(es):
  • Date
  • Thread