[XML-SIG] Python 1.6 XML APIs

[Paul Prescod]

"Fred L. Drake, Jr." wrote:
> 
> Paul,
>   This all sounds really interesting!
>   I am hesitant to say we'll accept several new modules for 1.6 at
> this point, however.  Perhaps it makes sense to pick a couple that
> offer the flexibility (saxlib?) and ease-of-use (pulldom? minidom?).

Pulldom depends on minidom so you get two for the price of one.
Actually, if I was smart, I would have just concatenated the code and
called it one module...is it too late for me to pretend that they were
never two modules. :) :)

Once you have minidom, pulldom gives you so much bang per buck that I
would hate to lose it. I really think that it is alot easier to use than
SAX because it isn't as generalized and optimized.

I am willing to lose qp considering our timelines. We can try again for
1.7.

I am actually not that tied to SAX 2 either. PyExpat needs to expose a
SAX 2-compatible interface but Python doesn't have first class
"interface modules" so that doesn't imply much more than a little bit of
wrapper code.

If we DO want to put SAX in, then we would still probably lose the
drivers. Drivers could be distributed with parsers. That takes us down
to basically 4 files: 

 saxlib - the core library -- probably necessary
 saxexts - most of this is not useful until you have more than one
parser
 saxmisc - this is basically interface documentation not code
 saxutils - useful, but maybe overkill for the builtin library

I could go either way on including any of them. You *can use SAX* with
only saxlib. In fact, the only thing I can think of that you really,
really need is SAXException and SAXParseException. Most of the rest is
interface documentation (empty base classes) and methods to help you
find parsers (not relevant until you have multiple of them).

Of course Lars has thought about this alot more than I have. I think his
opinion would be valuable.

So I'm willing to push for:

 mini/pushdom
 "minisax"
 pyexpat

and leave the rest to the XML-sig distribution.

> If we can narrow it down quickly, I can talk to Guido about what
> should go in, but we're essentially at feature-freeze now.  We can be
> a little more flexible for library modules, but each module that gets
> added is essentially a promise that it'll be maintained for at least
> half of all eternity.  More, if anyone uses it.  ;)

The *dom modules are really so tiny and easy to maintain...no C code,
few external dependencies...few published methods...I wish I had thought
about this 80/20 point a year ago!

I'll send them to you tonight and you'll see what I mean. I just need a
tiny bit more testing. Too bad about your talk!!!

>   Does it make sense to make the XML support in the core a package?
> It sounds like we'll have as many as three new modules: pyexpat,
> saxlib, and ????dom.  There's also the legacy xmllib to think about.
> We don't want to clobber the "xml" package namespace, either.  Perhaps
> xmllib should become a package which imports its current contents from
> a sub-module, and also contains the new modules (except pyexpat)?

I think that the last time we got into this discussion it became a
rathole of "shouldn't we packagize the whole Python library?" and "what
does this mean for the Python xml distribution". I don't want to "go
there" unless these questions have been answered. The path of least
resistance is to packagize later with everything else.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy