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

>>         attribute NamedNodeMap applicationData;
>
>    It's actually sufficient to have a single "Object" there, which
>    can hold dictionaries or whatever is desired.

Actually, no; it isn't. That works fine as long as you're writing all the code
which is using this feature. But if you want to plug together several
off-the-shelf DOM processing tools, each of which uses that single hook, there's
no way for them to negotiate how to share it unless that sharing is specified by
the DOM. ("What do you mean, it's a Hashtable? I used a NamedNodeMap, and Fred
over there used a Vector!") The single-Object solution also leaves open the
questions about what to do when the node gets cloned/split/joined.

If we're going to do it, it's worth doing right.

>    HOWEVER ... it's also possible for applications to maintain
>    their own tables which map nodes to values of their choice,
>    so I'm unconvinced this needs to be part of DOM.

That does work, though again it leaves the clone/join problem open. There are
ways to manage them, but if this turns out to be a commonly desired function
there's something to be said for encapsulating that management in the DOM.

______________________________________
Joe Kesselman  / IBM Research

Received on Thursday, 7 October 1999 16:20:15 UTC