On Mon, Oct 28, 2002 at 11:05:15AM -0500, Daniel Veillard wrote:
On Mon, Oct 28, 2002 at 10:19:09AM +0100, Christian Glahn wrote:I found an interesting issue in xmlNewChild(). I thought, it is possible to append a new child to documents, elements and document fragments withDocument fragments are a DOM only paradigm. It does not reflect in XML itself. As a result while it was originally added to the set of node type the API for this type had nearly zero usage.
I agree on that point, although I think document fragments are quite usefull on the application level (and that's where I have some use for this node type).
xmlNewChild(). It showed that document fragments are not supported by this function, although it would make sense to do so. I concider this as a bugI still don't see (except purely for DOM compatibility mode) why this is useful. I may apply the patch anyway.
It was actually used for high level DOM building with from a SAX stream. :) Document fragments are *real* usefull in cases where well balanced chunks are parsed.
If no namespace structure is passed to xmlNewChild() it appears, that the namespace of the parent node is silently taken as namespace for the new node as well. I was quite surprized about this behaviour, since I was expecting a node with no namespace set. Although the given implementation is unchanged at least since 2.4.20, I *think* that's wrong as well.No it's just the semantic of this operation. If you want a different semantic use a different function, I don;t want to change that now.
ok, I understand. I just was not shure if the implementation showed the correct behaviour.
I don't have the time to do this right now. Provide a patch, I will apply it if it doesn't modify the seamtic of the operation for the other node types.
I attached the patch that does not take effect to the existing implementaion. Christian
Attachment:
tree.c.patch
Description: Text document