Re: The DOM is not a model, it is a library!

>face the wrath of hundreds users when live nodelists turn out to
>be hopelessly inefficient, even though they were told up front that _this_
>implementation is specialized and that getElementsByTagName is deprecated.

If _your_ users react this way,  then this is probably a stong hint that you
either (a) haven't explained the issue well enough, or (b) made a bad guess
about their needs and should consider retuning your implementation.

An API -- even strict compliance with an API -- only promises functionality, not
performance. The latter is considered a quality-of-implementation issue, and is
definitely subject to tuning for specific scopes of applications. One of the
concerns of the DOM WG is that it be possible to support these behaviors
efficiently across a range of implementations, but the DOM can't promise that
all implementations will be efficient, or even mandate that they should be.
There will never be a single universal DOM implementation; there will be many
good ones optimized for different tasks.

Minimal storage space may not be compatable with best performance. To take an
absurd example, consider a model which is singly-linked.  It could implement
getParent by searching downward from all the root nodes until it finds a node
which has the current node as a child. Obviously performance will be abysmal,
but code written to the DOM API will run, and (eventually) generate the expected
results, and that's all that DOM compliance promises.

As a more realistic example, consider a "proxy DOM" -- a DOM API wrapped around
a storage representation which bears no resemblence to the DOM's structure at
all. Allowing DOM access to a database would be a perfect example of this. It
may be inefficient, especially when compared to the storage system's native API,
and if performance is your primary goal you might not want to go this route. On
the other hand, it may be a good convenience feature for programmers, and may be
better than the alternative of copying the data into a separate DOM,
manipulating it there, and then copying it back.

The DOM is interfaces. It's only interfaces. What's going on behind those
interfaces doesn't matter to the DOM as long as the expected results come back.
It _may_ matter to the DOM user -- but sticking to the standard interfaces
serves their needs by allowing them to switch to another DOM if yours doesn't
perform well enough, or letting them move their code to yours if your
performance or features are a better fit than what they have been using.
Departing from the DOM hinders that ability to move between implementations.
There may be reasons to do it, but the farther the departure the less
interchangability.

Note that if the right answer for you is to provide only DOM Level 1 compliance,
that's legitimate. The hasFeature tests allow applications to check what's
supported and Level 2 applications can either refuse to run or attempt to work
around the limitations. This is also why much of Level 2 is broken out into
optional modules -- if you've got no use for CSS support or the Traversal tools
you can decline to implement them. It's up to you to understand the needs of
your user community and the impact on your market; if you guess wrong, they'll
tell you and/or go elsewhere.

The same tradeoff exists for subset not supported by hasFeature. One model I've
experimented with implements only a few of the most essential DOM interfaces. I
don't claim it's a DOM, and it certainly won't run all DOM applications... but I
can promise the user that code written against it will run on a DOM as defined
by Level 1, Level 2, and (given the WG's caution about backward compatability)
probably future levels.

Think of the DOM as a tool, like a parser or compiler. I should be able to run
my ANSI/POSIX C code though any C compiler and get the same results, though
performance may vary wildly. I should be able to run my pure DOM code against
any DOM and get the same results, with the same caveat. Individual compilers
often extend the libraries; that's equivalent to adding custom methods to DOM
objects or adding additional objects outside the DOM itself. Code that uses
those features may not be portable, but code that uses only the formal
definition is unaffected. Significantly changing the syntax or semantics of C
itself, or the abstract model presented by the DOM, runs the risk of causing
breakage in both directions and probably deserves a warning to the user and a
new name in recognition of that departure.

______________________________________
Joe Kesselman  / IBM Research

Received on Wednesday, 6 October 1999 10:29:28 UTC