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

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-07-12 19:47:01

Phil Endecott wrote:

> That brings up another question; which of these approaches do people prefer:
> 
> - Use a C++ XML library that runs on a libxml2 backend, so that it can 
> also use libxslt to do XSLT transformations.
> 
> - Use a standalone C++ XML library that is incompatible with libxslt, 
> and instead do XSLT-like transformations in C++.

That sounds like a false dichotomy. If we have a compliant XML API XSLT
can be implemented on top of it. If, additionally, the XML API sits on
top of a XML backend library that also provides xslt functionality, it
is straight forward to provide bindings for those, too.

> This question brings us back a bit closer to the features of Stefan's 
> propsal (which I think could be extended to do XSLT using libxslt).  I 
> think that if I were starting another project of the sort that I 
> described before I would probably avoid XSLT - with hindsight I 
> overstretched it.  But what would ideal C++ XML transforming (or just 
> XML reading) code look like?  As gchen writes: "creating xml does't 
> seem a big problem, but writing xml-reader [..] is a time-consuming 
> task".  Boost.Spirit can match things; can we use something vaguely 
> like Spirit syntax to match XML fragments, and define actions to apply 
> to them?

That's all interesting to consider, but it is different from my proposal,
so I'd like to get us back on focus. (And incidentally, David didn't answer
my question yet whether his tree-constructing syntax was something on top
of a procedural API, or whether it would replace it.)

Yes, there are many things that can be done to "write XML" in C++ that
particularly appeal to those among us with strong opinions on syntax.

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.
Having some nice-looking syntax bind to the API I propose should be
straight forward, but may incure performance overhead. (Some of that may
be mitigated by clever proxying tricks, but that likely involves other penalties,
such as code complexity, etc.)

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/).

Hoping that this discussion will lead somewhere,

                Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...