RE: A Proposal for Refactoring SAX
Andy Clark wrote, <snip/> 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. I *presume* that in addition to your proposal you have in mind that a SAX2 parser could also be a SAX1 parser (at least until SAX1 is retired) which would allow SAX1 clients to interoperate with SAX2 parsers. And I *presume* that you envisage an adapter that would allow a SAX1 parser to be presented as a SAX2 parser, allowing SAX2 clients to interoperate with older parsers. If those two assumptions are right, then your proposal looks fairly plausible, with the proviso that updating clients and parsers for SAX2 will involve (admittedly trivial) recoding which could slow migration. I'm not convinced that this is a better bet than simply adding new methods to the old interfaces ... but I have to admit that that approach has its own problems as my own contributions to the various related threads testify. I think that the biggest problems are likely to be namespace and naming issues. In your breakdown of the post-refactoring situation you've put the core classes and interfaces under org.xml. Then in your discussion you write, > A simple solution for not breaking SAX 1.0 > compatibility would be to move the new org.xml.sax > interfaces and classes into a package named > org.xml.sax2. Again, I'm assuming that org.xml is being taken as being preferable to org.xml.sax. Unfortunately, neither of these options are particularly nice. org.xml is problematic, because it limits the scope for other, future, functionally unrelated APIs, to be released in the org.xml namespace. org.xml.sax2 is just plain nasty, and quite likely to be error prone (I'm sure *I*'d forget the '2' quite frequently ;-) Given that you're suggesting, what is, in effect, a completely new API, why don't we go for a namespace that looks something like this, org xml parser EntityResolver ErrorHandler InputSource Locator Parser ParserException (was XMLException) ParseException (was XMLParseException) helpers LocatorImpl ParserFactory stream AttributeList DocumentHandler DTDHandler HandlerBase StreamParser (was SAXParser) helpers AttributeListImpl StreamParserFactory (was SAXParserFactory) dom DOMParser helpers DOMParserFactory sax // SAX1 stuff here helpers // SAX1 stuff here There's no more effort involved in switching over to this namespace structure that the one you've proposed, and it has the advantage that the names are a little more meaningful ... which'd be useful for novices. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@c... England 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/ and on CD-ROM/ISBN 981-02-3594-1 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