Re: [boost] [xml] Brainstorming / Request for Comments, Suggestions, Opinions ...

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2006-09-07 14:55:04

Sebastian Redl wrote:

> It seems to me that your earlier proposal was mainly about a few API
> specifications, that were then supposed to be implemented somehow -
> preferably
> on top of an existing XML library, in order to avoid reinventing the wheel.
> 
> This idea certainly has a lot of merit, but it also has some distinct
> disadvantages.
> 
> First, an API specification is nice for standardization, but not very usable
> within the context of Boost. In order to be useful, there must be at least
> one
> implementation of the API. Otherwise, the specification is worth nothing
> to the
> end user.

Indeed.

> This implementation must exist within Boost, i.e. it must be completely
> contained within Boost.

Huh ? While I can see advantages in code being contained within the boost
source / binary packages, I think that is by no means a requirement. (FWIW,
we had a discussion about that specific point, and agreed that there was no
such requirement.)

> Libraries like Regex and Iostreams offer enhanced
> functionality if certain external libraries are available, but they will work
> without them, too. Obviously, the Xml library could not work without the
> external XML implementation if it is just a wrapper around it.

Quite correct, and in order to make sure the API can be implemented by other
means (i.e. without libxml2) we have to make sure it is neutral, i.e. no
implementation-specific aspects percolate through to the API.
But it doesn't mean the reference implementation has to be free of third-party
code.

Otherwise, would you prefer boost.python to ship its own 'Bython' implementation ?
;-)

> This means that, if the library is a wrapper around an external one, the
> external library (let's for argument's sake assume libxml2, which seems to
> bring
> less licensing trouble compared to Xerces, the only other sufficiently
> complete
> XML library I can think of) must be distributed with Boost.
> What does this entail?
> The library must build as part of Boost. I haven't checked, but I assume
> libxml2's build system right now is based on automake. That would have to be
> translated to Boost.Build. As part of this process, configuration macros
> might
> need to be translated. This could easily lead to a real fork of the code
> base.
> Unless Boost wants to rely on the regression testing done by the authors of
> libxml2, regression tests, portability tests and everything else must be
> written and maintained.
> And last but certainly not least, there's the licensing issue. Boost is
> working
> hard to get all code under the Boost license. Would we want an external
> library
> under any other license, no matter how permissive, in that code base? Or
> would
> the authors of libxml2 permit relicensing of the source? (As a programmer,
> I'd
> rather reimplement a library than pursuing such goals. ;) )
> 
> Second, the recommendation focused on a DOM-style API. As at least two people
> [1][2] pointed out, DOM-style APIs are not as universally useful as other
> APIs.

Indeed, I was focussing on the DOM-style API, but that's only because I
happened to use it at that time, and so had an immediate need.
I indicated that a SAX-like (better: XMLReader-like) API would follow,
if there was enough interest. (libxml2 naturally builds its own tree API
on top of such an xml_reader.)

> To sum up, I do believe we should reinvent the wheel here. But we should
> create an improved wheel, and I think the Boost community is uniquely
> suited to
> create a wheel that works particularly well with C++.

What improvements would your implementation offer ? (Note that I'm specifically
asking for the implementation, as the whole argument seems to be much less
concerned about the API. Or, would there be API improvements that couldn't
be implemented using third-part libraries such as libxml2 ?)

Thanks,
                Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...