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