RFC: Simple XML Event-Based API for Java

[David Megginson]

After careful thought, I am fairly certain that I would be willing to
accept the following simple event-driven API for Ælfred.  It meets
most of Tim Bray's concerns (I'd love to hear from Norbert Mikula and
from Chris Lovett), and it requires me to use only one extra class
file (the new XmlProcessor interface -- see below):


XmlApplication.java:
====================8<====================8<====================
import java.net.URL;
import java.util.Dictionary;

public interface XmlApplication {

  public void 
    startDocument (XmlProcessor processor, String pubid, URL sysid);

  public void 
    endDocument (XmlProcessor processor);

  public void
    startProlog (XmlProcessor processor);

  public void 
    endProlog (XmlProcessor processor);

  public void 
    startElement (XmlProcessor processor, String elname, 
                  Dictionary attributes);

  public void 
    endElement (XmlProcessor processor, String elname);

  public void 
    characters (XmlProcessor processor, char ch[], int start, int length);

  public void 
    processingInstruction (XmlProcessor processor, String target, String data);

  public void 
    error (XmlProcessor processor, String message, URL url, int line);
}

// end of XmlApplication.java
====================8<====================8<====================


The processor itself could implement the following interface (very
Thread-oriented and Bean-like):


XmlProcessor.java:
====================8<====================8<====================
import java.lang.Runnable;
import java.net.URL;

public interface XmlProcessor extends Runnable {

  public void setPublicId (String publicId);
  public String getPublicId ();

  public void setSystemId (URL systemId);
  public URL getSystemId ();

  public void setUserData (Object data);
  public Object getUserData ();

  public void addApplication (XmlApplication application);
  public void removeApplication (XmlApplication application);

  public void run();

}

// end of XmlProcessor.java
====================8<====================8<====================


I would lose Ælfred's resolveEntity() callback, the isSpecified
boolean for attributes and the simple String argument for character
data.  Tim would lose the ability to return a boolean to stop the
parse (the user would have to throw an exception), and would have to
rename more of his callbacks.

On the positive side, this interface would let you hang more than one
application off the same parse, which could be very interesting.  The
userData property also gives users a chance to pass extra information
to the processor easily, if they wish.

This new XmlProcessor interface (actually a parser, but I'm using the
XML spec's terminology here) does not preclude additional
functionality -- I'll keep all of Ælfred's DTD-query methods -- but
neither does it standardise that functionality.


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)