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

keshlam@us.ibm.com wrote:
> 
> >>         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.  ... ("What do you mean, it's a Hashtable? I used
> a NamedNodeMap, and Fred over there used a Vector!") 

Then there was the other part of my comment, calling attention to the
issue of how that resource gets shared.  You can push the issue away,
but it's always there.  A NamedNodeMap is rather heavy weight, too, for
a facility I've observed to be rarely used when it was available.

"What do you mean, you used the key 'session' to hold _your_ session?
It holds _my_ session!!!  Fred's session is under the 'fred_session'
key, and he's agreed with Fred from OtherCorp.COM where the other guy
uses 'COM.OtherCorp.Fred.Session' !"


>	The single-Object solution also leaves open the
> questions about what to do when the node gets cloned/split/joined.

Let's see:  "Fred wants his values associated only with the original
node.  You want clones of your values associated with the new node.
I want my original value associated with both nodes, and never use
this feature on text nodes.  Sandy only uses it on Text nodes and
wants a callback to figure out which split node gets the value..."

That's more of an API than I'd ever care to see in standard.  There's
just not enough value in solving it.

My ancient proposal for a "userData" field applied only to Element,
so the split/join issue didn't arise.  Classically, clones involve a
shallow copy of data members -- so they'd get the same data, unless
one wanted to define a special notion of cloning.

(Is there a need for a "DOMNodeCloned" mutation event?)


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

Intentionally so.  See the variety of possible answers I sketched above,
when I wasn't trying to be thorough.  If the association is external,
so is the choice of what's preserved through tree mutations of all kinds.


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

I've seen a limited need for the functionality, not enough to make it worth
putting into DOM.  It costs (memory, complexity).  My bias is not to have it,
or if it's there to make it cost as little as possible (i.e. have it be a
single object that gets no special treatment from DOM).

- Dave

Received on Thursday, 7 October 1999 16:47:04 UTC