xml-dev - Specifying options in SAX

[<david@megginson.com>]

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
brittle.  

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
have).


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

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)