Opening SAX for better filter support

Bill la Forge b.laforge at
Thu Mar 11 18:03:35 GMT 1999

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

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.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list