[
Lists Home |
Date Index |
Thread Index
]
> >>>>> 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).
> > 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.
> >> 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?
> 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?
What about the burden on developers creating performance monitors, test suites,
SSL auditing tools, and so on? Instead of working with easily-recognized query
strings, they'll have to deal with queries expressed as syntax trees. Isn't
readability at the core of why XML is widely-adopted?
======== Ken North ===========
www.WebServicesSummit.com
www.SQLSummit.com
www.GridSummit.com
|
