[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ModSAX (SAX 1.1) Proposal
James Clark writes: > I don't see the point of this. It doesn't seem to buy me anything over > what I can already do using normal programming language features: > interface PingParser extends Parser { > void setPingHandler(PingHandler handler); > } [snip] Thank you very to to James for his comments. James's suggestion complicates the the chain-of-responsibility pattern for SAX programming, and that pattern has proven very productive in SAX work so far. For example, consider the following set-up: 1. the application is a client of 2. an attribute-inheritance filter, which is a client of 3. a ping filter, which is a client of 4. the XP ModSAX driver Only #3 will implement the PingParser interface, so my application will have to know to register its DocumentHandler with (2) but its PingHandler with (3). Using the ModParser interface, the application could register both of its handlers with (2), the top-level ModParser; (2) would accept the DocumentHandler object directly (as it must), and would pass the PingHandler along the chain to its parent filter; any ModHandlers that made it to the XP ModSAX driver and were not recognised would cause a SAXNotSupportedException. > The ModHandler class seems particularily useless. It just creates > a completely unnecessary dependency between handler classes and the > SAX package. You could use Object just as well. This is admittedly a matter of taste, but empty interfaces are common in the Java world as a statement of intent, and they do have the advantage of slightly-stronger type checking. I far prefer void setHandler (String handlerID, ModHandler handler) throws SAXNotSupportedException; to void setHandler (String handlerID, Object handler) throws SAXNotSupportedException; because stupid bugs are more likely to be caught at compilation time rather than runtime, and that's always a win for creating robust code. > None of this seems to solve the real problem which is actually > defining the handlers that are needed to provide the functionality > missing from SAX 1.0 (like the handlers for comments, namespaces > etc that were in the previous draft). This design provides the infrastructure for adding those handlers -- once we have a standard way of adding new handlers to SAX without rewriting the interface, we can define some implementations of ModHandler for lexical information, etc., exactly as in the previous draft. With this new infrastructure, we can also now specifically request (non-)validation, (no) namespace processing, external entity (non-)expansion, etc., and we can do capability discovery in a more robust way. A year or two from now, we won't need to issue SAX 1.2 to handle, say, data-typing. All the best, David -- David Megginson david@m... http://www.megginson.com/ 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
|