Re: [xmlc] 2.3beta getElementById() behavior

I've made the XHTMLDocumentBase.java changes to both the HEAD and the 
XMLC 2.2.xx branch.  Optimized lookup is attempted first.  If that 
fails because importNode/adoptNode fails to copy over ID'ness, then 
it falls back to recursing the DOM for "id" attributes with the 
specified value, just as Xerces2 HTMLDocumentImpl.java does.

I also checked in your feature request.

Both changes will exist in XMLC-2.2.14 and 2.3beta3.  I'll see if I 
can do a release this weekend, though I may end up trying to address 
a couple more things I'm investigating, so it may be delayed for 
another week.  We'll see.  In any case, you can build it yourself to 
get the functionality immediately.


Jake

At 08:08 PM 1/25/2007, you wrote:
>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



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