Phil Endecott wrote:
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
You'd do an XPath query. (See the XPath docs for exact semantics of what can and can not be queried, and returned.)
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) { ... } }
As often, inheritance is the wrong tool to extend. This example is no exception.
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.
Right. But I don't see that as a limitation of my approach. Rather, I'd use a different way to achieve that anyway.
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?
I did some work on libxml++ some years ago, but then parted when it became apparent that libxml++ was to be glued to tightly into GNOME (the choice of unicode string is fixed, i.e. not parametrized as in my proposal), and other unfortunate decisions. Incidentally, the approach I had taken in the way I bind to libxml2 there was part of an earlier proposal I submitted to boost (many years ago). Then, people suggested alternatives that eventually let me to the current approach. May I suggest that you search the boost ML archives to find more details. (Before starting to contribute to libxml++ I also looked into xmlwrapp, but decided against it for a number of reasons. It has been too long for me to remember exact details, but performance was a problem (or rather, the unnecessary copying of data, that let me to believe that performance would turn out to be a bottleneck, eventually). Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...