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)
 Michael Kay wrote: >>I really don't understand how one could possibly want >>anything else as an interface for a domain-specific language. >> >> > >Unfortunately, your inability to see that there are two sides to this debate >makes it very difficult to have a reasoned and productive discussion on >this: it tends to polarise people in their existing positions rather than to >encourage them to see the merits in your own point of view. > > > Alright, my bad, I do not want to polarize people - there are more important things to life than XQuery + Java. >You should try to follow the standard rhetorical procedure: analyze the >opponent's arguments, demonstrate that you have understood them, and then >produce counter-arguments, point by point. Asserting that you don't >understand the opposing position gives you no chance of convincing anyone >that you are right. > > > The problem is, (correct me if I am wrong) people do not seem to "buy" that a high-level representation of an XQuery expression keeps all options open while adding this tiny little bit of abstraction can help programmers, debuggers, driver developers, etc. I think I do understand why people believe strings are important, after all JDBC is based on that, there are tons of code that contains query strings, where one can more less read what the query does, strings can be written as-is on a network stream etc. etc. But I am not argueing against allowing to pass strings. My point is that it is more than questionable to use them as the *only* way to pass queries to the XQJ driver (what was called "call-level interface"). This results in the *lack* of a high-level interface which is the real problem. JDBC is a real shame (I hope I am not doing it again). This is all but new. In scsh(the scheme shell), a similar question appeared with regular expressions. It was solved nicely by having S-expressions (= syntax trees) as the interface and offering conversions to and from POSIX regexp-strings. The tree representation can be used to compute regexps(queries?) dynamically and plug them in other regexps. The conversion to POSIX was nice because implementors that want to use a POSIX C-library (an xquery tool?) can do so by just calling the "convert" routine on the regexp tree first. How do you simplify a regexp ? You do tree-traversals, identifying parts that can be simplified. A string, you would need to parse first. I think in languages like C it would be ok to glue strings together in order to build queries (like in the MySQL C API). Even in C, one can mimick OO style (see e.g. the DOM like interface in Daniel Veillard's libxml), but I guess it is not standard enough to make a point about OO programming in C. But does the same hold for Java ? Without having a tree, how would an XQJ implementor make use of the XQuery equivalences described in Jerome Simeon, Mary Fernandez, Phil Wadler's paper "A semistructured monad for semistructured data" ? http://homepages.inf.ed.ac.uk/wadler/topics/xml.html#xquery There are tons of things that one would like to do with an XQuery expression in Java, not just ship them to the database. In some sense, the discussion about analyzers, optimizers, debuggers all makes a case for a having a high-level model of queries. cheers, 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
|
|||||||||
