[xml] entity handling concept
- From: Christian Glahn <christian glahn uibk ac at>
- To: xml gnome org
- Subject: [xml] entity handling concept
- Date: Wed, 18 Apr 2001 21:19:12 +0200
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.
regards
christian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]