Re: [Libxmlplusplus-general] Parser abstraction

[Stefan Seefeld <seefeld sympatico ca>]

Christophe de Vienne wrote:

> > the dom parser's 'parse' method(s) returns a document, the sax parser's
> > 'parse' method returns nothing. How's this semantically the same, or
> > equivalent ?
>
>
> I did not realise that in your exemple of create_document_from_file(...) the 
> parse method returned something.
> For me the parse methods tells the parser to do the actual parsing, after what 
> we eventually go to get the result. Returning the Document would be the 
> semantic of a createDocument method, which could cohexist with parse.
> The two parsers, even if working very differently, has a common point : they 
> parse something. I find logical to put the functions for that action in a 
> common interface.

hmm, from my point of view 'parsing something' is the 'how', while
'creating a document' is the 'what'. In other words, in the DOM way of life
I create a document from file/memory and the fact that something is parsed
is an implementation detail. The SAX model then renders that detail explicit,
i.e. in the world of SAX the fact that something is parsed is the actual semantics.

That's precisely why it is natural to implement a DOM document creation on SAX.

In short, SAX and DOM don't operate on the same level, they both describe two
very different worlds.

> Is it really unbearable to write each time :
> DomParser p;
> p.parse(something);
> Document * doc = p.getDocument();
>
> especially if we introduce the create_document_from_file(...) function ?

well, it's of course not unbearable, but it's unintuitive and inelegant.
Again, I'm excluding stateful (chunk-wise) parsing here.
If parsing is an atomic action, why should I need two methods to get
a document from a file ?

> The situation I was thinking of would be to create a class that is able to 
> read a document from a special source, for exemple network with a weird 
> protocol, and to which we could give the Parser which has to parse it.

well, for 'special sources' there is the 'std::streambuf' abstraction in
C++. Us that when you want to abstract away the physical nature of the source
you are reading from.

> My conclusion for now is that we would loose something (small but still) in 
> removing the common interface, while I don't see what we gain.

We gain clarity and elegance. (did you ever get to appreciate the elegance
of simple mathematical formulae ? If so, you'll surely understand what I mean).

> I'd like to have some more points of view since we'll have to make a decision 
> at last.

heh, you are right. Let's listen to the others :-)

Stefan