[XML-SIG] Re: saxlib 1.0beta

[Paul Prescod]

Andrew Kuchling wrote:
> 
>         Let me get your proposal clear; you're suggesting that we drop
> having a driver for using xmllib, and just use xmlproc or Expat,
> right?  

No. I guess I'm suggesting we just drop xmllib. Turn it into a wrapper for
xmlproc unless it is faster or otherwise better as it is. My point is that
we should ship xmlproc for the DTD stuff, so once we do that, what's the
point of xmllib anymore? 

We can either think of it as a regex vs. re issue (deprecate one module
for the other) or we could just consider xmllib a deprecated *interface*
to xmlproc (there is probably a precedent for this, too, but I don't know
it).

> I don't really see a problem with that; we have to distribute
> the .py files for DOM, SAX, and whatever else, so adding the xmlproc
> files to the list isn't a big problem.  It's sort of unsettling that
> Python will ship with an XML parser that then won't be used at all by
> the fancier XML tools, but I don't see a way around that, unless some
> subset of the XML package becomes a standard part of Python.

Unless they are large, they might as well all come with Python. Perhaps
the Python library documentation would only document the most important
classes, though.

>         An aside about DOM: I haven't been trying to focus the SIG's
> interest to DOM up to this point, for two reasons.  First, it's still
> in the working draft stage.  Secondly, SAX is much closer to being
> frozen (has Megginson officially stamped his Java implementation as
> 1.0 final?).  Therefore Lars M. has been busier than Stefane...  DOM
> will also present some tricky technical problems, such as thread
> safety.

Yes. The DOM may also present performance problems. Python objects are a
little heavyweight for large documents. Maybe someone will/should write a
DOM in C. I wouldn't expect it to be that large or complicated. It would
primarily shift the property lookup from bulky hash tables to svelte C
code and (relatively) bulky PyObjects to C strings and pointers.

>         (It would be nice if some Java-related code could be in that
> release, too.  Paul, what's the status of your work with JPython?)

I was waiting for the next SAX release, but now I'm in the final stages of
a book. Keep me updated on your progress and I'll try to squeeze my stuff
in before 1.0. I could do a tutorial and an example program.
 
>         Once that's done, hopefully some brave souls will start trying
> to use SAX, so comments and bug reports will begin coming in.  At the
> same time, we can worry about JPython, about DOM, and about Unicode
> support for Python.  I'm not sure which should come first; perhaps DOM
> can still wait, while we try to get a good solution for Unicode.  On
> the other hand, Unicode support won't be added as part of the 1.5
> development cycle, so it would have to wait until the next major
> release of Python, and that's probably a long time off.

Unicode should definately be higher priority than DOM, IMO. I would go so
far as to say that Unicode should *determine* the date of the next release
of Python (though I don't care if it is called Python 1.5.2 or Python
1.6). Maybe I'm naive about what it means and takes to release a new
version, but what's the harm in perfecting the XML and Unicode stuff and
releasing it as 1.6 in say, three months? It could even be a minor
publicity event. If we were the first with a C implementation, we might
have the fastest DOM implementation at the time of release.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Can we afford to feed that army, 
 while so many children are naked and hungry?
Can we afford to remain passive, 
 while that soldier-army is growing so massive?
  - "Gabby" Barbadian Calpysonian in "Boots"