W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1998

RE: Should Document.cloneNode() work in Level 1?

From: Kirkpatrick, Alfie <akirkpatrick@ims-global.com>
Date: Wed, 9 Sep 1998 10:40:29 +0100
Message-Id: <199809090946.FAA17292@www10.w3.org>
To: www-dom@w3.org, Don Park <donpark@quake.net>

I'm not sure I understand this debate about cloning or transferring.
As I see it, the current spec doesn't say anything about transferring
nodes without cloning, so presumably it can be left to implementations.

The reason I wanted a targetDoc on cloneNode is so that we can
mix implementations. So if I do an appendChild from one implementation
to another, it can use cloneNode to get a clean copy in its own
implementation. I now see that it can also be used to transfer nodes
between documents too. For example (in pseudo code):

Node Element::appendChild(Node newChild)
    // Check implementation
    NodeInternal customNode=newChild.QueryInterface(INodeInternal);
    if ( (customNode == NULL) || (newChild.ownerDocument != ownerDocument) )
         // Not my implementation/document
         customNode=newChild.cloneNode(TRUE, ownerDocument);
    // Add to my children
    // Here's where we use the custom interface

Does this make any sense at all in Java?

Without a lot more work (ie. Level 2), I don't think we can get a
which works between implementations/documents. However, if cloneNode is
given a targetDoc parameter, implementations can decide whether to clone
or not, and have a clear mechanism for doing so.

A performance boost might be to say that if the newChild is the same
implementation, has a different ownerDocument but doesn't have a parent
(perhaps after a removeChild), the custom interface could be used to modify
the ownerDocument and the parentNode, and thus avoid cloning.

This raises a question. What happens to ownerDocument and parentNode
after removeChild?


> ----------
> From: 	Don Park
> Sent: 	09 September 1998 09:59
> To: 	www-dom@w3.org
> Subject: 	Re: Should Document.cloneNode() work in Level 1?
> Alfie,
> >The problem with transferNode below is that it assumes that
> >the destination node can change the ownerDocument for the
> >node, which currently isn't possible between implementations.
> Yeah, I realized my forgetfulness right after posting it.  This basically
> forces transferNode implementation to always move by copying the content.
> However, your suggestion also forces cloning.  The question is, are there
> any way to do this without cloning?  Just change the definition of
> insertChild/appendChild?
> Don

Received on Wednesday, 9 September 1998 05:46:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:26 UTC