Re: [boost] RFC: Boost.XML API prototype in the sandbox
Message-ID: <1184343317532@dmwebmail.japan.chezphil.org> In-Reply-To: <46977296.8030205@sympatico.ca> References: <46977296.8030205@sympatico.ca> X-Mailer: Decimail Webmail 3alpha16 MIME-Version: 1.0 Content-Type: text/plain; format="flowed" Stefan Seefeld wrote:
Phil Endecott wrote:
For example, I might need to efficiently find all the <foo> nodes in a large tree. How would I do that with your library?
You'd do an XPath query.
I'm pretty sure that libxml2 would visit every node in the tree to do that. With XSLT you can use the "key" mechanism to make this more efficient, but XPath alone doesn't get you that.
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.
Can you elaborate?
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.
E.g. these http://thread.gmane.org/gmane.comp.lib.boost.devel/85985 http://thread.gmane.org/gmane.comp.lib.boost.devel/86508 http://thread.gmane.org/gmane.comp.lib.boost.devel/86872 Regards, Phil.
Phil Endecott wrote:
Stefan Seefeld wrote:
Phil Endecott wrote:
For example, I might need to efficiently find all the <foo> nodes in a large tree. How would I do that with your library? You'd do an XPath query.
I'm pretty sure that libxml2 would visit every node in the tree to do that. With XSLT you can use the "key" mechanism to make this more efficient, but XPath alone doesn't get you that.
I don't understand what you are saying. What does XPath not get me ? I clearly can issue an xpath query, resulting in a nodeset filled with all 'foo' elements of the document.
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.
Can you elaborate?
My point is that I wouldn't attach user-data to nodes by derivation, but by some other, non-intrusive, means. Composition is often a much better device than inheritance.
May I suggest that you search the boost ML archives to find more details.
E.g. these
http://thread.gmane.org/gmane.comp.lib.boost.devel/85985 http://thread.gmane.org/gmane.comp.lib.boost.devel/86508 http://thread.gmane.org/gmane.comp.lib.boost.devel/86872
Yep. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 13/07/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
Stefan Seefeld wrote:
Phil Endecott wrote:
For example, I might need to efficiently find all the <foo> nodes in a large tree. How would I do that with your library?
You'd do an XPath query.
I'm pretty sure that libxml2 would visit every node in the tree to do that. With XSLT you can use the "key" mechanism to make this more efficient, but XPath alone doesn't get you that.
No, but it's *very* easy to write a bit of code to do that - I've done so today, using Stefan's code. Also - when libxslt builds the key, it will more than likely run an XPath query to gather the nodes that are indexed. Remember - libxslt is built on top of libxml2's XPath implementation. Stuart Dootson
participants (3)
-
Phil Endecott -
Stefan Seefeld -
Stuart Dootson