SAX: towards a solution

[David Megginson]

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.  I will be posting a series of separate messages, each
containing a single SAX design question, and will look for a consensus
on each one.  Here are the design topics that I will be posting on
over the weekend:

1) Document start and end.
2) External entity start and end.
3) External entity resolution.
4) Error reporting.
5) Whitespace handling.
6) Processing instructions.
7) Comments.
8) Doctype declaration.
9) Parser interface.
10) Naming and packaging.


ASSUMPTIONS
-----------

Before we start, I am assuming that we will all accept the following
three events without further discussion, since no one objected last
time:

  startElement (String name, java.util.Dictionary attributes)
  endElement (String name)
  charData (char ch[], int length)

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.
For example, if you're only interested in character data, you can try
something like this:

  public class MyApplication extends XmlAppBase {

    public void charData (char ch[], int length)
    {
      System.out.println(new String(ch, 0, length));
    }

  }

There is not need for the programmer to worry about startElement(),
endElement(), since they are already implemented as empty stubs in
XmlAppBase:

  import java.util.Dictionary;

  public class XmlAppBase implements XmlApplication {
  {
    public void startElement (String name, Dictionary attributes) {}
    public void endElement (String name) {}
    public void charData (char ch[], int length) {}
    [...]
  }

_Please_ keep this model in mind when you are commenting on the
relative simplicity or complexity of SAX for users (as opposed to
parser programmers) -- extra functionality is cheap, since it can be
hidden away like this.


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)