[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] problem (bug?) with xmlNewChild()
- From: Christian Glahn <christian glahn uibk ac at>
- To: Daniel Veillard <veillard redhat com>
- Cc: xml gnome org
- Subject: Re: [xml] problem (bug?) with xmlNewChild()
- Date: Mon, 28 Oct 2002 19:10:38 +0100
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 with
>
> Document 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 bug
>
> I 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
*** tree.c Mon Oct 28 18:19:32 2002
--- tree.c.phish Mon Oct 28 18:18:57 2002
*************** xmlNewChild(xmlNodePtr parent, xmlNsPtr
*** 2091,2096 ****
--- 2091,2098 ----
cur = xmlNewDocNode((xmlDocPtr) parent, NULL, name, content);
else
cur = xmlNewDocNode((xmlDocPtr) parent, ns, name, content);
+ } else if (parent->type == XML_DOCUMENT_FRAG_NODE) {
+ cur = xmlNewDocNode( parent->doc, ns, name, content);
} else {
return(NULL);
}
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]