On 05/06/2013 03:18 PM, Stefan Seefeld wrote:
Well, I don't expect any packager to package both. Or perhaps they might, so users have the choice to install, say, `yum install boost-xml-xerces` or `yum install boost-xml-libxml2`. Still, for these two the provided functionality should be mostly the same, while you are advocating a 'boost-xml' package offering a reduced API. I'm not convinced that will solve any real problem.
I am not really advocating anything with regards to packaging; I was responding to your question. Linux packages are a peripheral issue to me because they are usually too old (the latest version in my distribution is Boost 1.49.) So the following is just a brainstorm. A solution could be to have a 'boost-xml' package with the Boost.Xml codebase -- that is, the APIs, the wrappers for libxml2 and Xerces, and whatever implementation we write. This package does not contain any package dependencies on libxml2 or Xerces, because neither may be used by the user. If such dependencies are important (although Boost.Multiprecision seems to live happily without), then I would add a 'boost-xml-libxml2' package without any content except dependencies on the boost-xml and libxml2 packages, and similar for Xerces.
Fine, so you insist on writing your own XML implementation. That's obviously up to you, and as long as your implementation is complete and validates, there should be no problem using that as backend for the (to be defined) boost.xml.
I am not really sure why you keep insisting on validation. It may be important for your applications, but not every application needs it. This includes Boost.Serialization and Boost.PropertyTree. W3C clearly acknowledges this. The XML standard explicitly allows both validating and non-validating XML processors (see section 5.1.) Having said that, my alternative proposal did offer a solution for validation, so I do not really see the problem.
Can you elaborate ? Each backend library has its own data structure to keep content and associated state. Whatever of that state is made visible through boost.xml needs to be done through a portable and public API. Or do you expect users to access the backend directly ?
I was not arguing against a C++ API for DOM. I was talking about whether or not we should provide our own implementation thereof.
The two existing implementations that come close to what I think is a good model to follow are the boost.xml sandbox project (which I now moved to https://github.com/stefanseefeld/boost.xml), as well as arabica (www.jezuk.co.uk/arabica). By mapping to a range of implementations (libxml2, xerces, MSXML, etc.) they prove that the API is robust.
I suggest you base your critique on those APIs, and indicate what you think isn't working there.
Why? I have not made any arguments for or against how the APIs should actually look. I am addressing a different problem.