[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation
David Megginson wrote: > 1. Create a new interface, org.xml.sax.Parser2, that extends > org.xml.sax.Parser. > [...] > 2. Add the methods to org.xml.sax.Parser, and require applications to > catch NoSuchMethodException when using the new methods, in case > they're concerned about what version they're dealing with. > [...] > 3. Create a separate interface org.xml.sax.ParserProps (or something > like that), and require SAX2 drivers to implement both interfaces. > [...] How about option 4... 4. Leave SAX 1.0 the way it is and place the new interfaces in new packages with the same names. PRO: Allows the members of xml-dev to design the new classes and interfaces without being hindered by subclassing/subtyping considerations. CON: Two separate (and similar in their base functionality) set of classes and interfaces. I wrote to the list awhile ago about an idea to "re-factor" the existing SAX classes and interfaces to make them more generically useful. There was little response from the group. After getting a response from David Brownell asking "Why do this?" and talking to Lars M. at the XML Europe show, I got the impression that there was no interest because noone understand what I was proposing. So I'm back again to try to spark some interest in the idea. The idea of re-factoring the API set comes from the work that I've done on the IBM XML4J parser. Supporting the industry standards meant that we included SAX 1.0 support as well as DOM 1.0. The SAX community did it right and included interfaces for parsing, error handling, entity resolution, etc. The DOM community has no such concept, so parser implementors either a) have to make their own proprietary way of loading documents and performing entity resolution (among other things); or b) use the SAX classes. Most parser implementations, including XML4J, use SAX 1.0 for the features lacking in DOM (and other standards). As a parser implementation, you don't want to publish a set of streaming APIs for a parser instance that is *not* based on streaming callbacks (startElement, etc). BUT... you *do* want to have a generic error handling facility, entity resolution, and ability to at least initiate a parse. For an example, look at the Parser interface. Should a DOM parser be required to allow people to register DocumentHandlers? Probably not, but you do want methods like parse, setErrorHandler, and setEntityResolver. In short, I would suggest that the useful classes and interfaces from SAX 1.0 be moved to another package. Then, the interfaces and classes considered to be part of SAX2 can live in a separate package from the SAX 1.0 API. This would answer the question of how to expand the existing interfaces because the old APIs would not break. I'm not a fan of really long posts so I'm going to post another message with explicit details about which interfaces/classes would move; where they would go to; and what benefits we would get from the new separation. -- Andy Clark * IBM, JTC - Silicon Valley * andyclar@u... 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
|