Boost logo

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk