Re: [Libxmlplusplus-general] Parser abstraction

[Stefan S. <se...@sy...>]

Christophe de Vienne wrote:

> There is one case, which we did not implement yet although, that justify 
> having a state : libxml propose an interface, xmlParseChunk, that allow to 
> parse a document by small pieces. With a Parser class it will be easy and 
> natural to have, for exemple, two parsers building two document at the same 
> time without interfering. Even if it's a rare case, there is not much to do 
> to make it possible with a parser object, while having a function would force 
> us to add a state.

I don't understand that statement. Yes, I agree, if we ever want to parse
a document chunk-wise, we need a stateful parser that can remember where it
left of. I fully agree that for this case we want a parser class.

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'.

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). 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.)

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.

Regards,
		Stefan