Stefan Seefeld wrote: [snip stuff about spirit-like matching]
That's all interesting to consider, but it is different from my proposal, so I'd like to get us back on focus.
Yes this thread is diverging in many directions, but I think it's important to consider how people would want to use an XML API. As you say, once you have the right basic API you can implement other stuff on top of it, but if you have the wrong API you can't. For example, I might need to efficiently find all the <foo> nodes in a large tree. How would I do that with your library? I'd like to write something like this: class xml_doc_with_index: public xml_doc { ... extends the library's xml_doc to add an index of elements by their name, maintained automatically as elements are added and removed ... }; void f() { xml_doc_with_index d; d << cin; // parses XML document from input into d; index is built for (node_iterator i = d.elements_by_name.lower_bound("foo"); i != d.elements_by_name.upper_bound("foo"); ++i) { ... } } I think that there are a lot of useful techniques that can't be done using a libxml2 backend, including the symbol-table idea that I have mentioned before and the whole business of pointer semantics i.e. deep vs. shallow copy, copy-on-write and so on.
However, as I tried to point out numerous times, I do believe it is important to be able to bind highly efficient XML library backends, and not reinvent everything from scratch.
There is certainly an opportunity for a C++ XML library that "binds highly efficiently to an XML library backend", but I feel that that opportunity is already filled by xmlwrapp (http://sourceforge.net/projects/xmlwrapp/) and libxml++ (http://libxmlplusplus.sourceforge.net/) both of which have quite liberal licenses. What does yours offer that they don't?
To put it a little more bluntly: I do believe that XML is one of those topics where almost everybody has a strong opinion, in one direction or another. The syntax does look simple, and so everybody 'knows' how to do it best. That's a typical bike-shed question (http://www.bikeshed.com/).
We already have two quite satisfactory bike sheds (see above). There is not much point (IMHO) in building another to essentially the same design. If we're going to build another bike shed it should be a "modern bike shed for the next millenium". :-) Regards, Phil.