Re: Copying a node from one doc to another

> 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).

Some of this was discussed. We didn't get it to a point where we felt our
description was robust enough to incorporate into the spec.

> 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.

Seems reasonable, as far as it goes. As I said, there is a proposal to
revisit this in DOM Level 3.



> You'll recall that I have in the past pointed out that "import" is a move
> operation

Not really relevant to the discussion at hand. Reasonable people may
disagree with our word choice, and move can certainly be reconsidered...
but we really are not using import in the sense you would prefer.

You pointed out that "import across a geopolitical border" is a move
operation. But there are counterexamples in our own industry, such as the
Java use of the word to mean "copy interface information from". We didn't
find an alternative term that was clearly better, and decided that while
this usage may be jargonesque it wasn't inappropriate.

Before anyone else says it: "There's glory for you."




______________________________________
Joe Kesselman  / IBM Research

Received on Wednesday, 15 March 2000 09:06:11 UTC