[
Lists Home |
Date Index |
Thread Index
]
Ken,
Ken North wrote:
>>>>>>>This effectively kills all possibilities of static (compile-time)
>>>>>>>verification of queries, like syntax checking (let alone types).
>>>>>>>
>>>>>>>
>
>XQJ provides a prepared query model with prepared expressions (static analysis
>and execution-time binding).
>
>
>
What you say is quite impossible - maybe I am not clear enough:
the simple static analysis I am aiming at is made by the *Java
compiler*: correct syntax of the query, and possibly some type-checking.
This catches the "easily avoidable errors".
if you have a class FLWOR(For f, Let l, Where w, OrderedBy o, Return r),
it is impossible to mix things up.
If you have a string "for $i = ... etc etc" you can make mistakes and
the compiler will not complain about it.
The best that prepared expressions can get is to throw an exception at
startup - but this is already runtime, and hence not "static" from the
point of view of the Java programmer.
>>>The bottom line, as you said, is that there are many benefits in late
>>>
>>>
>binding.
>
>It's particularly beneficial if you need to write source code to operate against
>disparate data sources, instead of having to pre-process and re-compile each
>time.
>
>
>
I agree completely, some embedding of XQuery into Java via preprocessing
is tedious and does not scale.
>>>>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.
>>>>
>>>>
>
>One common solution for debugging is using a visual, interactive query tool --
>type in a query, execute it, run the same query with your program, and compare
>results. How many visual XQuery tools have been published that accept XQueryX
>or abstract syntax trees as input?
>
>
>
Let us suppose you want to use such a tool: every abstract syntax tree
can be serialized to concrete syntax with no effort.
The point is, before you avoid logical errors in your query, you want to
avoid missing parentheses, typos, and type mismatches.
>>facts:
>>- parsing a query string yields an abstract syntax tree (AST).
>>- if out of laziness, one does not want to agree what would be the best
>>AST for XQuery, one can take XqueryX
>>
>>
>
>Every XQJ application will have to include a parser if it has to pass an AST
>instead of a query string. Why put the burden of parsing queries on every XQJ
>developer instead of the developers who specialize in writing XQuery drivers and
>engines?
>
>
First of all, it depends if you want to allow to pass query strings at
all. You need a parser to the AST from these.
Second, parsing is one of the best understood programming task that exists.
Third, developers get rid of exception throwing / handling for easily
avoidable errors
You are actually asking "why deal with the burden of using the type
system of Java to avoid errors ?"
Well, to do a decent job in designing an interface.
I actually do not understand your point - don't JSRs have open source
reference implementations ? I think the more successful ones do.
If you admit javac as a tool to debug queries, I do not know how many
times it is shipped, 3 million ?
>What about the burden on developers creating performance monitors, test suites,
>SSL auditing tools, and so on? Instead of working with easily-recognized query
>
>
All these tasks become simpler if you do not have to syntax- or type
check queries.
At some point this has to be done, the earlier, the better. With an API,
one can enforce correct queries with a snip of the finger.
>strings, they'll have to deal with queries expressed as syntax trees. Isn't
>readability at the core of why XML is widely-adopted?
>
>
>
No, it is the use of markup and thus *structured* information that makes
XML.
If you will, every piece of software that renders structured information
to a string is forgetting the structure, and thus more low-level.
It is always possible to get from a higher-level to a lower-level: a
pretty-printer can turn an AST into a readable XQuery string (or some
internal binary format, for the efficiency enthusiasts or whatever).
cheers,
Burak
|
