SAX: Parser Interface (question 9 of 10)

David Megginson ak117 at
Sun Jan 4 01:36:55 GMT 1998

[SAX is a proposal for a simple, event-based XML API, using
callbacks.  This is one in a series of ten design questions that we
need to answer to implement the API.]

So far, all of my questions have related to the callback interface
(XmlApplication); should SAX also include a simple interface for the
parser/processor itself, like the following?

  public interface XmlParser extends java.lang.Runnable {

    public void setDocumentSystemID (String systemID);

    public void setXmlApplication (XmlApplication app);

    public void run ();


(We would also mandate a zero-argument constructor, but there is no
way to enforce that with the interface.)  Implementations might also
provide additional convenience constructors to set the systemID and
app directly.


- this interface constrains the parser writers to use the same
  invocation methods;

- it will be necessary to write separate frontends for some parsers to
  implement this functionality;

- extending java.lang.Runnable is Java-specific, and the concept may
  not translate well to other languages.


- it will be simple to substitute parsers dynamically;

- it will be simple to start a parser as a new thread;

- most users will not have to know the details of different parser


Yes (strongly).

In Java, this approach will be especially powerful, because
applications can allow users to choose their own parsers at run time
(even if the application writer has no knowledge of that parser).
Assume, for example, that the variable 'parserOfChoice' contains the
class name of a user's preferred parser:

  Class parserClass = Class.forName(parserOfChoice);
  XmlParser parser = (XmlParser)parserClass.newInstance();

Note that the zero-argument constructor is required for this sort of

It will also be trivial to start the parser as a thread:

  Thread parserThread = new Thread(parser);


It might be useful to have corresponding getDocumentSystemID and
getXmlApplication methods, but since they are not absolutely
essential, it might not make sense to mandate them in the interface.

All the best,


David Megginson                 ak117 at
Microstar Software Ltd.         dmeggins at

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

More information about the Xml-dev mailing list