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