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 [EMAIL PROTECTED] 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.
