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

Subject: Re: [boost] [GSOC] XML library of Boost
From: Simon Siemens (simon.siemens_at_[hidden])
Date: 2013-05-09 05:30:55

Am Sonntag, den 05.05.2013, 11:53 +0200 schrieb Bjorn Reese:
> On 05/01/2013 05:15 PM, Stefan Seefeld wrote:
> 
> > As I have argued many times before on this list, I think it would be
> > foolish to try to reimplement all the functionality to support XML.
> 
> I went back to read those discussions, and I think that there are good
> points on both sides. In my experience, most people only need a simple
> XML parser without all the extra features of XML Schema, XSLT, etc.
> Others also need fairly simple extensions such as XPath, and finally
> some need the full monty. It all depend on their use cases.
> 
> > I agree with others that in the context of boost this should be about
> > defining a good XML API, and then map that to existing libraries. In
> 
> Here is an alternative suggestion. Parsing the XML syntax is fairly
> simple, so we could provide a basic XML parser for those with simple
> needs. This XML parser should be based on the Builder design pattern
> (somewhat reminiscient of a SAX interface). The default builder will
> create our own tree/DOM, with which you can do nothing by simple tree
> manipulation. In case we need more complex features, such as XML
> Schema, we could provide a builder for, say, libxml2, which generates
> libxml2 trees that can be used, via the XML APIs you envision, to
> invoke the the libxml2 XML Schema validation.
> 
> This approach allows us to have a simple XML parser for projects like
> Boost.Serialization and Boost.PropertyTree without the need for an
> external dependency. It also allows us to do more advanced stuff with
> external dependencies.

I would prefer seeing it from the following point of view. I separate
the GSOC project from what the library can be in the *best* case.

Mingchao is doing a GSOC project. That project must find a reasonable
result in a limit time. To succeed is important for him. The best way to
reach this goal is to priorities requirements on the project result.

For me, the prioritized requirements are

     1. Define various interfaces (StAX style, SAX style, DOM style) in
        C++ standard library style. This is difficult but most
        important.
     2. Implement the library with one backend. Only with this step,
        other people can really test the library and comment on the
        interface. Thus Step 1 and 2 cannot be separated. Rather
        Mingchao can start with one interface and do step 1 and 2. Then
        he proceeds with the next interface performing step 1 and 2, ...
     3. Add more backends

When Mingchao has a good interface and a good implementation with one
backend for one, two or all three interface styles, he has a reasonable
project result.

If he has some time left, he can implement some more backends. Thus the
question of implementing a native Boost backend is simply a matter of
how far he gets down the prioritized requirements list. Because he
already designs a backend component in the architecture, anyone else
could also implement the native Boost backend. This feature independent
of the GSOC project. It is just important, to a have generic backend
interface.

Cheers

Simon