Re: Explaining DOM oddities

Good message, but of course I have some comments....

Overall, I understand the constraints. However, this is a public mailing
list, this is the forum for commenting on the standard, and as far as I
know, the only way in which the standard has been presented to anyone
outside the organizations collaborating to create the standard. Step back
and look at the DOM as a product. This mailing list is a market research
tool. Customers are telling you that the product is broken and are strongly
encouraging you to modify your product.


>Second, the API must be generally backward compatible with Netscape
>Navigator and MS Internet Explorer for obvious reasons.

I can't resist commenting on this. Of course I understand the rationale
here. <flame>But backward compatibility with products implementing a
standard that doesn't yet exist? Seems kinda backward to me. A standard is
meant to simplify development efforts for those using the standard--not just
the implementors--but first the standard has to exist! Most customers
understand and grudgingly accept incompatibilities in favor of standard
implementations.  If the existing implementations are broken when they
evolve to support a NEW standard, customers may grumble, but they won't
revolt.  Especially if it means that they won't have to maintain multiple
versions of their code (or pages or scripts). There are many examples of
incompatibilities between the IE & Netscape--many of which could and should
be addressed by DOM--How are those incompatibilities being addressed while
maintaining backward compatibility?</flame>

Ok, I feel better now.

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

Could you explain this further?  Since CompositeNode "HAS A" collection of
children, if Element "IS A" CompositeNode, then it too "HAS A" collection of
children...  What is the difference between Element inheriting its child
list from CompositeNode rather than Node? The proposal for a CompositeNode
was meant to more accurately describe the constraint that there are node
types that can't have children.  If the CompositeNode interface is not
implemented, then there should be a NotSupportedException specified on
insertBefore() so that *correct* implementations can complain when I try to
add an element to a comment. Yet another exception to catch...  As a client,
I would rather know at compile time that I can't perform an operation than
wait to be informed via an exception at runtime.

The argument to keep insufficient or incorrect abstractions in an API to
satisfy vendors who happen to implement something similar is pretty weak.
This is a standard that will hopefully have a long lifetime.  Should defects
be knowingly built into the first release?


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

NodeIterator handles indexed access and iterators. Where is the associative
array access?  And if names should be descriptive, it should be called
something other than Iterator--that name describes only a portion of its
behavior.  Again, for the ECMAScript/VBScript programmers out there, the
name won't matter--they'll be using indexed access in the same way they do
now, right?

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

Good argument. I'll agree that multiple access methods are necessary. I just
disagree on the way in which the DOM authors have chosen to provide those
methods.  Don't get me wrong--I know that the DOM in its current form is the
result of a significant cooperative effort between companies that may also
be competitors.  Having participated in standards efforts in the past, I
also understand the difficulty that was undoubtedly involved in creating the
spec. And I think the spec is very close to being finished. It just needs a
little tweaking here and there.


Jeff Mackay
Vtopia, Inc.
url: http://www.vtopia.com/
e-mail: jmackay@vtopia.com

Received on Monday, 4 May 1998 23:52:11 UTC