Re: Older Sibling?

> > Reminder, since we're on the topic: node identity does not require
object
> > identity.
>
> "identity" being as fuzzy a notion as "equality" -- I said this earlier
> in terms of (eq? a b) and (equals? a b).


As long as we remember that there are two distinct kinds of "identity"
being discussed, it's not so bad:

Node identity is clearly defined in terms of the DOM, and is a necessary
concept for a significant number of common tree processing operations. As
one example, take the case of unioning several searches into a single list
of nodes; if you can't ask "is this a node I've seen before", you can't
discard duplicates. Or, consider a hand-coded subtree walker; if you can't
ask "is this the root node I started from", you can't stop yourself from
walking out of that subtree.

Most of us have been blythely assuming that object identity -- the
programming language's node1==node2 or equivalent -- can be used to test
for node identity. But in DOMs which operate as a proxy for other data
representations, it is possible that several DOM Node objects may in fact
be handles for the same node. In that case, == will return false (unless
you're in a language that permits overriding =='s behavior), but
Node.isSameNode(Node) would be defined as returning true.


Equality is yet another question, of course. Presumably equality would be
defined as "represents the same content". We've dithered a bit about
exactly how to define that -- specifically, about whether there's one
definition that really works for the majority of cases -- and between that
and the lack of a compelling need (since this test _can_ be implemented in
terms of the public DOM API), it's been deferred. The main argument for
moving it into the DOM would be that some DOMs might want to apply hashing
or other techniques to improve performance.


______________________________________
Joe Kesselman  / IBM Research

Received on Tuesday, 29 February 2000 09:11:08 UTC