Re: Copying a node from one doc to another

>         A problem arose when we started looking
> at the HTML DOM and some other proposed usecases, precisely because they
> _might_ have subclass-specific per-instances data.

The code walking the "source" subtree clearly has got to touch each node
to modify its owner, and such nodes could encapsulate any specialized
logic if desired (including ability to veto a proposed move).

Unless DOM is in the business of specifying APIs used by subclassers
as well as applications, all such details are out of scope.

However, your point relates to some architectural assumptions (AFAIK not
part of the DOM L2 spec) about DOM objects and their relationships with
various external contexts.  Such relationships really ought to be part of
an architectural description of DOM, if they're used to make design choices
in the way you've suggested.


>     and it
> wasn't clear how to make the behavior when moving across implementations
> (or subclasses of implementations) consistant with moving within an
> implementation, so we went with a clone-analogy rather than a
move-analogy.

Who had added "move between implementations" as a requirement?  Bad model;
see below.

You'll recall that I have in the past pointed out that "import" is a move
operation ("import this young cheese surreptitiously, since the FDA claims
it's too tasty for any palate US-resident palate") ... so importNode() is
using the wrong analogy (looks like a move, not a clone like it is).


> There's a proposal on the table to introduce something more like move in
> DOM Level 3. It might still be a clone-and-discard if you're crossing
> implementations boundaries, but it would provide an opportunity for
> optimization in those cases where the DOM can recognize a compabable node.
> I haven't seen a description of how the above issues are to be addressed,
> so I have no guess about whether it'll fly or not.

I think the original proposal I made some long time ago said that
a move either worked or didn't ... and the caller might need to
attempt a smart-enough copy (e.g. a directed clone, like importNode
does) if a move couldn't be done.

Folk who don't care about the overhead of a copy can always clone,
but folk who _do_ care will never want copies/clones done without
their explicit request.  (Tree clones can use a LOT of memory.)

- Dave

Received on Wednesday, 15 March 2000 02:22:03 UTC