Re: [xml-dev] Early Draft Review: XQuery for Java (JSR 225)

[Burak Emir <Burak.Emir@epfl.ch>]

Ken,

you wrote:

>That's my point -- what happens between an XQJ client (consumer) and an XQuery
>engine/server/provider is relevant to the "strings or not" API discussion.
>
and:

>Assume postText() is an API we use for HTTP POSTs. Someone decides its more
>efficient to use compression instead of sending uncompressed HTML or XML across
>the wire. We decide to use LZW compression and replace the postText() String
>argument with a binary string or BLOB.
>
>How does that API change not affect the format of the data passed between the
>browser (web client) and the web server?
>
An API for HTTP Posts means dealing with wires.

An XQuery is an expression in a domain specific language - there might 
not even be a wire involved.

You think

>Testing and debugging of an XQJ program will be quite limited without connecting
>to an XQuery engine/server.
>
but I do not think this is true - from the use of variables to naming 
conventions, expressions can be dealt with in all sorts of ways. Small 
tests can and should occur at every scale and all every level of 
development.

A developer might choose to write his own "engine" which makes up random 
data or is a wrapper around an SQL client. He will have a hard time if 
he has to deal with strings.


Ken North wrote:

>Rich Salz wrote
>  
>
>>The API implementation can then uncompress.
>>    
>>
>
>Certainly, but the API change has still altered the format of the web page or
>document sent over the wire. Representing XQJ queries as abstract syntax trees,
>instead of as query strings, has a similar effect on the wire format.
>
>  
>
I don't like to repeat myself endlessly, you must know perfectly by now 
that you can turn an AST into a string if desired.

>>In this example it's kinda silly, but  there is no *requirements* that an API
>>    
>>
>expose wire protocol details.
>
>When creating high level APIs, it's certainly not a design goal  to expose lower
>level details.
>
>In theory XQJ and JDBC provide a layer of abstraction over the network
>transport. In practice, altering an API (such as changing the type of arguments)
>can have side effects that ripple down to lower levels (such as the format of
>messages).
>  
>

I think this is quite fundamental. If you *just* want a wrapper around 
network communication with servers as close as possible to JDBC, then 
you do not need much functionality.  But that you cannot call it "XQuery 
for Java".

The point is, a lot of the necessary interfaces and code (a parser, a 
pretty printer, a type checker, a verifier, an optimizer) will be 
written anyway by the guys who write the server (somewhere entangled in 
their code). If XQuery was a high-level API, then
* users of the server product could access this functionality without 
running the server
* server developers could use and test this functionality independent 
from the server, and
* everybody who wants to work with queries on a high level could do so 
without developing his own stuff on top.

>Static query analysis, compile-time type checking, etc. do not preclude coding
>queries as strings -- look at the SQLJ API.
>
But that is a real extension, not an API (it needs preprocessing, 
different syntax etc.). The preprocessor will necessarily parse the 
strings...

>It makes sense to offer an alternative to passing strings, but not a replacement
>for passing strings.
>  
>
That is all I'm saying, but a tree alternative must be completely 
interchangeable with strings - this can make the design of APIs quite 
horrible, so the only sane way to offer both is to make one the *main* 
representation and the other one a convenience thing to create the first.

It really does not make sense to make every XQJ implementation offer 
convenience conversion from trees to strings. And most of our discussion 
carries over to the question "which should be the main representation of 
queries in the XQJ API" ?

Burak