Lists Home |
Date Index |
- From: "Bill la Forge" <email@example.com>
- To: "XML List" <firstname.lastname@example.org>
- 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
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:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)