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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Opening SAX for better filter support

[ Lists Home | Date Index | Thread Index ]
  • From: "Bill la Forge" <b.laforge@jxml.com>
  • To: "XML List" <xml-dev@ic.ac.uk>
  • Date: Thu, 11 Mar 1999 13:07:06 -0500

A fixed API has lots of advantages in terms of service/user.
Each can be implemented to the API without being bound to
the other. And if you do need a non-standard feature, you 
isolate the code that has such a dependency. Overall, a
very manageable situation unless you move too far out of scope
of the API.

Introduce middleware and everything changes. Now you
want an open API that permits unanticipated interactions 
between the service/user without needing to completely bypass
the middleware.

With the advent of SAX filters, we have now moved to having a
need for a more open API, and David's proposal seems to
fit that need precisely.

Consider a complex of stacked and nested filters wrapping
a parser. This composition is something which might be best
done separately from the application itself, but the application
may still need to access various parts. Indeed, a good design
would keep as much of the application as possible independent
of any particular structure, as the structure may need to
change if we change parsers or introduce more appropriate
filters.

Think of this complex of parser and filters as some kind of aggregate
that is best treated as a gray box by the application--the application
may need to identify and interact with various parts of the aggregate,
but doesn't know the overall structure.

The new get and set methods are exactly what we need. We can
present a named object to the aggregate and, by routing the 
request through the aggregate, the component which knows 
what to do with that object can process it. Conversely, we can
request a reference to a component or result by name and the
appropriate component is able to respond.

Now while not of this may be terribly efficient, it doesn't need to be--
these are calls that are made for configuration or to access
results. So it should work and work beautifully.

Bill



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