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

Subject: Re: [boost] [GSOC] XML library of Boost
From: Bjorn Reese (breese_at_[hidden])
Date: 2013-05-08 07:21:33

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.