Re: [boost] API Review request: XML APIs for C++

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-12 10:25:48

Peter Dimov wrote:

> Looks reasonable, but we don't want the architecture of the backend to
> affect the interface.

right. So what is would be reasonable semantics to expect from a dom API
? May be I'v just got used to libxml2's way of life, but I think it is
a good choice. Nodes are owned by their parents, so you can do

dom::element *child = parent->add_child("info");

And calling

dom::element::iterator i = parent->find(child);
parent->erase_child(i);

will invalidate 'child'. I don't know of any way to make that more safe
while still being efficient.

> There is also the problem that the user can be left
> with an invalid pointer after the document has been deleted.

Yes, but is that a problem ? Of course it has to be written in bold 
strokes: "Don't delete a document while operating on its content !",
but I think the main idea to get across is that nodes *can only* exist
in the context of a document. That's not only because of memory 
ownership issues, but also for a variety of other contextual data
associated with a node, such as namespaces.

I had a long discussion with the libxml2 author about ownership
semantics and he convinced me that the current way is the best tradeoff
between simplicity/ease of use and efficiency.

> Since the DOM is a tree and has no cycles, it should be possible to get
> fairly close to the Java interface using strict ownership or shared_ptr
> underneath. In the libxml2 case every Node would need to keep the whole
> Document alive but this may not be necessary given a different backend.

I don't understand that. The document owns its nodes, so letting nodes
reference the document would create loops, no ?

> Of course if this isn't practical a quick fix would be to return a
> shared_ptr<Document> from parse_file.

yeah, that's unrelated. But why not std::auto_ptr then ?

Regards,
                Stefan