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 ]

Ken,

Ken North wrote:

>If we pass strings between XQJ clients and XQuery servers, developers who've
>been processing SQL using C++, PHP, Perl, and Python will often choose to
>support XQuery by adapting existing scripts or classes.
>
>  
>
What do you mean by XQJ client ? Is it the driver, which implements the 
XQJ API, takes the queries and sends them off to the server ?
Or do you mean the code written by the XQJ user ?

I think the user should be able to choose what to pass to the XQJ driver 
(or client) - be it strings for compatibility, or trees for sanity reasons.

The driver can then do fancy things in its executeUpdate or executeQuery 
implementation which should not be of concern to the user.

>On the other hand, if an XQJ client must emit abstract syntax trees (serialized
>as Java byte arrays), we'll have to write Java programs for both ends of the XQJ
>client - XQuery server link.
>
>  
>
But that is an implementation choice that is well beyond the scope of 
the XQJ spec, isn't it ?

I am not sure whether one would always choose to transmit the AST, 
because drivers may choose to create something more low-lever than that 
(s.th. closer to "execution plans"). But I am sure that what ever you 
want to transmit, you can generate it nicely from the AST.

Any Java byte arrays can be "serialized" to a sequence of bytes (just 
don't call the "serialize" method, but write something like 
"toMyCustomBLOB()").

cheers,
B.




 

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

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