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

Don,

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
    m_children.push_back(customNode);
    // Here's where we use the custom interface
    customNode.parentNode=this;
}

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
transferNode
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?

Alfie.

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