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

Don (and all),

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.

As for Document.createCopy, this seems distinctly non-OO.
Wouldn't it require the document to test what kind of node
it was copying and then have some very node-specific operation
for each (or have I missed something here)?

I'd like to revisit cloneNode(bool deep, Document newDoc).
I still haven't seen any counter arguments for this approach.
Stephen Savitzky started the suggestion to put cloneNode
in Document with the following advantages:

>  1. it would keep _all_ the node-creation methods on Document

The node creation methods would still be on document. Granted,
the node would then have to transfer some data, something like:

Element::cloneNode(deep, targetDoc)
{
    targetDoc.createElement(tagName);
    // Transfer attributes
    if ( deep )
        // clone children
}

But this would actually be very neat, being able to clone attributes
and so on, with each class handling its own cloning.

>  2. it would not have to be modified or extended when new node types are
>     added.  

I don't see what would have to be modified for new node types.

>  3. there are no problems when the original node's document and the target
>     document use totally different implementation classes.

I don't see a problem with the above approach either.

To summarise, we are only going to get small changes into Level 1
at this stage (if that). Unless there are serious problems with the simple
change proposed, why not go with it?

Alfie.

> ----------
> From: 	Don Park
> Sent: 	09 September 1998 05:54
> To: 	www-dom@w3.org
> Subject: 	Re: Should Document.cloneNode() work in Level 1?
> 
> I think there might be a very nice solution here somewhere.
> 
> How does this look?
> 
> We just add Document.transferNode(Node node) as Ray suggested and have the
> user use Node.cloneNode() with it if he is cloning over to a new document.
> 
> Node originalNode; // this node is in the tree structure (parentNode !=
> null)
> Document destinationDoc;
> 
> destinationDoc.transferNode(originalNode.cloneNode(false));
>     // transfer a shallow clone
> 
> destinationDoc.transferNode(originalNode.cloneNode(true));
>     // transfer a deep clone
> 
> destinationDoc.transferNode(originalNode);
>     // transfer the original node
> 
> Comments?
> 
> Don Park
> Docuverse
> 
> -----Original Message-----
> From: Ray Whitmer <ray@imall.com>
> To: www-dom@w3.org <www-dom@w3.org>
> Date: Tuesday, September 08, 1998 6:23 PM
> Subject: Re: Should Document.cloneNode() work in Level 1?
> 
> 
> >Don Park wrote:
> >
> >> >newDoc.createCopy(node, false); // for a shallow copy
> >> >newDoc.createCopy(node, true); // for a deep copy
> >>
> >> I have no problem with this proposal particularly because it shifts the
> >> responsibility of copying to the destination document.  It feels right.
> >
> >I would prefer a method at the doc level, but one which has the option of
> >either cloning if the document is incompatible or transforming it if the
> >documents are compatible.  Only the retured node and not the original
> >would be usable after the operation.
> >
> >I would call this transferNode(node) // always a deep transfer.
> >
> >Actually, given my current model's shared underlying data model, I can
> >clone faster than I can mutate the original reference to have new
> >ownerDocuments, since clones share the original data.  I only prefer this
> >other approach to allow other implementations to efficiently transfer
> >documents between compatible implementations.  If no one else wants it,
> >fine.
> >
> >I didn't hear opinions whether document.cloneNode(deep) should clone the
> >document itself or raise an exception.  This is quite different from both
> >cloneNode or transferNode on a child, because it creates a new
> >ownerDocument rather than confining to or transferring between existing
> >ownerDocument's.  I think we need something like cloneNode to work at the
> >document level.
> >
> >Ray Whitmer
> >
> >
> >
>