Quoting Michael Glavassevich <[EMAIL PROTECTED]>: > 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. >
If the schema is completely different, then you probably have larger issues than ID'ness, no? If you are importing <a> elements and the destination document doesn't define <a> elements in its schema, importNode()/adoptNode() is still going to let you do it. The fact that it doesn't belong there won't be apparent until one serializes and reparses or calls Document.normalizeDocument(). Likewise, if the source document schema defines an attribute of type ID and the destination document schema doesn't, one can certainly correct the situation by calling Document.normalizeDocument(). Essentially, I'm not sure I buy the argument, when it comes to ID'ness, that importNode()/adoptNode() has to jump through hoops to make sure it isn't doing anything that might be incorrect with respect to the schema while it's an "anything goes" attitude toward unsupported elements? In fact, I'd argue that the ID'ness issue is innocuous. Blind copying of ID'ness *may* result in ID's existing that may not continue to exist after a call to Document.normalizeDocument(). Big deal. Blind copying of element nodes with names not defined by the schema *will* result in a validation error upon Document.normalizeDocument(). So why put the onus on the ID'ness code when the existing code allows the document to be put into a state where it will cause catastrophic error upon Document.normalizeDocument()? To me, user intension is pretty clear. In 80% or more of the cases one is going to work with two documents of the same type when importing/adopting nodes or risk some serious validation problems. Maintaining ID'ness for the 80% or more seems to be the right thing to do. The 20% better damned well call Document.normalizeDocument() since there's a pretty high probability that the document will be invalid after the new elements are imported/adopted, in which case any "improper" blind copying of ID'ness will have been corrected assuming invalid elements didn't already cause everything to explode. Why force the 80%'ers to call Document.normalizeDocument() when the 20%'ers have to do it anyway? I just don't see blind copying of ID's as a problem given my arguments above. thoughts? Jake > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
