Hi Jake, Jacob Kjome <[EMAIL PROTECTED]> wrote on 01/28/2007 03:50:25 AM:
> I just realized the Elliotte Rusty Harold posted an issue about > losing ID'ness when cloning [1]. Since the importNode()/adoptNode() > issue is so related, I posted a comment about there rather than > reporting a new issue. I also attached a patch, which works for me > in limited testing, to transfer ID'ness from a node (and children) in > one document to the next for both cloneNode() and > adoptNode(). Please take a look and let me know what you think. I had a quick look yesterday evening. It seems your patch just blindly copies ID-ness from one document to another. It isn't clear to me that that's what a user really wants. Consider that the source and target documents may have different schemas. What may be considered an ID in the source document may not be in the target. The DOM implementation may not have enough information at the time to know that so whatever it does in the absence of that information could be "wrong". So what do you do? You really need to revalidate (i.e. call Document.normalizeDocument()) to re-establish ID-ness. > As I stated in the issue, I'm really not sure what the behavior > should be for cloneNode(), but importNode()/adoptNode() seem more > clear. The user-intent is there and Id's won't necessarily be > identical (and could be simply considered user error if they are) as > they will be when cloning a node with an Id in the current document > (which is, arguably, more of a library error than user > error). Can this get applied before the next release? > > > [1] https://issues.apache.org/jira/browse/XERCESJ-1022 > > > Jake > > At 03:22 PM 1/25/2007, you wrote: > >Quoting Michael Glavassevich <[EMAIL PROTECTED]>: > > > >> Hi Jake, > >> > >> Jacob Kjome <[EMAIL PROTECTED]> wrote on 01/25/2007 01:19:46 AM: > >> > >> > I'm wondering whether or not I should expect that if I import/adopt a > >> > node from a source DOM, that attributes of type ID on the > >> > imported/adopted nodes should be found by getElementById() in the > >> > destination DOM. The behavior I'm seeing is that getElementById() > >> > fails to find the elemements (null is returned). > >> > > >> > Can anyone provide some insight on what I should expect? If the type > >> > of the attributes are not carried over, what is one to do? For > >> > non-HTML DOM's, getElementById() can apply to an attribute of any > >> > name, as long as it was marked as of type ID, so it's not like I > >> > recurse the DOM for "id" attributes, as I might in the HTML DOM. > >> > >> There was a discussion [1] on this topic a couple years ago. I was fairly > >> convinced by Joe Kesselman's thoughts [2] at the time though now I'm not > >> really sure. > >> > > > >Interesting. I read further and it seems that Elliotte Rusty > Harold determined > >that it was a cloning problem [3]. Any comments on that? Could > this be fixed > >by correcting the cloning issue? > > > >> > Actually, when I use the HTML DOM, I seem to have the same problem > >> > and I wouldn't expect it there because if > >> > HTMLDocument.getElementById() can't find an element with an attribute > >> > registered as of type ID with the specified value, it falls back to > >> > recursing the DOM looking for "id" attributes with the specified > >> > value. Why is it not finding the elements? > >> > >> Sounds like a bug. > >> > > > >Not a bug. Sorry about that. You responded just before I sent > another message > >stating that this claim was a mistake. The HTML DOM works just > fine because it > >falls back to recursion. I was mistaken about the DOM I was using at > >the time. > >It wasn't the HTML DOM but a custom XHTML DOM variant of the > standard DOM that > >provides no HTML DOM-like fallback mechanism recursing the DOM for "id" > >attributes with a given name. I'm probably going to have to add > the fallback > >recursion because of the losing ID'ness issue. > > > >> > >> [1] http://marc.theaimsgroup.com/?t=109836916900003&r=1&w=2 > >> [2] http://marc.theaimsgroup.com/?l=xerces-j-dev&m=109838807214629&w=2 > >> > >> Michael Glavassevich > >> XML Parser Development > >> IBM Toronto Lab > >> E-mail: [EMAIL PROTECTED] > >> E-mail: [EMAIL PROTECTED] > > > > > >[3] http://marc.theaimsgroup.com/?l=xerces-j-dev&m=109841032302937&w=2 > > > >Jake > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
