Hi,
I must admit I have not read all the mails in in this tread, but I hope I
got the point. My € 0.02 on why DOM/XPath is not the solution:
Ad 1: The DOM is not clean data model.
The DOM started as a simple JavaScript model and evolved into the powerful
"almost-the-data-model-for-XML" thing we have today. It's widely deployed,
it's well understood, it's easy, it's working. But it's also ad-hoc, patchy
and not designed for query optimization. Pointer chasing a tree won't scale
beyond a certain limit. At GMD we did the PDOM, implemented optimizations,
found it to scale quite far (we had 500 MB of XML in a PDOM and it was still
working), but there are limits. With today's and future Tera-XML DB's there
must be a better solution.
Ad 2: XPath is not a clean query language.
I must not go into details, but there are errors in the spec. And (in my
private opinion) the "node-set with a current node pointer" approach is a
bottleneck. Functions are bottlenecks, because optimization stop here. A
computational complete language like XSLT/XPath is not the solution, you
simply can't optimize a Turing complete language to the extend you can
optimize a more limited calculus.
Ad 3: Future
For today, XPath/XSLT/DOM is what we have. All of them will have a strong
influence on XML Query, but must not limit its design. There are other areas
which contribute: document repositories, OODBMS, RDBMS, full text retrieval
systems, ... XML is not limited to the DOM-OO way of doing things.
IMHO it is not the way to go to extend what we have (DOM, XPath), but to
build on the experience we gathered using both. XML Query has the chance for
a clean-room redesign (with many lessons learned from DOM/XPath). It should
not be wasted by perpetuating design flaws in Xpath/DOM.
Regards,
++im
--
ingo.macherius@gmd.de
GMD-IPSI, Open Adaptive Information Management Systems Group (OASYS)
http://xml.darmstadt.gmd.de/