SAX Future

[Michael Kay]

>Yes, but how do we accomplish this?  Do we invent a new package name
>for SAX 1.0.1 to avoid collision?


I suspect we have to - unless someone knows a better way. Given that parsers
include the SAX interface classes in their distribution, we don't really
want people to have several different definitions of the same interface on
their classpath.

Are there any other areas where you can get multiple implementations of the
same Java interface from different suppliers? If so, how do they solve the
version control problem? Or have we achieved a first?

There are other version control nasties lurking in the "helper" classes. For
example SUN's distribution includes a modified version of ParserFactory,
under the original package name and class name. (The modification is to load
SUN's parser if no other parser was specified). This means if you have
downloaded more than one SAX parser, it becomes somewhat random which
version of the SAX ParserFactory class gets loaded. You can't even write a
ParserFactoryFactory to influence the decision! However well-intentioned
SUN's actions, I think this should be banned - and we should design SAX
1.0.1 to make it unnecessary.

Mike Kay


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