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