Burak Emir wrote:
> 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.

It's true there may be no wire involved for every XQuery application. But if an
XQuery engine is embedded in a standalone Java program, a developer might choose
to use streams, consumer/producer classes, or reader/writer classes instead of
using the XQJ API.

The overhead for XQJ-style programming (drivers, connection pooling, registering
data sources with JNDI, maintaining state, caching) is necessary for
distributed, multi-user computing. Why would you incur that overhead if you are
deploying in a single-computer environment?

> 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.

If you look at the Java API for some of the existing XQuery implementations
(Galax, IPSI-XQ), they don't seem to have a problem dealing with query strings:
http://www.sqlsummit.com/XQueryProv.htm

> 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" ?

Instead of revising the XQJ API, it's probably better to have a separate
specification for alternative representations of queries. (That was there's a
separate SQLJ specification, instead of shoehorning early checking of queries
into the JDBC API.)