Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@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...)
|
