Specifying options in SAX

david at megginson.com david at megginson.com
Wed Jan 27 17:54:51 GMT 1999

james anderson writes:

 > Why not permit the application to bind an instance to perform the
 > respective operations. It's more powerful and no harder to
 > implement or to use?

I love it, but I don't think we should do it.

James's proposal, as I understand it, is an excellent design pattern:

  // This is how Java can do a strongly-typed enumeration...
  public final class Response {
    public final static int DONTCARE = new Response();
    public final static int YES = new Response();
    public final static int NO = new Response();
    private OptionResponse () {}

  public interface OptionManager {
    public abstract Response wantValidation ();
    public abstract Response wantNamespaces ();
    public abstract Response wantEntityExpansion ();

  public interface XParser extends Parser {
    // ...
    public void setOptionManager (OptionManager manager);

Unfortunately, SAX doesn't generally swing this way: note that there
is not a separate interface/class for each SAX event type either,
despite the fact that their absence makes the interface much more

Ironically, elegant and extensible design tends to steepen the
learning curve by multiplying interfaces and classes (how many people
ever learned SP's native interface?), and SAX's target audience has
not all read Gamma/Helm/Johnson/Vlissides.

Think of SAX as a low-level device driver -- it's ugly, but you can
build beautiful things on top of it (as many people on this list

All the best,


David Megginson                 david at megginson.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)

More information about the Xml-dev mailing list