DO NOT REPLY [Bug 4808] - using object identity as a substitute for isSameNode is bad idea

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4808>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4808

using object identity as a substitute for isSameNode is bad idea





------- Additional Comments From keshlam@us.ibm.com  2001-11-12 07:04 -------
You're right about the issue, but your proposed fix doesn't work.

As you noted, we currently assume == will yield the right result, and may not 
operate correctly on DOMs which don't guarantee that behavior. Known limitation.

equals() is not defined by the DOM API, so we can't rely on it. Even if it did 
work on DOM nodes, it really should compare their semantic content, not their 
object identity. In other words, given:
   <a><b>c</b><b>c</b></a>
the two <b> elements should report true when compared with equals(), which is 
definitely not a helpful when we're trying to establish node identity.

The == operator comes closer to being the correct semantic. It yields the 
correct answer in many DOMs, but not in all. Our own DOM proxy for DTM is one 
counterexample, so we're very aware of the issue.


The DOM Working Group is introducing the isSameNode() test in DOM Level 3 
precisely to address this issue; they recognized that this was an oversight in 
the DOM's design and are correcting it. The problem is, that correction is still 
only in a Working Draft version of the DOM, and even after it's released there 
will be a lot of DOMs which don't honor it.


It might make sense for us to implement a wrapper which uses isSameNode() if the 
DOM implementation in question supports it, and use == as a fallback when it 
doesn't -- on the assumption that if a DOM hasn't made the effort to support 
isSameNode, it must have mae the same assumption. Setting up that dual-pathed 
wrapper means dealing with Java reflection, which may have some performance 
implications.