On Jan 25, 2007, at 10:08 PM, Jacob Kjome wrote:
Michael Glavassevich, on the Xerces list, pointed me to these. [2] is the one
that originally convinced him that keeping ID'ness is not only unnecessary, but
not desirable, but he says he's not so sure now...
[1] http://marc.theaimsgroup.com/?t=109836916900003&r=1&w=2
[2] http://marc.theaimsgroup.com/?l=xerces-j-dev&m=109838807214629&w=2
To me, the end-user, it seems like if I call getElementById("dog") on a document that has an element with id="dog", it should give me that element. Period. If I've imported nodes that have resulted in an invalid document with duplicate ids, getElementById("dog") should return any one of the elements with that id. Since I'm the one that broke the document, I shouldn't get to expect one over the other. I'd also lean in favor of the importNode() failing if there were duplicate id's (something that'd be easy to do if you were copying the new nodes' ids into your map).
But again, that's just my opinion as an end-user outside the DOM black box. I'm pretty sure that _javascript_ DOM behaves the way I've described. But then _javascript_ is out there in Anything Goes Land without DTDs to respect.
Which of these issues do you have control over and which do you have
to convince Xerces to implement?
#1 is a matter of the Xerces team implementing it properly. #2 is something I
have full control over in XMLC and will do this for the next releases (2.3beta3
and 2.2.14).
Yay! This pleases me very much. Thank you.
You never did address my question about how the Xerces and Lazydom element implementations don't use the W3C DOM interfaces. What's up with that? Were they off doing their own thing before the standard interfaces were made available?
