libxml2 memory handling

I am working on redoing the memory handling so that the new extensions will
no longer use need the resource destructors, but rather work as normal
objects do with no regards to when or how the objects are destroyed. This
would not only relieve us of worrying about the order things are freed but
also allow for the objects to work as they should (i.e. calling unset would
actually unset the object and clean up the underlying libxml trees and
memory).

There are a few certain instances that it will cause a problem. The problem
occurs when a document object is destroyed and the tree is freed before
nodes wihch are not part of the tree, but owned by the doc. A few libxml2
calls use the doc property for some of its calls, and these crash. There are
a few ways to deal with it, but I wanted to know what people think as both
will involve a few steps that would need to dealt with when writing some of
the functions. I am also not sure of all the ramifications of some of the
possible solutions, so if anyone can see any or can see a better solution to
this, let me know

One possible solution is when unlinking nodes and creating nodes, which have
not been added to the doc, is to set their doc to NULL, add a doc pointer or
its address to the domxml_object structure and use that to do validate the
doc conditions prior to performing appends, etc... the libxml calls should
take care of setting the doc properly when appending (or we could do that
ourselves when needed).

Another possible solution would be to add a list to node pointers on the
domxml_object of a document which any time a node is unlinked or created, it
would be added to this list. This list basically would contain the nodes
which the document owns, but are not part of the tree. When a document
object is freed, it would first go through this list and set all the nodes
doc property to NULL (or we could destroy these objects) and then go ahead
and free the document. This would require any unlink, replace, etc... to
have to add and/or remove the node pointer from this list so that the list
is properly maintained.

This brings up the last point on when should nodes be unlinked and when
should nodes be freed? There really is no defined way to handle this in the
specs. Take for instance, the case when you have an object pointing to an
unlinked element. You also have an object pointing to another element
further within the tree of the unlinked element. The top level element is
being destroyed, should the child be freed (thus destroying the object
associated with this node) or should the child be unlinked from the tree?

Rob