Re: [Libxmlplusplus-general] Parser abstraction

[Christophe de Vienne <cdevienne alphacent com>]

Le Vendredi 31 Janvier 2003 20:06, Stefan Seefeld a écrit :
> 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 have 
common options. One thing I want to be done on it is to be able to configure 
the parsers through this abstact Parser class. The options I'm refering to 
concerns, for exemple, if the document has to be validated or not. I don't 
have in mind the complete list of them but they're is other ones that are 
interesting to have.
The difference between both parsers is the output, but the input is exactly 
the same : we can parse a file, a buffer, a stream, and the abstraction 
defines only how input can be given to the Parser, not the way to retrieve 
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 
abstraction. Your factory function is in fact a DomParser, which returns a 
Document instead of a root_node (this probably better, since it's closer to 
libxml).
Moreover, I personnaly think that having a DomParser class makes more natural 
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 
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