Re: Subclassing DOM nodes

>I don't understand what you write in parentheses.  Isn't a DOM node object
>in a tree unique?

Summary: In most DOMs, you can use your language's object-identity operator
to test node identity. But this is a binding/implementation detail, and is
_not_ guaranteed by the DOM spec. We expect to provide a more portable
solution in DOM Level 3.



Long version:


Don't confuse a DOM node and a DOM Node Object.

The former is a node in a  DOM tree, and has a unique identity -- but it
may not be an object; it may be a row in a table, or a database record, or
a point in a text buffer, or something which is computed when it's needed.
The DOM API says nothing about how the data is stored, and that storage may
not map 1:1 to DOM objects.

The latter -- the Node object -- is an object which implements the DOM's
Node interface and represents the corresponding node in the DOM tree. It
must be uniquely identifiable, but there is no promise in the DOM
Recommendation that the "==" operation (or your language's equivalent)
suffices to test node identity. It happens to work that way in most
existing DOMs, but not in all.

Some otherwise reasonable DOMs would pay a significant performance penalty
if asked to guarantee that == could be used for this purpose. For example,
they may be generating front-end Node objects on demand, using them, then
returning them to the heap when the user is done with them; in that case
the same node may have a different Node object each time you access it --
and may in fact have more than one Node object at the same time.

This was probably an oversight in the DOM spec, and we're planing to fix
it. It's called out in the Level 3 Requirements (rather tersely, I admit)
as
     * node identity. Is this object the same node as that one?
and is addressed in the Level 3 Working Draft by
      boolean  isSameNode(in Node other);

But exposing the node's identity outside the DOM, eg for this "side-data
lookup table" we've been discussing, is more complicated. We have to
resolve questions about how the identity is represented (or abstracted) and
what its actual scope of uniqueness should be (Document? DOMImplementation?
All DOMs running in the same process even if they aren't based on the same
implementation?). We haven't yet resolved all those issues completely;
watch the evolving Working Drafts for more information as it becomes
available.

______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 13 October 2000 09:41:30 UTC