Re: [boost] Re: API Review request: XML APIs for C++

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-12 08:14:39

Gennadiy Rozental wrote:

>   Here is my vision on the problem, couple ideas on XML parser design:
> 1. No xmlChar type -> template parameter

hmm, what code did you look at ? I *do* use templates for this. I use
'xmlChar' internally as that's the type used by libxml2. But that
part is private, the public interface uses a 'string' template parameter
in conjunction with a 'convert' trait that delivers the in/out
conversion between xmlChar and 'string'.

> 2. No hardcoded virtual functions. In some refinements it still may come to
> use virtual functions here and there. One way to achieve this is to supply
> implementation as template parameter:

I don't understand what's so 'outdated' about virtual functions. Why
must I avoid them and use templates everywhere ?

But I see your point, I could bind individual callback handlers with 
boost::function<>...

> 3. Most probably above may not be good enough. For better reusability let
> then use multiple template parameters for different types of handlers:

Hmm, that looks pretty clumsy, considering the number of different
handlers, and thus the numbers of template parameters. Why not just
bind each handler callback individual to the parser, as parser already
is a stateful object.

> 4. There maybe several "flavors" of document handlers. One simple: as usual
> concrete handler needs to expose methods like on_start_element and accept
> the name plus attributes. As an alternative we may consider document
> handlers supporting "named callbacks" (in a form of boost::function<...>)
> registration. IOW such handler would call a callback when element with
> desired name encountered. There are other alternatives.

interesting. However, I'd suggest to add such convenience on top of a
basic layer that is 'functionally complete'.

> I am sure that there also could be Spirit-based or Spirit-like solution.
> Check with the Spirit guys.

Well, sure, people can always rewrite xml parsers. But as I suggested
earlier, that is a *big* job, and there is much more than parsing, at
least if you look not only at sax but dom etc.

Regards,
                Stefan