Quoting Michael Glavassevich <[EMAIL PROTECTED]>:
> 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.
>
So, you make a distinction between users being "guided by the schema" for nodes,
but not for ID's. I guess I generally see your point; importing/adopting nodes
is an explicit action and the ID's would be, implicitly, along for the ride.
As such, users can't define their intention for ID's to carry over where they
can for the nodes they choose to carry over.
Then again, if I'm a user with no knowledge of the nasty details we are talking
about here, here's what I expect between two documents with the same schema...
page1.getElementById("myId"); //non-null
... [import node containing element with "myId" to page2]
page2.getElementById("myId"); //non-null
But page2.getElementById("myId") *is* null. While this may be expected behavior
by to XML experts, it most certainly isn't to Joe-user. If this is just going
to be the way it is for technical reasons, then this behavior should be in big
bold letters in the DOM FAQ....
"Note: users should have *no* expectation that either importNode(Node, boolean)
or adoptNode(Node) will carry over any IDs contained in the source document
node to the destination document. That is, if src.getElementById("myId")
returns a non-null value, after the import/adoption, it should *not* be
expected that dest.getElementById("myId") will return a non-null value. To
re-register imported/adopted node IDs, the remedy is to either serialize the
document and re-parse it, with validation enabled, or do it in-memory using
dest.normalizeDocument(), with validation enabled."
Without something like the above, the documentation for importNode()/adoptNode()
is incomplete and will continue to cause confusion.
> > 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].
>
I wasn't aware of continuous validity checking. Thanks for pointing that out.
> > 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.
>
Then, clearly, this is deficiency in the spec. Joe-user expects an ID that
exists the source document to continue to exist in the destination document,
especially when the two documents use the same schema. That this doesn't
happen and the behavior isn't addressed by the spec is rather annoying.
BTW, what was one to do before DOM3's normalizeDocument()? Serialize and
re-parse? That's a non-solution, really. Even normalizeDocument() enabling
validation isn't overly satisfying. Good luck validating the HTML DOM when the
DTD's are completely invalid (yes I realize that HTML isn't meant to be
validated, but I can register the ID's at parse time for optimized
getElementById() capabilities and that gets lost upon import/adopt). And
validation at runtime is a heavyweight process anyway when all you wanted to do
was import/adopt a node.
I guess the outcome of this conversation isn't satisfying to me, but I don't see
that changing anything. Blind copying of IDs clearly is not going to be
accepted into Xerces. I just wish there were another option than "use
normalizeDocument()".
Jake
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
