[XML-SIG] easySAX

[Fred L. Drake]

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

Lars,
  Have you written a version with the dispatcher to drive these
methods?  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.

 > 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?

  Sigh.  I'm very undecided about namespaces.  The concept is really
good, but I've shied away from using them.  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).  I'd be more likely to use the
DOM if I care about namespaces (and I almost cared about them the
other day!).

 > As for packaging, I think this should be a separate package from SAX
 > itself. Other convenient interfaces on top of SAX are both possible

  How about xml.easysax?

 > 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?

  In general, I think it's a good idea.
  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.  My name isn't Andrew, and chances are good it won't ever be, 
but *I* think it belongs there if people are likely to want to use
it.  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.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives