> Typically, low-level stuff such as this I feel should be
> implemented once and then reused over and over again. There are
> only so many ways to write character encoders / decoders and I
> would wager that most parsers out there pretty much have very
> similiar implementations for reading from byte streams. XML's
> beauty is not in the fact the spec defines support for about 6 or
> so different character encoding formats, it is in everything else.
> If another character encoding format comes out, then every SAX
> parser will have to possibly do a rewrite. If people could agree
> upon one good efficient dependable implementation, then no one
> (other than the people doing the 600 or so lines of character
> encoding implementation code) will have to do a thing. Of course,
> people could plug in their own character encoder / decoder
> implementations if they so choose, but at least they would have the
> choice.
The nice thing here is that all of this can be built on top of SAX
instead of inside it. Some implementors are already complaining --
quite understandably -- that SAX has grown far too large. However,
there is a great opportunity here for someone (or a group of people)
to write a separate SAX toolkit that includes what you suggest and
much more (such as classes implementing AttributeList and Locator,
with copy constructors).
All the best,
David
--
David Megginson ak117@freenet.carleton.ca
Microstar Software Ltd. dmeggins@microstar.com
http://home.sprynet.com/sprynet/dmeggins/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)