[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)

• To: "'Jonathan Robie'" <jonathan.robie@d...>,"'Burak Emir'" <Burak.Emir@e...>
• Subject: RE: Early Draft Review: XQuery for Java (JSR 225)
• From: "Michael Kay" <michael.h.kay@n...>
• Date: Thu, 27 May 2004 23:00:09 +0100
• Cc: <xml-dev@l...>
• In-reply-to: <40B61E2D.70902@d...>
• Thread-index: AcREC7Z6BQqL/VtkTjOar2ylShYQtQAJ+x2g

> 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)?

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.

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.

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.

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.

Michael Kay 

• Follow-Ups:
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>

• References:
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Jonathan Robie <jonathan.robie@d...>

• Prev by Date: Re: Early Draft Review: XQuery for Java (JSR 225)
• Next by Date: RE: Elliote Rusty Harold: W3C XForms The Next Big Thing?
• Previous by thread: Re: Early Draft Review: XQuery for Java (JSR 225)
• Next by thread: Re: Early Draft Review: XQuery for Java (JSR 225)
• Index(es):
  • Date
  • Thread