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


______________________________________
Joe Kesselman  / IBM Research

Received on Thursday, 5 April 2001 09:02:47 UTC