Re: SAX Future
>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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format