[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 18:57:33 +0200
• Cc: Bill de hÓra <bill.dehora@p...>, xml-dev@l...
• In-reply-to: <40D91050.6020907@o...>
• References: <20040620080246.RJLE21846.mta08-svc.ntlworld.com@Turtle> <40D6D10F.8010705@e...> <40D720B2.7050004@o...> <40D7FE45.5090808@e...> <40D8B2F6.3020900@o...> <40D8B625.8090009@p...> <40D91050.6020907@o...>
• User-agent: Mozilla Thunderbird 0.5 (X11/20040208)

Bob Foster wrote:

>> Not in my experience. Having access to a syntax tree can be quite 
>> useful.
>
>
> Yes, it can. But the most common use of syntax trees is as a parse 
> result. A corollary in this domain would be if one could read a stored 
> (or user-entered) query and obtain a syntax tree from it. But I didn't 
> get that from the sketched proposal, which seemed to me to be 
> output-only. Granted, given that there is no actual proposal, one is 
> free to attach all sorts of wonderful things one would like to be in 
> it, but it would be good to know what use cases you or others are 
> thinking an OOPified API would address.
>
Here is the beginning sketchy proposal
=== from  http://lists.xml.org/archives/xml-dev/200405/msg00346.html

>With algebraic types, it would be possible to build up an abstract 
>syntax tree, which would be passed to the driver before shipping to the 
>database.
>
=== end

The algebraic types bit does not matter, it really boils down to having 
an ast or a similar representation.

All this started to avoid having only strings.

I don't think asking for use cases makes much sense: you can include
o all use cases of the string based API (as all of this is possible, 
either with the objects, or using some wrappers that parse strings), plus
o having a high-level representation of queries (introspection, 
reflection, (schema?)validation)

It is not obvious to do any of the latter use cases with strings (unless 
you parse them), and good design does not a priori make it more 
difficult to get work done.

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...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Bill de hÓra <bill.dehora@p...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Bob Foster <bob@o...>

• Prev by Date: How It All Goes Wrong (WAS RE: Triplets on the Internet)
• Next by Date: Unsubscribing
• 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