[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)


xquery engine java
Ken North wrote:

>>The benefit of a string interface is that it gives looser coupling between
>>systems. The benefit of a custom syntax/protocol is that it gives earlier
>>validation. The experience of the last few years is that loose coupling
>>tends to win, across most application scenarios. Hence XML.
>>    
>>
>
>My comment was the argument about "strings or not" is moot (as in "deprived of
>practical relevance") when we're talking about stored queries -- as opposed to
>ad hoc, single-execution queries.
>  
>
But nobody talked about "strings or not" for what happens between client 
and server. The programmer should not be concerned at all with these 
implementation choices.

>For single-execution queries, the XQJ client program passes the query string to
>the driver for each execution of the query (or the abstract syntax tree
>alternative).
>
>For repetitive, stored queries, we don't pass a string each time so we don't
>parse the query repetitively. We parse it once, and on subsequent executions of
>the query, we pass execution time parameters.
>
>  
>
This does not impose any constraint on how you represent queries and how 
the programmer passes them to the interface.

It rather defines what should happen upon 
"preparedQuery.setArgument(1,foo); "

>>The benefit of a custom syntax/protocol is that it gives earlier validation.
>>    
>>
>
>In the case of  [JDBC | XQJ], we can use strings and delegate validation to the
>[SQL | XQuery] engine. We can use prepared statements (JDBC) or prepared
>expressions (XQJ) as a separate, distinct process before we execute a query.
>That gives us pre-execution validation and exception checking. (Pre-execution in
>this context is a reference to query execution, not program execution.)
>  
>
Sure you (the xquery server implementors) can, but the user who wants to 
validate them without a server cannot. Same for testing, debugging, 
pretty-printing,  <insert what="high-level programming activity" 
where="here"/> ...

Ken North wrote also:

>The XQJ client uses a driver to connect and submit queries to an XQuery engine.
>A typical scenario is a client-server architecture with the query engine running
>on a separate machine from clients that submit queries across the wire (in this
>case XQJ clients). The XQuery server and XQJ client execute on separate
>computers, or in separate processes if they reside on a single computer.
>

Since the XQJ client is already a separate process, why not do some 
validation here ?

More to the point, should the XQJ API support different implementation 
choices or use low-level representations that dictate only one?

>Any Java byte arrays can be "serialized" to a sequence of bytes (just
>> don't call the "serialize" method, but write something like
>> "toMyCustomBLOB()").
>  
>
>
>1. The client (XQJ or otherwise) has to be pass the query to the XQuery engine
>using a mutually-understood format. If Java clients are not passing query
>strings, then there needs to be a spec for queries represented as CustomBLOBs.
>
>  
>
the CustomBLOB was just an example to say that the XQJ implementers are 
free to choose what they want. Therefor what happens between client and 
server should really not have any influence on the API.

>2. Someone building an XQuery server will often prefer a language-neutral
>solution for servicing clients. Come one, come all -- Java clients, C#, Perl,
>whatever.
>
>  
>
It's off topic, but I agree - but then I also think every vendor will 
nevertheless supply his own XQJ implementations for Java (and the Dotnet 
equivalent). Language-neutral can mean a binary spec or an UTF-8 string, 
it does not necessarily mean "you must use query strings as is".

>3. If we must choose between elegance and interoperability, my vote is for
>interoperability. SOAP and XML RPCs emerged in part because of interoperability
>issues with COM+ and CORBA. XQuery servers, like HTTP servers, will serve a
>broader audience if they employ language-neutral and platform-neutral
>technologies.
>  
>
Sure, but the XQJ API is completely independent from these issues. COM+ 
was never intended to be interoperable, and CORBA is heavyweight because 
it wants to solve the problem of interoperability. Lightweight stuff 
like SOAP and XML RPC have the advantage of being XML, hence specifying 
character encodings or escaping unicode characters in a document is 
standardized and easy.

With XQJ, the aim is to provide an interface to XQuery for programmers. 
Programmers like interoperability, they do not want to care whether the 
server has 8 registers or 32 and what the endianness is. They like to 
parse COBOL or ABAP query in ASCII  and turn it into an XQuery (parse 
tree). They like to have a single place where column (or element) names 
are kept. They like to encapsulate everything database specific in a 
high-level API, so *their* users don't even think of XML and queries 
anymore. All this is made easy with a tree-like interface.

cheers,
Burak

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.