Re: [Libxmlplusplus-general] Parser abstraction

[Christophe de Vienne <cdevienne alphacent com>]

Le Samedi 1 Février 2003 20:34, Stefan Seefeld a écrit :
> Yet I maintain that there is nothing justifying a common base class for
> SAX parsers and parsers that create a DOM document. There isn't any code
> both would share, and there isn't any semantic commonality that could
> possibly make someone want to use an abstract parser reference, not knowing
> whether a call to 'parse' would mean 'generate a document' or 'call back on
> event X'.

The way parse_stream or an eventual parse_chunk is implemented could be 
shared, since only the parser state is initialised differently (and partialy 
only, since some options are the same ones).
Even the parse_file and parse_memory could share the same implementation in 
both classes if we used more low level libxml calls.

>
> And I don't see the relevance of wanting to parse two things at the same
> time. What do you mean with 'at the same time' ? In different threads ?
> Chunks belonging to different documents ? If it's the second, I agree that
> we need a parser class (see above).

I was thinking of both cases, but more specialy of the second one.

> But if you aren't parsing in chunks,
> there isn't any state to remember that couldn't be passed to the actual
> 'parse' call (such as whether or not to preserve white space etc.)
>

Imagine I have several documents to parse with the same options. I could 
instanciate a single parser instance that would become a factory of Document, 
parameterized once for all, and without having to give theses options each 
time to a factory function (which would mean store them somewhere).
Moreover, considering the underlying C layer, we could have not implemented 
any accessor to use a particular option. Having the parser state initialiased 
by the parser instance and accessors before doing the real parsing would let 
the possibility to alter it through a cobj() accessor in a herited class

> In a nutshell, yes, I agree that in case of chunks a dom parser would be
> a solution. But even then there isn't anything this parser has in common
> with the sax parser.
>

The inputs are in common. In libxml for exemple, the xmlParseChunk is the same 
for a sax or a dom parser : a Document will be produced if I don't specify a 
saxHandler. Still in libxml, the domparser is built on top of saxparser : the 
two concepts share more things that it seems at first sight.
Having an abstract Parser class will, in my opinion, reflects better the 
underlying lib.

Regards,

Christophe.