Re: [Libxmlplusplus-general] Parser abstraction

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

Le Vendredi 31 Janvier 2003 20:06, Stefan Seefeld a =E9crit :
> hi there,

hi

>
> libxml++ currently defines an abstract 'Parser' interface,
> which is implemented once to provide a DOM parser, and once
> for SAX.
>
> I'm wondering how useful such ab abstraction is. The implementation
> is completely different, and even for users there isn't anything
> the two have in common, i.e. the semantics of 'parse file "foo"' is
> very different.
>

The main interest I see in keeping an abstraction for parser is that they h=
ave=20
common options. One thing I want to be done on it is to be able to configur=
e=20
the parsers through this abstact Parser class. The options I'm refering to=
=20
concerns, for exemple, if the document has to be validated or not. I don't=
=20
have in mind the complete list of them but they're is other ones that are=20
interesting to have.
The difference between both parsers is the output, but the input is exactly=
=20
the same : we can parse a file, a buffer, a stream, and the abstraction=20
defines only how input can be given to the Parser, not the way to retrieve=
=20
any result.

> I'v (locally) introduced a 'Document' class, which is created
> by a 'create_document_from[file, stream, memory]' factory function.
> Note that this is really a function, as there isn't any state involved.
> Either you end up with a document, or you don't (an exception may be
> thrown to indicate failure).

I don't think having a Document class is incompatible with a parser=20
abstraction. Your factory function is in fact a DomParser, which returns a=
=20
Document instead of a root_node (this probably better, since it's closer to=
=20
libxml).
Moreover, I personnaly think that having a DomParser class makes more natur=
al=20
the fact to have several parser working at the same time.
One other argument I would have is that it is, in my opinion, closer to=20
libxml.

>
> What do you think about such a change ? Do we still need an abstract
> Parser class ?
>

I vote pro ;-)
Unless you prove me I'm wrong of course...

Cheers,

Christophe