[XML-SIG] SAX2: saxlib 1.0 fixes
Lars Marius Garshol
larsga@ifi.uio.no
27 Mar 1999 20:22:28 +0200
- We haven't defined what kind of argument setLocale should take,
partly because no parsers actually used it at the time. However, now
xmlproc supports localization and expat has what it needs to start
doing so (but at the moment only supports English and seems to have
no way of setting the locale (at least the version in the CVS tree)).
We need to take the following into account here:
- xmlproc: Uses case-insensitive ISO 3166 language codes
- Java locales: Uses a combination of lower-case ISO 639 country
codes and upper-case ISO 3166 language codes
- Python locale module: Uses the ANSI C library, which seems to be
missing in my copy of K&R, and the module documentation doesn't
explicitly say what the locale name is, but from the examples it
appears to be either ISO 3166 or ISO 639 codes.
- expat: How this will work, and if it ever will is unclear.
With this in mind I propose that setLocale should take a pair of
case-insensitive ISO 3166 and ISO 639 codes. xmlproc will then
ignore the country code, the JPython driver will do case conversion
and pass a java.util.Locale object to JavaSAX and hopefully this
will work with expat as well.
- The InputSource interface has been left out of PySAX, and should
be introduced now, as that solves a problem with EntityResolver and
also since Python will be getting Unicode support soon. If we agree
on this I'll make a draft and start a separate thread on this.
- The PySAX EntityResolver returns a system identifier, whereas the
Java version returns an InputSource. (Thanks to Paul Prescod for
pointing out the problems with this.) For consistency, and also to
enable users to provide custom protocol support, I think PySAX
should follow suit. Is anyone against this?
- The get method on AttributeList is missing if AttributeList is to
behave exactly as built-in dictionaries. Should be added. (Thanks
to Neelakantan Krishnaswami for spotting this one.)
--Lars M.