A Proposal for Refactoring SAX

[David Megginson]

Leigh Dodds writes:

 > While we're at it, why not add some additional DOM 
 > utilities, like writing out a DOM to disk, etc.
 > 
 > Overall I really like this refactoring approach.
 > 
 > Interested what David has to say though...

I think that it might raise SAX up a little too high -- SAX is
designed to be a simple, very low-level parser interface, like a
device driver in Unix or Windows; it was not meant to become a general
XML-processing infrastructure.  Personally, I always expected that
people would build more sophisticated stuff like SAXON on top of SAX.

One of the reasons that SAX succeeded is that it stayed simple and
kept out of people's faces.  Personally, I still fantasize about a new
version of SAX with even fewer handlers and callbacks, since there are
really only five things that 98% of XML applications have to know
about:

- elements
- attributes
- character data
- processing instructions
- errors

Unfortunately, XML 1.0 (and the current Infoset WD) won't let me get
away with that.

By the way, how many SAX implementors have ever used the SAX 1.0
DTDHandler interface in a real-world installation?  The XML 1.0 spec
requires processors to report the information in that interface, but
I'd be very interested to know about actual usage patterns.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

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/ and on CD-ROM/ISBN 981-02-3594-1
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)