Altova Mailing List Archives


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

From: Burak Emir <Burak.Emir@----.-->
To: Michael Kay <michael.h.kay@--------.--->
Date: 6/21/2004 12:12:00 PM
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

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.