Re: [Libxmlplusplus-general] API questions

[Stefan Seefeld <seefeld sympatico ca>]

Murray Cumming wrote:

> Nodes are created by their parents - other Nodes, or maybe the Parser,
> and are owned by them. You shouldn't need to new a Node yourself. This
> seems to work. We might state that more formally later.

well, the API suggests that I can create a node myself: all constructors
are public.

> > Imagine you have two xmlpp::nodes, with a parent/child relationship.
> > Then you delete the parent,
>
>
> You shouldn't delete nodes. Let libxml++ take care of that.

Can you elaborate on that a bit ? How (and when) does libxml++ care
for node deletion ?

All I see is a single node tree created at parse time, and deleted
recursively in the parent (root) node destructor.

But what happens if I want to restructure the tree manually, i.e.
want to insert new nodes, remove them, or put them into different
parents ?
That doesn't seem to be supported at all right now. So it seems the
current DOM tree should be considered read-only...

> > calling the underlaying libxml2
> > cleanup function (which, let's say, cleans up the subtree recursively).
> > Your child xmlpp::Node now points into invalid memory !
>
>
> In general, if you can provide a test case that reproduces a bug, we
> might investigate it.

as an example of the above, the Node::remove_child() deletes a given
child node. There doesn't seem to be a way to really remove a child node
and insert it elsewhere. Or at least there isn't a way to do it without
going the way of a deep copy.

Now think about the following situation: libxml2 provides a way to 
retrieve a 'NodeList' that match a pattern expression ('xpath') in the
context of a given document. So it returns a list of xmlNode pointers.
How can that be wrapped with libxml++ ? You can't just put those xmlNode
pointers into xmlpp::Node instances, as they would make a deep copy of
the nodes, which is probably not what you want.
What would be much more appropriate is to create xmlpp::Nodes that refer
to those xmlNodes without assuming ownership of them, so they can still
be 'managed' by other xmlpp::Node instances inside the document tree.

On the other hand, if there was a way to map back xmlNodes (libxml2) to
xmlpp::Nodes (libxml++), the pattern matching function could return 
pointers to existing xmlpp::Node instances. Well, this would, however, 
still not address the issue about manipulating a document tree without
making deep copies.

I hope this illustrates why providing more flexible ownership semantics
is important.

> > I would suggest you fix the semantics and then implement that
> > appropriately, either by always using deep copies, or (probably better)
> > by means of smart pointers (ref counting).
>
>
> I feel like smart pointers could be better, but so far there doesn't
> seem to be a big need. Maybe after the API freeze.

sure, if you plan a release, this shouldn't get into the way. However,
I'm not sure that this important a point can be added later without
affecting the API. Or, what's even worse, without affecting the semantic
of an existing API.

By the way, I'm just chatting with Daniel (DV) on
irc://irc.gnome.org/#xml, and he explains that the '_private' field in
the xmlNode structure could be used to implement the inverse mapping,
i.e. to point back from xmlNode to xmlpp::Node.
This really means libxml++ can (and then should) use libxml2 pointers
*everywhere*, even to access child nodes.


Regards,
		Stefan