SAX: do we want a base class (was Re: SAX: towards a solution)

David Ornstein davido at
Sun Jan 4 02:54:17 GMT 1998

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.


>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 Ornstein
Pragmatica, Inc.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
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