On 05/08/2013 07:21 AM, Bjorn Reese wrote:
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.
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.
You are evading the question. A user may not even care how boost.xml is implemented, as long as the functionality is there. If I'm such a user, I don't want to be confronted with the question of what backend to pick.
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.
Sorry, bad choice of words on my part. By "validates" I was referring to some functional requirements (such as a test suite) which an implementation is measured with for correctness. But since you are talking about it...
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.)
Right. But again, I think you are making life much harder than it needs to be for users. As a user I want to use the boost.xml library in my own project. Do you really anticipate there to be a bunch of different backends being offered to end-users to pick from, depending on what functionality he requires ? What a drag ! Just give him a a single library with easy instructions on how to call, link, and execute it. Being forced to look at backends totally defeats the purpose of having an abstraction layer in the first place.
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.
What I'm saying is that, once you impose "our own implementation", you eliminate the majority of existing backends, including libxml2 and xerces, because they have their own. And so, to support such backends, it's best to keep the choice of implementation for that data structure close to the backend, an "implementation detail". Stefan -- ...ich hab' noch einen Koffer in Berlin...