Re: SAX RFD: ModSAX Predefined Features
From: John Cowan <cowan@l...> >> > 2) This method is allowed to throw a SAXNewParserException, which >> > encapsulates a replacement parser. The application should use >> > the parser inside the exception in place of the original parser. >> > This allows parsers to push filters on top of themselves, which >> > complements the ability of applications to push them. >> >> I think that this could be layered on top of SAX, simply by >> subclassing SAXNotSupportedException. > >Yes, but by making it part of the core SAX protocol for setting >features, we guarantee universal support for it. A parser that knows >itself to be naive about namespaces can load the NamespaceFilter and >push it on top of itself, almost transparently to the application. >Otherwise, every application that wants namespace support needs >specialized knowledge about how to recover from SAXNotSupportedExn. There are really three approaches here: 1. An application pushes a filter "on top of" a parser. In this case, the application starts with a parser and chooses to augment it with a filter. 2. The application requests a feature of the parser and the parser elects to wrap itself in a filter. For efficiency reasons(?), it asks the application to now use the filter in place of itself. 3. An application works with a pseudo-parser. It asks for various features and the pseudo-parser selects a parser and a set of filters which together can deliver the requested capabilities. I do like David's proposal--its pretty open ended. The method get(infoID) will even serves as a front-end for aggregation! But I see a problem in trying to go too far on the feature selection path. The assumption seems to be that we are dealing here with a completely orthogonal set of features which are just selected or not as needed. There is no sense of structure or architecture here. I'm not sure that this is a useful model. Frankly, I much prefer Simon's layered approach: http://www.simonstl.com/articles/layering/layered.htm Again, I'm happy with the interface, but this idea of creating filter structures based on feature selection seems a bit lame. Bill 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