Making the DOM a more useful libaray API (was Re: The DOM is not a model, it is a library!)

----- Original Message -----
From: Stephen R. Savitzky <steve@rsv.ricoh.com>
To: DOM Mailing List <www-dom@w3.org>
Sent: Wednesday, October 06, 1999 12:32 PM
Subject: Re: The DOM is not a model, it is a library!

> That's why I'd like to see a specification that's general enough to cover
> the widest possible range of applications, simple enough to provide basic
> functionality without dragging in the rest of the DOM's baggage,
efficiently
> implementable in the most obvious way, and explicitly extensible so that
you
> can add what your application needs without raising the spectre of
> portability.
>
> It's not hard to do this.  You can base the whole Node API on the InfoSet,
> and do all navigation using _unidirectional_ iterators and tree walkers so
> that you never have to represent trees at all, and can throw away nodes
> after you've seen them for the last time.  Bidirectional iterators and
> generic tree walkers would be optional.  There was a draft of the DOM that
> was somewhat like this, returning a NodeIterator instead of a NodeList
> wherever it made sense; it's what I rebuilt my application around.

We discussed this general topic today on the DOM working group
teleconference.  Obviously we'll never fully come to a meeting of the minds
here, but we would *REALLY LIKE* to make whatever changes to Level 2 that we
can to make the DOM more extensible .... and to work with the InfoSet people
(I guess they're back in the core XML WG now) to make Level 3 and beyond of
the DOM completely congruent with the InfoSet.

Forgive me for not having time to go back through all the discussions over
the last week to pull together the various suggestions, so I'd appreciate it
if Stephen Savitsky and the others who've contributed to these threads could
help refresh my memory.

Some ideas ... and please note that I'm speaking for myself here, not the WG
... that come to mind include:

- Making the "space" of names and codes reserved to the DOM explicit so that
proprietary extensions do not collide with future DOM Levels.

- Adding appropriate wording making it clear what level of
interoperability -- across systems, languages, compilers/JVMs, etc. -- one
can reasonably assume for DOM applications.

- Perhaps making the hasFeature() mechanism more fine-grained, or allowing
implementor collaboration to define common subsets and extensions to the DOM
to be identified and named in a way accessible by hasFeature().  This is an
attempt to address Stephen Savitsky's idea that different subsets of
features are appropriate in different application areas, so something like
"LITESERVER" might be passed to hasFeature() to see if the implementation
supports only non-live NodeLists, (or perhaps no NodeLists or TreeWalkers,
only NodeIterators), unidirectional iterators, etc.  The challenge here is
to come up with a mechanism that allows people to get together and define
and query for support of useful subsets of the DOM and/or agreed-upon
extensions to the DOM without having the W3C getting involved.  I'm wide
open to suggstions here.

Please add any other suggestions, or suggest refinements to these, or any
other tweaks to the Level 2 spec that could help address the issues raised
in this thread. Please note that Level 2 is in the Last Call period so we're
not going to make *major* changes ... and the more concrete and specific the
suggestion, the more likely it is to be carefully considered and adopted.

In short, let's agree to disagree on the more philosophical questions, but
agree to put aside these disagreements and work on some very pragmatic
refinements of the DOM Level 2 spec!

Thanks,

Mike Champion

Received on Wednesday, 6 October 1999 14:12:44 UTC