A Proposal for Refactoring SAX

[andyclar at us.ibm.com]

Miles,

> I think we need a bit more detail, because, on the
> face of it your proposal *completely* breaks both
> forwards and backwards compatibility with SAX1.

That's pretty much the question that we have to answer: do
we completely break the compatibility with the old APIs to
design the new SAX right; or do we limit the growth of SAX
because of the legacy issue?

Creating new packages (and thus new API) *does* make
migration an all-or-nothing approach but if the new API has
features that people want, then they will switch.

>   org
>     xml
>       parser
>         EntityResolver
>         [...]
>       stream
>         [...]
>         StreamParser (was SAXParser)

I like your refactorization better! :) It's still
clean and separated for everyone to have a standard
way of doing things.

--
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)