DOM Node.cloneNode()

[Tyler Baker]

Don Park wrote:

> Tyler,
>
> >In other words, if I have a Node named "A" with two children named "B"
> >and "C", would you do something like this in Java for A:
>
> A shallow clone of "A" will result in a node of same type as "A" with no
> children.
> A deep clone of "A" will result in a node of same type as "A" with clones of
> "B" and "C".
>
> A node has exactly one parent or no parent at all so "B" and "C" can not be
> children of both "A" and its clone.  Since it is inappropriate for cloneNode
> to move "B" and "C" from "A" to its clone, a clone is made and added during
> deep clone.
>
>

This is what I would assume, but DOM stands for Document Object Model and so I
was not sure if the purpose of the DOM was to simply build a tree or else a
complex graph.  In the latter case, you would not need to really enforce this
condition.

I would take it that an implementation would call clone() on all children to
retrieve the references to the objects in the case of a deep copy...


> >Similiarly, what happens with the Attributes of a Node is also not too
> >clear to me.  Are attributes copied by value or by reference as well?
> >What happens to the parent attribute?  Should it be copied as well or
> >should it just have the implicit DocumentFragment reference as its
> >parent?  What happens to the references to the siblings of a node?
>
> Whether an attribute is copied by value or by reference depends on the
> implementation.  I think most implementations will copy assigned attributes
> by value and default attributes by reference.  Attributes does not have a
> parent nor siblings so it can not return DocumentFragment as its parent.
>
>

The spec says:

"The Attribute inherits the Node interface, which has a parentNode attribute.
This attribute is set to the Element associated with the attribute as an
expedient way of getting from the attribute to the Element. Note: In XML, the
value of an attribute is represented by the child nodes of an attribute node,
since the value can be contain entity references. Thus, attributes which contain
entity references will have a child list containing both text nodes and entity
reference nodes. In addition, tokenised attribute types, such as NMTOKENS will
result in a child list where each child represents a single token from the
attribute value."

As I understand this, an AttributeNode has an Element as a parent and there is
nothing that says an Attribute cannot have siblings.  In this sense you could
think of a list of attributes in some particular order as all being siblings of
each other.  From this statement, Attributes can also have children which really
does not make a lot of sense to me.

>From a personal perspective, it would really suit the DOM much better if you
totally did away with the Node interface altogether and traverse the DOM tree by
element.  The other option would of course be to nest elements, text, PIs, etc.
inside a Node object just like you would with any basic tree implementation.

In other words you would have in C:

typedef struct {
  Node* parent_node;
  NodeList* child_nodes;
  Node* previous_sibling;
  Node* next_sibling;

  unsigned int type;
  void* object;
} Node;

or of course in Java:

public interface Node {
  Node getParentNode();
  NodeList getChildNodes();
  Node getPreviousSibling();
  Node getNextSibling();

  int getType();
  Object getObject();
};

Right now in the current DOM implementation I have, for at least the Element
interface implementation, whenever I come across a sub-element that I need to
locate a handler for, I need to pass a lot of information to the super
constructor such as a reference to a previous sibling and a reference to the
parent that otherwise would not be necessary if I did not have to inherit the
abstract Node implementation in the first place.  This is doable from an
implementation standpoint, but very yucky IMHO.

Last but not least, why on earth are the constants for "Type" shorts?  Is this to
conserve memory?  In Java, all integer operations are done on 32 bit integers so
if you use shorts, you are slowing your case statements down considerably as a
cast is necessary to convert the short into an int anyways.  Most systems out
there now are 32 bit, so why worry about an extra 2 bytes per node.  If memory
was a concern, why not just use octal values as constants?

BTW, thanx for the response...

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)