Ken North wrote:

>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?
>
>  
>
Testing, using the connection pooling/caching/data sources of another 
(legacy) API.

Offering the same interface to query databases as well as in-memory XML 
(this has of course nothing to with databases).

>>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
>
>  
>
Sorry, but I did not find much useful information at that address - do 
they even have a publically available Java API ?
A quick google search did not bring much on this - so I am taking your 
word for it.

But Galax, IPSI never aimed to provide a general-purpose Java API.

If XQJ really should be just an XQuery version of JDBC, with a 
predetermined, low-level interface, it is wasted potential.

For sure such a JDBC remake has some use, but it is not even close to 80/20.

>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.)
>
>  
>
It's certainly not shoehorning, just a clean design choice that involves 
more abstraction (and possibly, clumsier syntax).

We are all free to ignore innovation, and to see XQuery as being just a 
database thing - maybe XQJ programming should not be compositional, 
correct, easy.

How many Java APIs do we have that offer some sort of DOM, some sort of 
XPath ? How many languages and tools do you need to use to implement a 
web service that compares a user-submitted XML document with one in a 
database, and formats the output in valid XHTML ?

Maybe database companies and consultants make good money on sloppy work, 
but it does not change the fact that this mentality of having hundreds 
of badly-matching too-special-purpose APIs is an obstacle to good 
software development. 

Burak