Tree Structure Differences at Gdome2 Layer

As we have already pointed out in the previous section, the libxml2 tree structure is not always sufficient (nor adequate, in some cases) to fully implement the DOM specification. Every time the user application asks for the first time an handle to a particular document node, Gdome2 creates a structure with an internal reference to the corresponding libxml2 node. Elements, attributes and, in general, all the entities derived from Node share the same structure as generic nodes: the inheritance mechanism implemented in Gdome2 allows the sharing of common methods. At this point Gdome2 returns an ``opaque'' pointer to a GdomeNode structure thus preventing any potentially dangerous modification to the internal fields used by Gdome2. The internal structure for a node is the following:

type struct _Gdome_xml_Node Gdome_xml_Node
struct _Gdome_xml_Node {
    GdomeNode super;
    int refcnt; 
    xmlNode *n;
    GdomeAccessType accessType;
    Gdome_xml_ListenerList *ll;
};

Gdome2 uses a reference counting mechanism to keep track of the number of users of a given node: the structure is shared by all the users which asked for the same DOM node, and the structure is eventually freed as soon as the counter reaches 0. The sharing of this structure is implemented in an efficient way exploiting the _private field inside libxml2 nodes: when a Gdome2 node is requested by the user, a first check is made on the _private field of the corresponding libxml2 node. If this field is NULL, then the node is accessed for the first time, Gdome2 allocates and initializes a new wrapping structure and sets a pointer to it in the _private field. On the other hand, if _private is a non-NULL pointer, then Gdome2 assumes that it is a previously allocated Gdome_xml_Node and simply returns its value, after having incremented the reference counter accordingly. However, there are two cases where libxml2 structures are not suitable for this kind of handling:

DocumentType:

following the DOM specification, this node is meant to provide the lists of entities and notations that are declared both in the external and internal DTD of the document. However, libxml2 builds different hash tables depending on whether the entities or the notations come from the internal or external fragment of the DTD, for a total of 4 different hash tables. So, when a handle to a DocumentType node is asked for, Gdome2 builds two new hash tables, one for the entities and one for the notations, resulting from the merging of the paired hash tables for entities and notations.

Notation:

for historical reasons, in libxml2 this node has a particular and too simple structure. So, to treat this node uniformly with all the other node types (in particular for the implementation of DocumentType), Gdome allocates a further wrapper to the libxml2 Notation node, so that it looks like all the other nodes.