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

[David Ornstein]

David Megginson wrote [04:51 AM 1/3/98 ]:
>We have had an interesting discussion about SAX ("simple API for XML"?
>I cannot remember) the past few weeks, and now it's time to get
>specific.

Excellent.  It's good to see someone grab this and take it forward.  

>[clip]
>
>ASSUMPTIONS

[clip]

>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?  How about people working in
other languages (somebody mentioned tcl, for example)?  I'd assume not.

Clearly one can say that this base class *is* optional and its absence
won't prevent anyone from using a SAX-implementing parser.  The trouble
with this argument is that the availability of the base class -- and code
in that class which is more than just empty stubs -- is coming into play in
the pro/con discussions about the design issues.  I'll cite a few examples:

>From question 1:
>Furthermore, if a SAX-based application
>extends the XmlAppBase base class, then it can simply ignore these if
>they are not needed.

>From question 2:
>if an application is derived from XmlAppBase, it can simply ignore
>  these events if it doesn't need them;


and:
>We could simplify things further for most users if the XmlAppBase
>class ***implemented final versions of these handlers and maintained its
>own entity stack*** [emphasis mine - davido], providing an additional
getCurrentEntity() query
>method (not part of the interface).

And from question 3:
>could be implemented in XmlAppBase, so that most users could simply
>  ignore it (the default implementation would always return the
>  systemID argument unmodified);

So, my concern is that meaningful use of SAX implementations would come to
depend, in practice, on the presence of this base class.  And that's
trouble for non-Java SAX clients.

So, my vote is that we assume that there is *not* a presence of base class.

Clearly this is a question of goals for SAX.  As someone who hopes to use
SAX-based parsers (and who may implement one), I can say that I may be
discouraged from using/implementing them if it's hard outside of Java.  On
the other hand, it may be that the collective goals of *those who are
actually doing the implementation work today* are satisfied by this design.
 And I'm a great believer in yielding to those who are actually doing the
work. :>)

What say y'all?



================================
David Ornstein
Pragmatica, Inc.
http://www.pragmaticainc.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)