Explaining DOM oddities

[Please note that this is COMPLETELY MY PERSONAL OPINION,  and not any kind
of official pronouncement from the WG]

It has taken me several days of digesting the comments and suggestions on
this list to recall WHY we on the DOM working group have done some of
things we've done that are contrary to common practice and the commandments
of the Design Patterns book.  I've made mention of a nightmarish web of
constraints that we are tangled up in, but since you've all been so helpful
lately, maybe it's time to clarify some of those constraints so that you
don't waste time coming up with perfectly reasonable but non-adoptable
suggestions.  

First, the names should be simple, short, informative, work within various
script languages' rather lame scoping rules, make correct use of SGML
teminology, be consistent with common usage, but not conflict with actual
Dynamic HTML implementations. Ha ha ha!   Don't get me started .... So, if
you wonder why something like tags() in IE4's API got turned into
getElementsByTagName() in the DOM, think about these constraints for
awhile.  Needless to say, "short" often loses out ...

Second, the API must be generally backward compatible with Netscape
Navigator and MS Internet Explorer for obvious reasons.  Strictly speaking,
we've tried to be compatible with "DOM Level 0", which is defined as that
which was common between Navigator 3.0 and IE 3.0.  This leads to some
counter-intuitive constraints; for example, several concrete element types
in HTML already have array semantics in the browsers' APIs. This prevents
us from allowing the square bracket syntax for getting at children in
ECMAScript;  e.g. mychild = mynode[i] will not work.  Thus, as I understand
it, we MUST have a "HAS A" relationship between an Element and the
collection of its children, not an "IS A" relationship between Element and
a CompositeNode base class. 

Third, (although I realize some of you apparently disagree) we believe it
is critical that the DOM "language neutral", i.e., that outside of
unavoidable "language binding" issues, it be available in principle from
widely-used programming languages like Java, (but including C/C++), script
languages like ECMAScript (but also VBScript, Perl, Tcl, etc.), CORBA (but
also COM), and anything else someone wants to write a binding for (e.g.
Eiffel, Python, Scheme, etc.). This means that we can't use certain
features of supported by many languages (such as multiple inheritance, or
various types of name overloading) that sophisticated designers are used to.

Fourth, the API itself should be as small as possible, yet for various
political and PR reasons, we need to accomodate a wide range of "paradigms"
for how documents are navigated and manipulated.  That is, we can't say
"Here is the ONE TRUE DOM PATH, thou shalt do it our way!" because we want
the DOM APIs to be used in real life rather than becoming "zealotware".  We
have to make it easy for script writers to use the DOM in the way they are
used to, yet give Java programmers access to techniques they are used to;
and since we all work for organization that intend to profit from their DOM
support, we try hard not to inconvenience our own customers in their
migration to the DOM.  

This is why the NodeIterator class is defined the way it is:  some will
want to navigate DOM documents as via collections with their array-like
syntax and semantics (some will prefer using numerical indexs, and some
will demand "associative array" name-based lookup); and others will want to
use iteration semantics.  We don't WANT to have separate methods that
return indexed arrays, associative arrays, and iterators all over the
place, so we tried to invent an abstraction that covered all of these.  It
may not be the most elegant piece of software design that you ever saw; it
was quite literally invented by a committee; it certainly has flaws that we
would like help correcting ... but I for one find the idea of a small API
with a single highly-overloaded navigation class preferable to a an API
that's bloated by multiple versions of many methods that simply return
different types of navigation objects.  

One may disagree, but please consider our constraints in the context of any
suggestion -- we can't simply say things like "DOM documents are trees!
Tell your customers to learn to use tree navigation", or "50 gazillion
VisualBasic and JavaScript developers can't be wrong! Use indexed
collections for everything" even though either would make the DOM API more
simple and elegant.


I hope this helps explain some of the background for the way the DOM API is
drafted today, and why some perfectly reasonable comments and suggestions
from this mailing list have not been adopted.

Thanks for listening,

Mike Champion

Received on Monday, 4 May 1998 13:29:27 UTC