[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: DOM Node.cloneNode()
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|