Cart
[Home] [By Thread] [By Date] [Recent Entries]
Paul Prescod wrote [05:50 PM 1/3/98 ]: >David Ornstein wrote: >> >> My point is about a relationship: as the usefulness of the base class >> climbs towards necessity, the probability of people using SAX-implementing >> parsers *that don't come with the base class supplied* declines. This is >> only important iff the design of the API is influenced by the assumption of >> the presence of the base class. ... >If SAX implementors are required to provide a base class, clients could >use it through delegation or inheritance, depending on the language. If >implementing a SAX client is going to depend on this base class, then we >must specify its behaviour and require its existence, however. Agreed. >Life would be easier if we did not depend on it. Double agreed. >One way to do this is >to use the common event-handling idiom of returning "false" or "null" >when you want the caller to do the job. So, for instance a >"fetchEntity()" method might return NULL to indicate that the client >wanted to leave it up to the SAX implementation. I think this is a good approach that solves most of the problems. Then all we must do is specify the default behavior. To do this we would get rid of the base class (leaving an empty interface only). We would then go back through the messages from the past few days and gather the places where someone said: "and the base class could just do such-and-such which can be overridden as desired" and move the such-and-such into the formally specified behavior for each event when the Client declares NoInterest. >Yet another way to do it would be to require the registration of objects >for the handling of more complex events: > >registerEventFetcher( EventFetcher fletch ); Registration schemes can be very nice and quite scalable, but I do think the extra cost is worth it. Especially given that your other proposal makes sense. David ================================ David Ornstein Pragmatica, Inc. http://www.pragmaticainc.com 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/ 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...)
|
