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

Subject: Re: [boost] [GSOC] XML library of Boost
From: Bjorn Reese (breese_at_[hidden])
Date: 2013-05-12 07:00:29

On 05/09/2013 04:26 PM, Stefan Seefeld wrote:

> In particular, it seems you aren't distinguishing between users and
> developers.

In our case there is overlap between them. Some users do not care about
the implementation details. Other users want to use most of the library,
but want to change certain aspects, e.g. adding their own binary XML
frontend, or providing their own DOM.

Having said that, I believe I have satisfied all the "pure" user
requirements that you have mentioned so far.

>> Then create a 'boost-xml-standalone' package without dependencies, and
>> let the 'boost-xml' package depend on the 'boost-xml-standalone' and
>> 'libxml2' packages. Problem solved.
>
> Sorry, what problem is solved ?

The problem you mentioned:

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

> You are citing out of context. Implementing multiple backends has many
> benefits for *developers*, for example as it helps to guarantee that the
> API isn't tied to a particular backend. It should not affect in any way
> *users*, who will only use the boost.xml API (and library), without any
> concern for any particular implementation choice.

So if we want to offer both libxml2 and Xerces wrappers, this would
result two separate Boost libraries?

> While the layering you describe pretty much matches a typical
> implementation, this doesn't have any consequences for users, as these
> layers can't be exchanged. You can't mix a layer from one backend and
> combine it with another layer from a different backend. So why care, on
> an API level ?

I was demonstrating how easy it would be to provide our own
implementation of the well-established APIs (or their C++ equivalents.)
It is possible to mix SAX and DOM from different backends, as I have
indicated for libxml2, which is the only kind of mixing that I have
argued for.

> I believe your point was that you want to be able to implement only the
> "XML lexer", but neither the SAX nor DOM APIs, and still be able to call
> the result "boost.xml", yes ?

No, the XML lexer is more an implementation detail. My proposal
includes the whole range: XML lexer, SAX, XmlReader, and DOM. I have
never argued that Boost.Xml should contain anything less.

XmlReader will be ideal for Boost.Serialization.

A clean C++ separation (builder pattern) between SAX and DOM would give
us the flexibility to plug in different DOMs. This will be ideal for
Boost.PropertyTree, which has its own "DOM". The separation will also
allow us to plug in different SAXs, such as binary XML parsers.

Come to think of it, the XML lexer could be useful for indexing (see
Roger Martin's reference to VDT-XML.)