SAX RFD: ModSAX Predefined Features

[Bill la Forge]

From: John Cowan <cowan at locke.ccil.org>
>>  > 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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)