|
[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, Michael Kay wrote: >>Burak Emir wrote: >> >> >> >>>I just cannot believe that one can seriously want to repeat >>> >>> >>the IMHO biggest design error of JDBC, namely to pass *strings* to >>the library. >> >> >>>This effectively kills all possibilities of static (compile-time) >>>verification of queries, like syntax checking (let alone types). >>> >>>flabbergasted... >>> >>> > >Burak, what kind of interface did you have in mind? Is it the "embedded DML" >kind of interface where query language statements are defined as an >extension to the basic programming language (i.e. a sublanguage)? > > > Indeed, but it does not need to be a proper language extension. A set of classes and interfaces can play this role, by means of abstract syntax. >There were many systems that used that kind of language binding in the 1970s >and 1980s, typically with COBOL and PL/I: the Codasyl DML was based entirely >on this model. When relational systems became popular in the mid 80s >embedded SQL was used with C, but it was overtaken in the market by >"call-level interfaces" that supplied DML statements as strings. > > > People do not like to deal with proper language extensions. Pizza has algebraic types for Java, hardly anybody seems to have noticed. >It's not entirely clear to me why the call-level interfaces won the battle. >I suspect it has something to do with the inconvenience of preprocessing; >perhaps something to do with the difficulty of different standards groups >agreeing on a hybrid language (I seem to remember great political battles >with the Ada/SQL binding); and something to do with the sheer variety of >programming languages that people want to use. Another reason for the >success of call-level interfaces, notably ODBC, was the desire to avoid >committing a client application to a particular vendor's database product at >compile time: there are many benefits in late binding. > > > With algebraic types, it would be possible to build up an abstract syntax tree, which would be passed to the driver before shipping to the database. In Pizza (or Haskell or ocaml or Scala) one would do like this: Var b = Var(); Var authors = Var(); FLOWR( For( b, Doc("books.xml").descOrSelf("bib:book"), /* for $b in doc("books.xml") // bib:book */ Let( authors, b.descOrSelf("bib:author") ), /* let $authors = b // bib:author */ _, _, Return( element("result"), Sequence( b.child("bib:title"), authors ) ) /* return <result>{ $b/bib:title, $authors }</result> */ ) Using abstract syntax is like using the Command design pattern. methods like descOrSelf(..) would construct a new command instance from an old. It might look ugly (and loose popularity), but at the very least you eliminate a range of syntax errors while retaining advantages of late binding, vendor-neutrality etc. Also, this solution is only partial, as things like element names are still strings, not constants - that would depend on data binding. One can add a library which parses strings, and provide a "call-level interface" facade. (I would not call anything that exchanges raw strings an interface, it is rather a decorated IO channel). But there are enough developers who cannot take hunting for syntax errors popping up at runtime any longer, and depriving them of a real interface (like JDBC) seems like a mistake to me. >As a matter of interest, there is continuous pressure (which the WGs have so >far resisted) for a dynamic XPath binding to XSLT - that is, the ability for >an XSLT stylesheet to construct XPath expressions from run-time strings. I >am not in the slightest flabbergasted by this requirement, it seems very >natural to me. > > > But if the interface depends only on abstract syntax (what is certainly possible in Java), the programmer can parse strings himself if he really likes to, and deal with exceptions that arise during parsing. If one deals with strings I believe most database drivers would ship the query string "as is" to the database (because you would not like to duplicate the code to parse the query strings, because strings are already serialized, cause the DB has to handle strings anyway, etc). This causes least work for the driver developer, and most work for the application developer, who has to deal with errors popping up at runtime, and testing syntax of his queries depends on having a running DBMS to answer the queries. >In the case of a Java/XQuery binding, defining the query language as a >sublanguage of Java seems hardly viable. The place for that is in some kind >of higher level tool, e.g. a JSP tag library, or an XML pipeline processing >language. > > > I agree that changing something by adding to Java syntax is an approach with severe shortcomings (and probably not the goal of JSR225), and that higher-level languages and tools can find more elegant solutions. <advertising href="http://scala.epfl.ch">Luckily with Scala there is at least one higher-level language that can interface with Java code.</advertising> But using only strings is clearly the worst one can do. If an application is dealing with XML, it can *at the very least* pass trees to the database. interface. Xquery even has an XML syntax. cheers, Burak 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Cast Your Vote
We need your help – Vote for DataDirect XML Products!
Winners and finalists announced at SOA World Conference in November. 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
|
|||||||||
|
|
| Stylus Studio® Developer Network | Contact Us | Email this page |
| PRODUCTS | TRY | BUY | LEARN | SUPPORT | COMPANY |
 Cart
|
