SAX: How many interfaces?

[David Megginson]

For SAX, how much does the number of interfaces and classes matter?
My original plan was to have something like this in the *.sax package
(I'm still experimenting with different names):

  public interface *.sax.Parser
  public interface *.sax.Application
  public class *.sax.AppBase
  
Given the unsuitability of java.util.Dictionary for attributes,
however, it is clear that we will need at least four instead of three:

  public interface *.sax.Parser
  public interface *.sax.Application
  public interface *.sax.ValueMap
  public class *.sax.AppBase

I have been reluctant to create too many classes and interfaces
because for most SAX users, XML will just be a minor enabling
technology used for transactions, configuration, or other structured
data data.  The distinctions that we XML specialists want to make --
entity vs. element structure, etc. -- loom large for us, but may seem
unnecessarily picky to non-specialists, for whom XML is not really the
main point.

Nevertheless, it is essential that we not prematurely rule out any
approaches, so last night I wrote a different trial implementation,
using a couple more interfaces and classes:

  public interface *.sax.Parser
  public interface *.sax.EntityHandler
  public interface *.sax.DocumentHandler
  public interface *.sax.ErrorHandler
  public interface *.sax.AttributeMap
  public class *.sax.HandlerBase

This is certainly much more elegant.  With this approach, the parser
interface appears as follows:

public interface Parser {

  public void setEntityHandler (EntityHandler handler);
  public void setDocumentHandler (DocumentHandler handler);
  public void setErrorHandler (ErrorHandler handler);

  void parse (String publicID, String systemID) 
      throws java.lang.Exception;

}


We've lost the ability to extend java.lang.Runnable, but we've gained
the ability to throw exceptions if we wish (Java only), together with
the ability to set separate event handlers for each area.

As a professional SGML/XML implementor and system architect, I am very
comfortable with this sort of approach, but I don't know how it will
play with typical Java hackers:

- Will this arrangement be too hard to understand?

- Will it look like we're being XML purists and splitting too many
  theoretical hairs, for something that should be dead simple (what
  they consider to be just a single data format)?

- Will applet writers be willing to include this many extra *.class
  files just for XML support?

There remain strong pragmatic arguments for the
everything-in-a-single-interface approach.


All the best,


David

-- 
David Megginson                 ak117 at freenet.carleton.ca
Microstar Software Ltd.         dmeggins at microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

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)