[xml] entity handling concept

hi everybody,

during the weekend I tried to get through the concept for the 
entity reference concept in the document tree. As it is written
in the TODO file, the handling of % entity references has to 
be rethought. 

- Find way of representing PERefs in the Dtd so that %entity; can
  be saved back.

While I am implementing a small subsystem to handle XML files, this 
problem became important for me. I would like to read, set up and write 
document trees without bothering about PERefs I need to use by chance. 
Since we decided to use libxml2 in other parts of our system, I prefer
to use it as well, so I don't have to bother with different datasructures
anymore :-) 

Therefor I have a few conceptional suggestions about this issue.

As I understand the document tree handling, there is no way to do 
such a job without rethinking the way of handling entity references a bit
in the current version of libxml2 (which is to me 2.3.5 but I believe 
this is also true for 2.3.6). 

I got through the code of tree.c and realized, that &entity; nodes
store the entity name and the value of the entity in the node 
nested inside the document tree rather than using it as a reference.
As well the child pointer of the node (*children and *last) point to
the entity itself. i don't know why latter is done, since the entity 
node is not needed anymore to handle this specific node. 

While thinking about representing PERefs in the Dtd, I would more 
agree into an representation which follows the current implmentation 
of "normal" entities (&entities;). This means to store the data (tree) 
underneath the %entity;-node rather than replacing the entity reference 
entierly with the imported data. 

Such an implementation could be done transparent to other parts of 
the library (and its extensions) through providing small wrapper functions 
(e.g. getNodeNextSibling() or setNodePrevSibling() etc.) to access 
the data. 

The bad thing about this concept is, that it keeps for each reference 
node the whole data tree in memory. This could be a problem if such
entities are used intensivly to import large sub-trees. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]