Altova Mailing List Archives

RE: adding addressing capabilities to the DOM

From: Tyson Chihaya <Tyson@-----------.--->
To: "'francis@-------.---'" <-------@-------.--->, www-dom@--.---
Date: 4/21/2000 12:24:00 PM
It seems to me that Joe is speaking more to the case where the DOM is
completely in memory.  As someone who has implemented a DOM on top of a
database, I have to agree with Francis here and say that providing a way to
delegate responsibility for evaluating XPaths (or other types of queries in
the future) into the implementation is vital.  In our implementation, we
take XPath queries (on any element node) and convert them into SQL
statements (and then create nodes that belong to the document on the way
back).  I'm not sure how we could have accomplished this otherwise.
Francis' point about not building a database query language into a database
engine is a good one.

I think I agree with Joe's third point:

> 3) It is unclear that a querying API actually belongs inside the DOM at
> all. One can argue that querying applies across document models -- one
> might wish to apply a query to a SAX stream, for example -- and thus it
> want an independent API, which DOM implementations could support but which
> might also be available in other contexts.

..which I think is saying that we might want a generic XPath API that DOM
implementations could support.  Although it almost seems as if an XPath API
would dictate that results be returned in a certain way-- as DOM nodes, as
SAX events (I'm really unclear about how a query interface for SAX would
work--sounds more like a filter than a query), etc.


-----Original Message-----
From: Francis Norton [mailto:francis@r...]
Sent: Wednesday, April 19, 2000 4:09 AM
To: www-dom@w...
Cc: Xml-Dev@Xml. Org; www-dom@w...
Subject: Re: adding addressing capabilities to the DOM

Can someone explain this point to me?

keshlam@u... wrote:
> 1) It is not particularly difficult to implement querying as an operation
> upon the DOM, rather than within the DOM. (Liveness issues are a
> but DOM Level 2, via mutation events may address these, especially if
> 3 adds "listener groups" as has been proposed.)

I seen this point made before, normally as a response to the suggestion
that xpath be included in a future build of the DOM.

But it seems to me that there couldn't be a worse function to build
"upon", rather than "within" the DOM. Whatever the cost of crossing the
component boundary, will be multiplied by the cost, potentially, of
traversing the entire document data structure. Additionally, if any kind
of indexing is implemented then you are effectively replicating the
document's tree structure and values outside the DOM.

I'm not an expert in this area, so please tell me if I've misunderstood
the issues, but it strikes me as making as much sense as the case for
not building a database query language into a databse engine.


This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.