Re: [boost] [GSOC] XML library of Boost

Subject: Re: [boost] [GSOC] XML library of Boost
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2013-05-08 08:08:55

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