W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Re: Equality tests on DOM nodes

From: Ray Whitmer <ray@imall.com>
Date: Fri, 11 Dec 1998 10:58:35 -0700
Message-ID: <36715D4A.9660A0D0@imall.com>
To: "Andrew M. Kuchling" <akuchlin@cnri.reston.va.us>
CC: www-dom@w3.org, xml-sig@python.org
Andrew M. Kuchling wrote:

> [CC'ed to xml-sig@python.org and www-dom@w3.org; followups to
>  www-dom@w3.org]
> With reference to the Python DOM implementation, someone has raised
> the question of testing the equality of nodes.  I don't think there's
> anything in the DOM Recommendation that discusses this question,
> possibly because the issue doesn't raise its head in Java.

I don't know Python, but very object in Java has an equals method to
signify deeper comparison than "==", for example, String.equals tells
whether the contents of two strings are identical.

>         * Should Element instances also compare their attributes?
> I would say 'yes', since the attributes are really associated with the
> Element node.
>         * If the two nodes have identical type and value, should the
> comparison be recursive, comparing the children of the nodes.  The ==
> operator would then be comparing entire subtrees rooted at node1 and
> node2.  I'm not certain if this is the best choice for the meaning of
> ==, but see no clear reason to choose recursive vs. non-recursive ==.
> Any suggestions?

For my own uses on both the client and server (in Java, not Python), the
full/deep comparison is the most useful and as such I implemented it in a
private API extension extremely efficiently.  A full/deep comparison is
very useful in many situations, and can be implemented much more
efficiently than forcing the user to check equality one attribute or
recursive child at a time (with acceptable tradeoffs in other parts of the

But I would recommend NOT using the built-in Python operator, just as I am
not using the built-in equals method in Java, until it has been defined in
the standard how this should be implemented.  Otherwise, users of your
implementation will not be interoperable with users of other
implementations, and also possibly not interoperable with the standard
definition if one is ever officially formulated.  Instead, define the
operator to raise an exception, if Python has one, and if you need an
equality check, write one in a private API with your own name on it so it
will be clear to users that by using your method, they will be sacrificing
portability, in exchange for a concise, permanent definition of its

The problem in Python is much bigger -- possibly rendering my advice
irrelevant -- since no official DOM API binding has been released for that
language in the first place.  I am just following how I would tell someone
to deal with the equals function in Java where users will expect
portability between implementations.

I don't know Python, so it is also possible that Python may impose more
rigidity on the requirements of == (than Java does on equals), making it
possible to know what the standard implementation should be, but your
raising the question would seem to indicate that it does not.

Ray Whitmer
Received on Friday, 11 December 1998 12:59:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC