Re: [boost] Proposal: XML APIs in boost

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-04 09:59:55

Stefan Seefeld
>Janusz Piwowarski wrote:
> > Stefan Seefeld wrote:
> >
> >>Now I hope that someone will actually start to send comments about the
> >>actual API / code I propose. ;-)
> >
> > I not sure why you do not use of overloaded append and insert members. 
>And,
>
>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" ));

> > I'd like to change begin_children and end_children to
> > std::pair<children_iterator, children_iterator> children (the same with
> > attributes).
>
>...or add a container proxy so one would write element->children().begin()
>instead of element->begin_children(). I'm not sure there is any gain. It
>seems to be a purely esthetical issue.

I prefer the container proxy as it is more familiar to STL users - ( 
children.first, children.second ) is harder to understand what is meant by 
first and second.

I would like to see STL techniques (like the children and attributes types 
being Container-like types), that would allow the leverage of existing STL 
and boost code.

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.

- Reece