Lists Home |
Date Index |
- From: "Bill la Forge" <firstname.lastname@example.org>
- To: "John Cowan" <email@example.com>, "XML Dev" <firstname.lastname@example.org>
- Date: Mon, 8 Mar 1999 18:05:56 -0500
From: John Cowan <email@example.com>
>> > 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:
Again, I'm happy with the interface, but this idea of creating filter structures based
on feature selection seems a bit lame.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)