RE: adding addressing capabilities to the DOM

[inline]
>
> Before folks go too far on this:  Note that the DOM Level 2 "traversal"
> chapter was, in fact, originally designed as a first step toward richer
> queries, and is arguably better suited for this purpose than the NodeList
> API.
>

By the NodeList API, I assume you mean:

NodeList getNodes(scheme, expression)  ??

Because I actually find *this* better suited for navigation/traversal than
the Traversal API simply because I don't have to write as much code to
achieve the same results. XPath is much more abstract.

> Also, keep in mind:
>
> 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 think the real issue here is to promote a standard interface for
performing such operations. I may seem like an XPath fanatic, but I truly
believe that it will become the dominate mechanism for performing common
data extraction routines regardless of the API (see next point). It's so
much simpler to use XPath to perform these tasks than to write the
equivalent DOM code. And we all know that simplicity always wins. What I
want is a standard way to accomplish this regardless of the DOM
implementation.

Based on my assumption that most DOM code is eventually going to use XPath
to some degree, not adding this API makes it _impossible_ to write
implementation independent code. Doesn't that go against what the DOM is all
about?

> 2) It probably makes sense to allow time for the XML Query
> Working Group to
> produce unified semantics for XML Querying before designing a standardized
> query API, to reduce the risk of creating conflicts with those semantics.
> Otherwise, why have a query WG?
>

The big issue here is time. If the concern is about creating a single API
that addresses different querying schemes, I'd be satisfied with an XPath
specific function. One for XQL can be added in DOM Level 7, once it's ready.

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

Today we have XML standard APIs for consuming/generating Infosets (DOM/SAX).
XPath defines a concrete syntax for addressing Infoset subsets and is not
tied to any API as you suggest. XPath _IS_ the "independent API" that you're
referring to above that "DOM implementations can support but which might
also be available in other contexts..." as you put it.

XPath can definitely be applied to both the DOM and SAX APIs to greatly
simplify processing (and already has for that matter). Because of this, what
we really *need* is a standard interface for bridging the technology with
each API, whenever it makes sense. I would eventually hope for the same kind
of integration with SAX but the DOM benefits are more immediately obvious.

-aaron

Received on Monday, 17 April 2000 22:11:59 UTC