[XML-SIG] XMLToolkit 0,7,BETA.3 Module parser.py (QA)

[Petko Petkov]

I decided to split the library to smaller files because it is getting 
bigger than I initially expected. But this is fine because now you can 
use just specific parts of the code for specific purposes in your 
application. The package will include a standalone version of the 
library as well which will be out 1500 lines of code including the 
documentation.

First of all I would like to know if this is a good idea?

Now, I am interested in something very specific and I would like to hear 
your comments. The attached file contains the parsing part of my 
library. So far I like the Parser and ParserNS classes. However, I would 
like to add classes that are opposite to them (these classes should 
contain methods that are opposite to those found in Parser and ParserNS, 
more over they have to be called almost in the same way to reduce 
developers frustration when using the library).

The classes that are opposite to Parser and ParserNS are called Composer 
and ComposerNS. The reason I would like to do this kind of separation is 
because if both Parser and Composer are written in certain way using 
certain conventions, less XML would be lost when converting from xml to 
object and vice versa.

I am kind of stuck with the Composition again. The Composer must be 
almost identical in nature to ParserNS but opposite if you know what I 
mean. This is how the parser works.

Parser.parsestring(string, handler) -> None
            |
            |
            V
Parser.splitstring(string) -> generator
            |
            |
            V
Parser.parsenodes(generator, handler) -> None
            |
            |
            V
handler - events


The Composer should do exactly the opposite of Parsing.

Composer.composestring(....) -> string
            |
            |
            V
handler - events
            |
            |
            V
Composer.composenodes(...., handler) -> generator
            |
            |
            V
....

Maybe I am confused and I am complicating the overall design too much. 
KEEP IT SIMPLE, yes this is my philosophy in live but it is much easyer 
to complicate things.

OK, I would like to have a generic interface for Composing xml.
The Parser usually outputs to events in handler. The Composer should 
start by inputing events into handler and somehow composing string, 
streams, files, etc.

Unfortunately, the more I think the more I realize that it will be much 
better if I give up. :) But, I am not a quieter and I really need this 
kind of library anyway.

I was thinking about the traditional way of processing XML files. In DOM 
we have the following stages:

Parse -> DOM -> Serialize

If we expand this stages with SAX it should look like the following:

XML -> Parser -> SAXHandlerToDOM -> DOM -> Serialize -> XML

As you can see this is oneway pipe. I thought that my library should use 
something similar to the following

XML -> Parser -> XMLTree
                    |
XML <- Composer <--+

If we expand it will look like this

XML -> Parser -> Handler -> XMLTree
                               |
XML <- Composer <- Handler <--+

So this is exactly what I want to achieve. Unfortunately, I don't have 
fresh ideas how to do that.

So, by looking at my parsing code (which is not complete), do you have 
any suggestions how to do that. I believe that you guys have more 
experience than me in this areas and maybe you are aware of some 
techniques which I am not.

Thanks in advance and sorry for the long and not that clear to me email. 
If this email is bothering you please take my apologies and ignore.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: parser.py
Url: http://mail.python.org/pipermail/xml-sig/attachments/20051212/2417dd5a/parser.asc