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.
Life would be easier if we did not depend on it. 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.
Yet another way to do it would be to require the registration of objects
for the handling of more complex events:
registerEventFetcher( EventFetcher fletch );
Paul Prescod
-- http://itrc.uwaterloo.ca/~paprescoArt is always at peril in universities, where there are so many people, young and old, who love art less than argument, and dote upon a text that provides the nutritious pemmican on which scholars love to chew. -- Robertson Davies in "The Cunning Man"
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/ 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)