Lists Home |
Date Index |
- To: Ken North <firstname.lastname@example.org>
- Subject: Re: [xml-dev] Early Draft Review: XQuery for Java (JSR 225)
- From: Burak Emir <Burak.Emir@epfl.ch>
- Date: Thu, 01 Jul 2004 16:05:21 +0200
- Cc: email@example.com
- In-reply-to: <002b01c45f20$18c23730$1601a8c0@DURANTE>
- References: <Pine.LNX.4.44L0.firstname.lastname@example.org> <002b01c45f20$18c23730$1601a8c0@DURANTE>
- User-agent: Mozilla Thunderbird 0.5 (X11/20040208)
>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.
>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.
>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
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
>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
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
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
>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" ?