OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Early Draft Review: XQuery for Java (JSR 225)

[ Lists Home | Date Index | Thread Index ]

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

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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS