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