Re: [xml] xmlCopyDtd() does not copy the children of the DTD node...
- From: Daniel Veillard <veillard redhat com>
- To: Anthony Jones <amj30 cam ac uk>
- Cc: xml gnome org
- Subject: Re: [xml] xmlCopyDtd() does not copy the children of the DTD node...
- Date: Wed, 23 Jan 2002 13:20:22 -0500
On Wed, Jan 23, 2002 at 04:39:25PM +0000, Anthony Jones wrote:
If we call xmlCopyDoc() on a document that contains declarations etc
within its DTD, they will not be copied. This can be demonstrated by
running the attached program on, for instance, test/defattr.xml, and
diffing original.xml and final.xml.
This is because xmlCopyDtd() does not copy the children of the DTD node -
is this the correct behaviour?
It used to be the correct behaviour but is not anymore and
results in the problem you're seing. DTD declarations used not to show up
as children of the DTD node. they do now (to be able to keep ordering,
and insert comments, PIs, etc...).
If not, I'll happily write a patch to try
and fix it, but I'm not entirely sure about the correct way to do it:
1) Should xmlCopyDtd() recursively copy the children of the DTD node, or do
we want to keep the current behaviour, and have a different function to
copy a DTD node and its children?
it should provide copies. Note that these copies are created in the
generated dtd as part of ret->entities ret->notations ret->elements
and ret->attributes, the problem is that these nodes should also show
up as children of the dtd node. Without preserving ordering it's
a simple matter of walking the hash tables an inserting in theclarations.
If one want to preserve the ordering of the DTD children this becomes
2) This would require the facility to copy the element/attribute/entity
declaration nodes (any others?), should this just be added to
Hum, the facility exist but is relatively different from "normal"
nodes copy, so I'm tempted to keep them distinct so far.
I would appreciate if you could work on this, I have little use myself
to get this right and this may need a bit of debugging. Morover getting more
people to lean libxml2 internals can only be a good thing :-)
thanks in advance !
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev