Re: [boost] Proposal: XML APIs in boost

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-11-04 10:19:45

Reece Dunn wrote:

>>Assuming you are talking about the element class and its methods to add
>>various child node types, I don't quite see how I could overload the 
>>function
>>name 'append' and 'insert', as most versions have the same signature.
>>E.g. 'insert_element("foo")' will add (and return) the element
>>
>><foo/>
> 
> 
>    node.insert( element( "foo" ));
> 
> 
>>while 'insert_comment("foo")' will add (and return) the comment
>>
>><!--foo-->
> 
> 
>    node.insert( comment( "foo" ));

That assumes you can create a freestanding 'element' and 'comment' object,
which I deliberately try to avoid, as it would necessitate the API to become
more complex.
In the simple model I have in mind users would *never* have to care for
node ownership, as nodes always live in the context of a document. You can
still move or copy nodes from one document to another, but being able to
create nodes that aren't attached to a document complicate this simple
model quite a bit.

[...]

> Since an XML document is a tree structure, it might be useful to have a 
> generic tree library first (using STL principles) so you could do something 
> like:
> 
>    typedef nary_tree< xml::node > document_fragment;
> 
> or even leverage the Boost.Graph library.

Yes, you certainly could implement an XML API on top of the boost graph library,
but as I said in my original mail, an XML library is *much* more than a means
to manipulate trees. Not only would it be a lot of work to (re)implement all
the XML specs, but also the domain-specific knowledge that went into the specific
tree structure(s) used in libxml2 make it particularly performant.

So, while the boost::xml::dom interface must not be targetted at any particular
backend, I don't think that thinking of it as 'yet another tree library' is
particularly helpful.

Regards,
                Stefan