Lars Marius Garshol larsga@ifi.uio.no
21 May 1999 18:19:10 +0200

* Lars Marius Garshol
| <URL: http://www.python.org/pipermail/xml-sig/1999-May/001199.html>
| with start_*/end_*/pi_*/ppi_* methods.

* Fred L. Drake
| Have you written a version with the dispatcher to drive these
| methods?  

Not yet. I was planning to do it if the proposal was accepted.

| I don't think there's a lot of code, but if you've already written
| it, it might be nice for people to have a chance to play with it.
| This would be especially good to play with for those of us with a
| lot of code based on the xmllib API, which I find I still use.

I'll post it the moment I complete it, provided I do complete it at
* Lars Marius Garshol
| Also, do we need to do anything in particular to deal with
| namespaces here? Should we reserve a namespace-URI callback argument
| to slot them into when SAX 2.0 is in place?
* Fred L. Drake
| Sigh.  I'm very undecided about namespaces.  The concept is really
| good, but I've shied away from using them.  

This is more or less my reaction as well, although I'm no fan of the
form the actual final Recommendation got, nor of the place it seems to
occupy in people's minds.

| Building all the support for documents that are likely to use
| several (known) namespaces that all need special processing is still
| a pain, especially using the event-based interfaces (SAX, xmllib).

This might be true, although I haven't tried or even thought much
about it. Some splitting filter that sends different namespaces to
different handlers might help, but I feel the basic problem is that
none of these have any provision for namespaces at all. And that is
what I want to avoid if we do easySAX now, since we won't be able to
insert this parameter later without breaking things.

But maybe we should have a separate NamespaceAwareDocumentHandler
instead? One nice thing would be if the parse method automagically
detected which kind of handler it received as a parameter and then
either applied or did not apply namespace processing.

* Lars Marius Garshol
| As for packaging, I think this should be a separate package from SAX
| itself. Other convenient interfaces on top of SAX are both possible
* Fred L. Drake
| How about xml.easysax?

Sounds good to me, although I've already used the file name ezsax on
my own disk. However, what I really meant was that I thought this
should be a separate release, with its own home page, ZIP file and
version history.
* Lars Marius Garshol
| If nobody protests I'll go ahead and do this, although I'd feel much
| easier about it if people actually voiced support for this. Andrew,
| do you think this belongs in the XML package?
* Fred L. Drake
| Perhaps the first cut can simply be a module that gets posted to the
| list; if it's well received, it can be added to the XML omnibus
| package.  

That's certainly an alternative, and it's by no means incompatible.
One reason I'd like it to be more than just something posted to the
list is that then it becomes easier to document it, refer to it and
also to discover it for new users.

Also, if this becomes widely used I suppose the more speed-conscious
may want to bypass SAX entirely and write easySAX drivers on top of a
parser. I think this is especially interesting in a JPython context,
where it can be built on top of Java SAX.

Opinions on this are welcome. Personally, I like packages that are
available separately as well as a part of a bigger lump.

| I think we should avoid the Perl-XML problem, with lots of different
| packages that people need to update independently.  I'd like to be
| able to say "this software requires the Python XML package:
| ftp://ftp.python.org/..." and be done with it.

I certainly agree with this.

--Lars M.