Proposed extensions to SAX

[Lars Marius Garshol]

I'm thinking of adding some methods to the Python version of SAX and
feedback from the Python list indicates that I should propose that it
be added to the main SAX interface, so here goes:

Proposed changes:

Creating a SAX interface in the SAX module with these methods:
 - sax_version, returns the version number of the SAX version implemented
 - saxlib_version, returns the version number of the SAX implementation
 - create_parser, returns a parser (see below for how the method
   decides which parser to return)
 - get_parser_list, returns a list of the parsers in the order they
   will be tried by create_parser. The first parser on the list that
   is present will be returned. (Any SAX implementation must have a
   predetermined default list.)
 - set_parser_list, lets the user decide parser priority
 - get_present_parsers, returns a list of the parsers that are
   actually present. (May be difficult to implement in Java (and other
   languages), but should be pretty straightforward in Python. This 
   method should therefor be allowed to return None/null/nil if it
   isn't supported.)

Adding two methods to the parser interface:
 - parser_name, returns the name of the parser used (to allow
   users to check which parser they are using)
 - parser_version, returns the parser version number

Rationale:

I think these extensions give users a simple and standardized way to
control which parser is used and also to detect this, in order to
handle differing versions and their differences in XML support and
bugs. 

The package methods should only be implemented once for each language
and should be fairly simple to implement. They can also be kept
apart in the documentation, so as to not clutter the API for those who
don't need/want these features.

The parser methods should be trivial to implement and shouldn't
clutter the interface too much.

If this goes through a naming scheme should be decided for parsers. I
think the class name (with full package name) should be used, in order
to avoid confusion and also for backward compatibility. It would also
give a simple way of distinguishing between the validating and
non-validating versions of parsers that have different classes for
this. (Any that don't?)

(And, yes, the method names should perhaps be changed to something a
bit more Java-like. :)

-- 
"These are, as I began, cumbersome ways / to kill a man. Simpler, direct, 
and much more neat / is to see that he is living somewhere in the middle /
of the twentieth century, and leave him there."     -- Edwin Brock

 http://www.stud.ifi.uio.no/~larsga/      http://birk105.studby.uio.no/


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)