Internal DOM Tree Representation in Gdome2

As we have seen, libxml2 has its own concept of document tree. So, from one side libxml2 is an already working DOM-like implementation which is relatively light-weight and further justified by the fact that it allows document validation. From the other side, it is definitely not a DOM implementation, for it does not export a full DOM interface and it is somehow targeted to the libxml2 internal use of the document. Thus, Gdome2 acts like a wrapper for the libxml2 tree structure, by implementing in a uniform way the DOM interfaces and ultimately hiding any detail relevant to the libxml2 internals. A Gdome2 node is just a wrapper with a reference to the actual libxml2 node. Moreover, as we will see, Gdome2 wrapping nodes are ``cached'' so that only one wrapper is possibly allocated for a given node of the tree, regardless the actual number of live references from the user application to that node. This approach has the advantage to exploit most of the libxml2 internal structure for the implementation of DOM, with the minimum duplication of code and a relevant save in terms of memory usage: Gdome2 node wrappers are just used to store fields and to provide functionalities not directly available by libxml2 nodes. Gdome2 implementation of the Node interface consists of a set of functions providing:

• reading access for read-only node attributes;
• read/write access for modifiable node attributes by means of a couple of get/set functions;
• the semantic associated to the corresponding method in the DOM specification.

In particular, the last possibility is either implemented by simply ``forwarding'' the method invocation to the corresponding libxml2 function over the libxml2 node, if such function is already provided by libxml2, or implementing it from scratch in case it is missing.