W3C home > Mailing lists > Public > www-ql@w3.org > July to September 2002

RE: Could XQuery replace the W3C DOM?

From: MStefanescu <mmstefan@attbi.com>
Date: Mon, 16 Sep 2002 13:47:47 -0400
Message-ID: <3D861943.4A43C30@attbi.com>
To: www-ql@w3.org

In response to the original question (i.e. if XQuery could completely
replace W3C DOM), my answer is: while in some cases -yes, in general -

Several posts justified why the answer could be yes, at least for some
applications. I'll just justify why the answer is no, for the general

I observe that the two serve different programming paradigms: DOM -
imperative programming and XQuery - declarative programming, each with
merits and pitfalls. Furthermore (and related), they provide different
levels of abstractions. I think that the distinction between programming
paradigms is important. The vast amount of programming is imperative,
but diverse in syntax detail (C/C++, Java, C#, EcmaScript, etc.).
Presumably, DOM satisfies the needs of a commanding programming majority
in a natural way: a set of interfaces, implementable in any of the
popular programming languages. The approach usually provides a low level
of abstraction (for instance, the navigation of a tree is very explicit,
and consequently, it can be tedious). The implementation of type safety
(as much as supported by the host language) is straightforward. While it
is much more tedious to program (hence error prone), with careful
programming, it can render better performance for specific cases
(optimization depends on both the schema and the instance; an optimized
query usually is based on knowledge of the schema only).

In contrast, there are some penalties in grafting something like XQuery
onto all the existing imperative programming languages. For instance,
compile time query optimization in such a hybrid language would not work
without making the respective compiler knowledgeable of XQuery, in
effect changing the host language. (Actually, you could do it easily in
any language which supports powerful macros, like Lisp). Runtime query
compilation has either a performance penalty (if done at the time of
query execution) or it is odd (if done at some initialization time).
Moreover, query optimization is generic. Implementation of type safety
(other than marginal) is also a significant problem.
Of course, the great benefits of using XQuery (readability, robustness,
ease of programming, painless generic optimization) are still relevant.

In summary, I think that both DOM and XQuery have its uses; overlaps
will exist and only specifics of the application will decide what is the
best approach for the job.

    Mugur Stefanescu
Received on Monday, 16 September 2002 13:48:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:15 UTC