[XML-SIG] SAX 2.0, again

[Lars Marius Garshol]

* Ken MacLeod
| 
| [representing XML names]
| The proposal I made earlier (passing objects instead of positional
| parameters) is another solution.

Yeah, I saw that after I'd posted and the list email had been fixed
again. I've looked at that proposal and want to think it through a
little before I say anything about it.

| Adding InputSource may not be necessary if there was a method
| parseCharFile() to specify character streams.

We still need to be able to return something from EntityResolver that
the parser can read from correctly, and I think InputSource is the way
to go. It's a very simple class anyway, and would be implemented only
once (in the SAX library).
 
| [easySAX vs Pyxie]
| 
| If I understand correctly, yes, having a SAX filter that calls
| tag-based methods names should be really easy.

It would, and we already have that. What I was thinking of was using
documentation comments to do dispatching on instead, since this would
give us more advanced dispatching.

You could do things like

  def c_beep(self, contents, attrs):
     ' section / title '
     self.out.make_element('h1', contents)

| I think the part I don't understand about easySAX and Pyxie (and
| it's probably from not having the opportunity to use them) is: why
| isn't the SAX binding already this easy?

It's a good question. The main reason is that I wanted something very
simple that could be implemented by parser libraries without too much
fuss and also something that could easily be put on top of databases,
converters and other kinds of tools to produce XML output.

Similarly, I wanted it to be possible to make competing toolkits for
making XML processing simple on top of a standard parser API so that
it would be trivially easy for all these toolkits to support all XML
parsers (and other XML generators) available in Python.

--Lars M.