Thanks for the groves (and purple) info.
The following is a cut from a DOM list that seems related.
----- Original Message -----
Sent: April 05, 2001 6:02 AM
Subject: Re: DOMKey in WD-DOM-Level-3-Core-20010136
> > Frankly, I'd like to see some explanation of the motivation &
> > rationale for the DOMKey thing
> We should probably make sure this rationalle is included in the spec.
> Here's a brief overview of the issue:
> There's been an ongoing request for a way to associate additional data with
> DOM nodes. In some DOM implementations, especially those which act as
> proxies for other data structures, there may be multiple objects which
> share the same node identity (which is why isSameNode is needed)... which
> prevents object identity from being used to make this association.
> DOMKey is intended to be a value which _does_ uniquely identify a node
> within a specific context and which can be used as an index to retrieve
> additional information from non-DOM data structures. In some DOMs which
> don't have the proxying issue, it may in fact be the object identity (eg
> its address), but that's an implementation detail.
> Having set up that concept, we need to decide what the useful scope of the
> context should be. There doesn't seem to be a practical way, to guarantee
> key uniqueness across multiple DOM implementations, so when you copy a node
> its key may already be in use in the other implementation -- and we don't
> want to prevent copying, so we definitely don't want to guarantee key
> uniqueness across implementations. We _could_ choose to guarantee
> uniqueness within all documents in a single a DOMImplementation, but there
> doesn't seem to be a strong use case for forcing that constraint upon all
> DOMs, so we chose to make the weaker statement that the key is unique only
> within a single document and that moving a node to another document may
> (not must!) result in its being assigned a new key.
> (Note that the whole concept of moving nodes between documents is new in
> any case, and that adoptNode will not be supported in all DOMs -- so in
> many cases you're going to fall back on importNode, which creates a new
> node with its own key in any case.)
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:04 PDT