Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Early Draft Review: XQuery for Java (JSR 225)
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
