Refactoring SAX 1.0

[andyclar at us.ibm.com]

In working on the IBM XML Parser in Java, we have found that
a number of classes from the SAX 1.0 API were useful to all
of our XML parsers, regardless of the higher level parser
API. For example, entity resolution, error handling, and
parse location are common to all XML parsers. Even parsing
a document from an input source is the same.

We think that it would be extremely beneficial to XML parser
users to break out the common classes into a separate package.
In this way, users have consistent access to the XML parser
and basic parser features even when the results of parsing
are different. For example,  parsing and error handling are
common whether the result of the parse is an event stream,
tree structure, JavaBean, transaction process, etc.

Since there is ongoing work to define the SAX2 interfaces,
it seems that now would be the perfect time to address whether
refactoring the SAX 1.0 classes makes sense.

Have other users encountered these issues and is there
interest in refactoring the SAX 1.0 classes in order to take
advantage of the commonality?

--
Andy Clark * IBM, JTC - Silicon Valley * andyclar at us.ibm.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)