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, you wrote: >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. > and: >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. You think >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 development. 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 >level details. > >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 >messages). > > 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 for Java". 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 strings... >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" ? 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
|
|||||||||
