Re: SAX Future
Re the Java parts of that future: Michael Kay wrote: > > >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. As has been pointed out, strict binary compatibility for interfaces ensures that this won't happen. How to ensure that in the face of multiple distributions gets into some legal issues. Since SAX is in the public domain, it's got an odd set of problems ... anyone can ship whatever they want and call it SAX, in effect. (We have no intention to do such a thing. Sun is very interested in "doing the right thing" here, working with David Megginson and others.) I think that part of the solution is to have conformance testing both for SAX interfaces and for parsers implementing them. Two parsers should agree on what "fatal errors" are, for example, as well as the data passed from the parser given specific input. (Modulo the fact that a block of text can be reported in one block or many, and so on.) > 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). That is, a configuration error is transparently recovered from. Anyone asking for a specific parser will always get it. Anyone wanting errors has countless ways to generate them ... ;-) Of note: This is the first comment we've received on this clearly documented change! The method "Create[s] a new SAX parser using the org.xml.sax.parser system property", per spec. > However well-intentioned > SUN's actions, I think this should be banned - and we should design SAX > 1.0.1 to make it unnecessary. I'm curious how you'd design an updated SAX to not have the capability of such a configuration error. Get rid of the notion of a default system configuration, pushing the problem up to application developers? That is the approach some other systems take. Re "banning" ... without some conformance testing, what would that mean? - Dave 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