[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: Michael Kay <michael.h.kay@n...>
• Subject: Re: Early Draft Review: XQuery for Java (JSR 225)
• From: Burak Emir <Burak.Emir@e...>
• Date: Fri, 28 May 2004 14:16:22 +0200
• Cc: "'Jonathan Robie'" <jonathan.robie@d...>, xml-dev@l..., jsr-225-comments@j...
• In-reply-to: <20040528091534.BASX13246.mta10-svc.ntlworld.com@Turtle>
• References: <20040528091534.BASX13246.mta10-svc.ntlworld.com@Turtle>
• User-agent: Mozilla Thunderbird 0.5 (X11/20040208)

Michael Kay wrote:

> 
>  
>
>>In Pizza (or Haskell or ocaml or Scala) one would do like this:
>>
>>Var b = Var();
>>Var authors = Var();
>>FLOWR(
>>   For( b, Doc("books.xml").descOrSelf("bib:book"), 
>>         /* for $b in doc("books.xml") // bib:book */
>>   Let( authors, b.descOrSelf("bib:author") ),
>>         /* let $authors = b // bib:author */
>>   _,
>>   _,
>>   Return(
>>       element("result"),
>>       Sequence( b.child("bib:title"), authors )
>>    )  /* return <result>{ $b/bib:title, $authors }</result> */
>>)
>>
>>    
>>
>
>But that's not exactly XQuery, is it? It's a new query language of your own
>  
>
The syntax is different, but I am not sure whether that matters.

Since XQuery has an XML syntax ( http://www.w3.org/TR/xqueryx/ ), one 
can argue that there is a canonical tree representation of each XQuery 
code fragment. Yes, it is a bit bloated, but these things can easily be 
generated by code.

 From trees to algebraic datatypes (or just plain classes whose only 
constructor takes the "right" types) it is only a little step, easy to 
specify and implement. Any XML processing code (be it in Java, XSLT or 
XQuery itself) could construct an XML tree representing a query before 
shipping it to the DBMS via the driver. I don't see why an abstraction 
representation of a program should fail to comply to the language.

>invention. This approach requires a new query language to be designed for
>each host language. You haven't started to address the problems, which range
>  
>
I was mainly concerned with Java, but I think any class-based OO 
language or one with algebraic data-types

>from incompatible syntax for identifiers between the programming language
>and the database, to incompatible semantics for operators like "=".
>
>  
>
The only thing a host language identifier could get bound to is a some 
instance of "XQueryThingie" - they do not interact with database idents. 
It should be database drivers who are responsible for handling these 
things, not application developers!

E.g. in Scala, I could define a function

def $( name:String ):XQueryVariable = Driver.make.XQueryVariable( name );

About operators, you got a point - if I were to use a language that does 
not allow me to redefine operators (such that the construction of 
XQueryThingies gets hidden), then I might run into problems. Like 
$("foo") = $("foo") might compare pointers instead of names.

Again, I did not provide a solution to everything (the string name might 
contain rubbish, which gets processed away or rubbish that makes the 
Driver fail). But these problems are comparably simpler to solve than 
the ones involved in debugging query strings.

>I think this example absolutely demonstrates the difficulties that arise
>with database sublanguages, and the reason they became unpopular.
>
>  
>

What has not changed is that programming languages do not really support 
integration of domain specific languages well.

But I think compiler technology came a long way. In large scale 
projects, one is well aware of advantages of static verification. 
Algebraic datatypes make slowly make their way to the mainstream. I 
think it is only a question of time when also mainstream language will 
come up with things like algebraic types (maybe even Java 1.6 ?).

All this to say, there are better ways today to integrate DSLs like 
XQuery available.

cheers,
Burak

• References:
  • RE: Early Draft Review: XQuery for Java (JSR 225)
    • From: "Michael Kay" <michael.h.kay@n...>

• Prev by Date: RE: Early Draft Review: XQuery for Java (JSR 225)
• Next by Date: XML: logical and/or physical model?
• Previous by thread: RE: Early Draft Review: XQuery for Java (JSR 225)
• Next by thread: Problem with entity expansion and SAX parser
• Index(es):
  • Date
  • Thread