RE: adding addressing capabilities to the DOM

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
may
> 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.

--tyson

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


Can someone explain this point to me?

keshlam@us.ibm.com 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
challenge,
> but DOM Level 2, via mutation events may address these, especially if
Level
> 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.

Francis.

Received on Friday, 21 April 2000 14:27:43 UTC