Jacob Kjome <[EMAIL PROTECTED]> wrote on 01/29/2007 02:02:41 PM: > 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?
Why? The user presumably knows what they're doing when they're modifying the document. If their edits are guided by the schema, the document should be valid after they've finished making their changes. If they need a valid document but are inserting junk all over the place then that's their error. > 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. Not necessarily. See [1]. > 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? Assuming Xerces did this, how does a user know that they don't need to call Document.normalizeDocument()? If that behaviour is not in the spec, there's no guarantee that a DOM implementation will do that so they would have to call Document.normalizeDocument() anyway or risk breaking in other environments because they were relying on an implementation detail. > I just don't see blind copying of ID's as a problem given my arguments above. > > thoughts? > > > Jake > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] [1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Val-20040127/validation.html#DocumentEditVAL-continuousValidityChecking 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]
