OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: SAX RFD: ModSAX Predefined Features

[ Lists Home | Date Index | Thread Index ]
  • From: "Bill la Forge" <b.laforge@jxml.com>
  • To: "John Cowan" <cowan@locke.ccil.org>, "XML Dev" <xml-dev@ic.ac.uk>
  • Date: Mon, 8 Mar 1999 18:05:56 -0500

From: John Cowan <cowan@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:

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:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS