text: Some weeks ago David Megginson released a SAX 2.0 beta in Java, and this release appears to be quite close to the final form of SAX 2.0. I've started working on translating this release into Python, but there are some general design issues that need to be thought through before this can be completed. ### XML names The - use (uri, localpart, rawname) for namespace-names, simple strings for ordinary names; rawname must be communicated out of band somehow - use XMLName objects for names, regardless of kind. If these were made immutable and drivers used hashtables of these this might not be too inefficient. - use separate parameters for uri, localpart and rawname, letting some of these be None depending on what was in the document and what the parser supports. ### Driver maintenance Given that SAX 2.0 is larger than SAX 1.0 and also supports various possibilities for extensions, writing a good and complete SAX 2.0 driver can be quite a bit of work. If any parser writers or others feel like contributing to this work by writing and maintaining drivers, then please feel encouraged to do so. If nobody does write drivers, I will do it, but it will probably take longer and they may not be as complete. ### Unicode support Python 1.6 will have Unicode support, and so we should make PySAX 2.0 Unicode-ready. The main part of this is really adding the InputSource object to the library, since this allows applications to feed byte or character streams to the parser in a convenient way. The question is: how will this distinction look in Python 1.6? Will there be one? How should we relate to it? Could we do it simply by using file-like objects with different semantics? ### easySAX vs Pyxie What should we do with this? Should we try to turn Pyxie into what we envisioned easySAX to be, or should we maintain two such libraries? I see advantages and disadvantages to both approaches. One idea I've had for easySAX is something inspired by John Aycock's Spark parser generator, that one could write SAX document handlers with three kinds of special methods: start-element, end-element and element content methods. These could use the 's_', 'e_' and 'c_' prefixes, respectively. Unlike in xmllib, though, the names of these methods would have no significance beyond the prefix. Instead, the documentation string could contain very simple XPath expressions to be used to dispatch events onto the various methods. This should allow us to write easySAX applications that look somewhat like this (self.out is some XML generator class which may or may not be part of easySAX): class MyHandler(GenericEZSAXHandler): def s_doc(self, attrs): ' document ' self.out.write_template("top") def c_sec_title(self, contents, attrs): ' section / title ' self.out.make_element('h1', contents) def c_subsec_title(self, contents, attrs): ' subsection / title ' self.out.make_element('h2', contents) def e_doc(self): ' document ' self.out.write_template("bottom") I'm fairly confident that a layer on top of SAX 2.0 to enable such easySAX applications could be made fairly fast and it should be pretty easy to implement as well. (I've made an early sketch of this.) The only question is what to do with namespace-names. Perhaps the application could declare constant namespace prefixes to be used in the documentation strings in its constructor. --Lars M.