Re: [xmlc] 2.3beta getElementById() behavior

At 05:59 PM 1/25/2007, you wrote:

> 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>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).

Keep in mind that the discussion here is XML-centric.  Because there 
is no inherent "id" attribute in XML (people have proposed a standard 
"xml:id" attribute), there is no fallback like there is in the HTML 
DOM, where it can simply recurse the DOM for elements with the "id" 
attribute and see if they match the desired value.    I like what 
Elliotte Rusty Harold had to say about it and agree that the ID'ness 
of attributes should be carried over.  And it sounds like it's simply 
an issue with the cloneNode().  Which might make sense if the 
original implementors of cloneNode() decided that if they cloned 
ID'ness and someone cloned a node with an attribute of type "ID", 
then there's be duplicate ID's, creating an invalid DOM.  However, 
there's lots of ways for a user to mess up a DOM and make it 
invalid.  What's one more, especially when user's are likely to know 
what they are doing and avoid doing bad things.


> 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.

The javascipt DOM is HTML-centric and treats "id" attributes as of 
type "ID".  You said it yourself.  There's no "DTDs to respect".  As 
such, it must make assumptions about what is an Id.  They simply 
don't have to face the issues that Xerces (or any parser) has with 
XML.  HTML is easy.


> > > 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?

You mean the HTML DOM interfaces, right?  Keep in mind that I 
originally thought you were using plain old HTML documents, not XHTML 
documents.  If you use the dom="xerces" or dom="lazydom" options for 
something with an XML format, then you will get the generic DOM, not 
the HTML DOM or the XHTML DOM.  When you choose dom="xhtml", then you 
get the XHTML DOM, which implements the HTML interfaces (as well as 
its own XHTML interfaces).

Try using dom="xerces" along with documentFormat="html".  You should 
end up with HTMLElementImpl as the DOM implementation, which, of 
course, implements the HTML DOM interfaces.


Jake


> Erik



--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws