Re: [boost] RFC: Boost.XML API prototype in the sandbox

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-07-12 07:28:38

Phil Endecott wrote:

> I have just dug out an old email that I wrote to the xmlwrapp list in
> 2004.  I had observed that xmlwrapp, which is a C++ wrapper around
> libxml2 with much in common with Stefan's proposal, had an overhead of
> about 150 bytes per node.  I had been getting binary data from a
> database (with negligible space overhead compared to a C++ struct),
> converting it to in-memory XML and then converting that to HTML or SVG
> using XSLT.  The in-memory XML was terribly bloated to the extent that
> it was the bottleneck in the system, for a couple of reasons.

...

> The view I'm coming to is that I'd prefer an XML class with enough
> template parameters to make these sorts of issues resolvable by the
> user, depending on the requirements of their application:

...

After such an experience my thoughts would be less oriented towards changing 
the XML in-memory class and more towards refactoring the application to not 
build the entire XML document in memory. This obviously wouldn't be possible 
if your next processing phase demands an in-memory XML as input; but if it 
does, it's possible that you wouldn't be allowed to change it anyway; you'll 
have to live with whatever template parameters have been picked by its 
author. If, on the other hand, the HTML/SVG backend takes an 
element_iterator range, you'll be able to feed it on demand without ever 
constructing the whole tree. Of course this would likely mean no XSLT. Doing 
an XSL transform on a "virtual" document would require an abstract node 
interface that you implement on top of your existing data to provide an XML 
view for it.