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

David Ornstein davido at
Sun Jan 4 02:45:26 GMT 1998

James Clark wrote [03:33 PM 1/3/98 ]:
>David Ornstein wrote:
>> >I am also assuming that we will provide not only a callback interface,
>> >but also an (optional) base class with stub methods that implementors
>> >can override as needed; that means that novice users will not have to
>> >implement all of SAX, even if we do end up with nine or ten methods.
>> This worries me.  My interest is in implementations of SAX-clients in C++.
>> Will I have, as part of somebody's SAX implementation that I'm using, this
>> (optional) base class available to me too? 
>In C++ I can't see any need for a base class separate from the
>interface. You can just have a single class which provides empty
>definitions for all virtual functions.

If the only purpose for the base class is to provide *empty* definitions
for the functions, then I agree.

On the other hand, I'm seeing the base class fill up with a variety of
"default implementations" for many of the functions in the interface.
These "default implementations" will be non-empty and their behavior may
turn out to be expected by clients.   As a result, reasonable
implementations will probably need/want to provide the base class.  This
may well end up meaning that the "default implementations"  actually become
a part of the SAX "spec".

Witness your comment in a previous note:

>If we do this, then the stub (adapter) class should do
>void ignorableWhitespace(char ch[], int off, int count) {
>  charData(ch, off, count);
>This means that users who don't care about the difference can just
>ignore it.


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