|
Boost : |
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-07-13 08:39:50
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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk