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