[
Lists Home |
Date Index |
Thread Index
]
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
|
