Re: [dom3core] WRONG_DOCUMENT_ERR

On Sunday, 12/04/2005 at 10:50 CET, Robin Berjon <robin.berjon@expway.fr>
wrote:
> Process-wise there are solutions to handle this, what is needed
> however is people to do the actual work, and technical consensus. It
> would be great if this list (or the IG) could come to at least some
> preliminary agreement on what needs to be changed how, with what
> potential impact.

On this specific case: The proposal on the table appears to be a statement
that WRONG_DOCUMENT_ERR does not absolutely have to be thrown if the two
nodes happen to be fully interoperable; if not thrown, the effect would be
equivalent to an implied adoptNode operation. (It would be up to the
implementation to decide what constitutes "fully interoperable.")

I am inclined to suggest we say that the exception Should (keyword) be
thrown, to discourage authoring nonportable code, especially since
adoptNode now offers a clean alternative. But "Should" allows room for
deliberate departure when an implementation determines that such is
necessary.

A point for those who haven't considered it: Before you commit to
implementing a DOM which does not throw this exception, make VERY sure that
you understand how you're going to handle both live NodeLists and (if you
intend to implement them) DOM 2 Events. Both of these require back-channel
communication amongst the nodes of a document, and thus are good examples
of why it's hard to make separately-implemented nodes play nicely together.
Also, as has been pointed out before, consider the HTML DOM (if you're
implementing that) and/or other DOMs that may be carrying additional
information or behavior. Generally, you will find that *only* nodes from a
single document-type-agnostic implementation will work reasonably with each
other, which makes relaxing this constraint rather less useful than it may
at first appear. The main advantage, as far as I've ever seen, turns out to
be saving the cycles needed to maintain and check owning document.

I'd still suggest that folks who need to perform this operation use
adoptNode.

Received on Wednesday, 7 December 2005 14:31:21 UTC