Re: [Libxmlplusplus-general] Parser abstraction

[Christophe de V. <cde...@al...>]

Le Samedi 1 F=E9vrier 2003 20:34, Stefan Seefeld a =E9crit :
> 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 knowi=
ng
> 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=20
shared, since only the parser state is initialised differently (and partial=
y=20
only, since some options are the same ones).
Even the parse_file and parse_memory could share the same implementation in=
=20
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=20
instanciate a single parser instance that would become a factory of Documen=
t,=20
parameterized once for all, and without having to give theses options each=
=20
time to a factory function (which would mean store them somewhere).
Moreover, considering the underlying C layer, we could have not implemented=
=20
any accessor to use a particular option. Having the parser state initialias=
ed=20
by the parser instance and accessors before doing the real parsing would le=
t=20
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 s=
ame=20
for a sax or a dom parser : a Document will be produced if I don't specify =
a=20
saxHandler. Still in libxml, the domparser is built on top of saxparser : t=
he=20
two concepts share more things that it seems at first sight.
Having an abstract Parser class will, in my opinion, reflects better the=20
underlying lib.

Regards,

Christophe.