[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX RFD: ModSAX Predefined Features

  • From: "Bill la Forge" <b.laforge@j...>
  • To: "John Cowan" <cowan@l...>, "XML Dev" <xml-dev@i...>
  • Date: Mon, 8 Mar 1999 18:05:56 -0500

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.