[XML-SIG] saxlib, xml, _xmlplus, etc.

[Mark D. Anderson]

this morning i decided to try out python for an xml hack, rather than my tried-and-true perl.
well, that was this morning, and now it is the afternoon....
i do have tmproc working now (my first goal), but it was heavy going there because
of the lack of road signs for the new person (new to python and its xml tools, but
experienced with xml and other programming languages).

so this is me just letting of steam (i know there is equal or greater chaos in the
current state of perl xml tools, but i already know that chaos).

in particular, what is the relationship between:
- the saxlib available from http://www.garshol.priv.no/download/software/saxlib/
- the xml core package that comes with python 2.x
- the _xmlplus package that comes with the pyxml package from the xml-sig at sourceforge

i can't find any explanation accessible from various top-level pages:
   http://pyxml.sourceforge.net/topics/
   http://www.python.org/sigs/xml-sig/
   http://www.python.org/sigs/xml-sig/status.html
   http://www.python.org/doc/howto/xml/ .
nor do any of the three packages above seem to have any obvious mention of the other two.
nor can i find an "xml and python faq", though surely this issue is an example of such a faq.
another would be: "will old python programs written against sax1 work with the latest pyxml?"

i did find a long, confusing, and inconclusive email thread several months ago on python-dev
http://mail.python.org/pipermail/python-dev/2000-September/009369.html

i've also looked at the ugly hack in xml/__init__.py for loading _xmlplus, though i still don't
know what the difference is between the packages.

btw, http://mail.python.org/mailman/listinfo/xml-sig
has dead links to http://mail.python.org/sigs/xml-sig/status.html
and http://mail.python.org/sigs/xml-sig/links.html

btw also, is it expected that the pyxml win32 installer for 2.0 not work with the python 2.1 beta?
when i ran the installer, it didn't even find the 2.1 installation.
if binary packages are obsoleted by dot revisions in the core, it is going to be painful for everyone.

btw again, another faq should be how urllib deals with win32 drive letters.
it barfs on things like "c:/tmp/myfile.xml" which is inconvenient but understandable, because there is no such thing
as a "c" scheme. using the "|" convention works: "c|/tmp/myfile.xml".
it works with "file:c:/tmp/myfile.xml" and "file:c|/tmp/myfile.xml".
the strings file:///c|/tmp/myfile.xml and file://c|/tmp/myfile.xml fail but file:/c|/tmp/myfile.xml works.
AFAIK this all differs slightly from java and from rfc1738.

-mda