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