RFC: Simple XML Event-Based API for Java

[James Clark]

David Megginson wrote:

> After careful thought, I am fairly certain that I would be willing to
> accept the following simple event-driven API for Ælfred.

I don't see the point of the XmlProcessor first argument.  What's wrong
with having the implementation of XmlApplication store the XmlProcessor
in the member variable?  (This is what SP typically does.)

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

What do the pubid and sysid arguments represent?  The document entity?

>   public void
>     startProlog (XmlProcessor processor);
> 
>   public void
>     endProlog (XmlProcessor processor);

Why do you need startProlog() and endProlog()?

>   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);

The one major omission I see here is absense of information about the
location (URL, byte offset, line number etc) of the events.  It would be
very nice to be able to implement validation as just as an
XmlApplication (that wraps around another XmlApp).  In others to to run
without validation you would use:

  processor.run(new MyXmlApplication());

and to run with validation you would use

  processor.run (new ValidateXmlApplication(new MyXmlApplication));

In order to make this work the application needs to be able to get
information about the location of start/end tags and of data.  This is
also useful for all kinds of application-specific validation.

This could be done by having the app ask the processor for the location
of the last event in some non-standardized way, but that's kind of
kludgy.  On the other hand, maybe this is just too fancy for a 
"simple" API.

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

I don't think having simply "String message" is going to
internationalize well. It's also desirable to know exactly what
character number/column number the error occurred at. Also XML
distinguishes fatal errors (which the parser must not continue
processing after) from other errors.  On the whole I would be inclined
to handle fatal errors as an exception, and not try to deal with
non-fatal errors at all in this simple interface.

> On the positive side, this interface would let you hang more than one
> application off the same parse, which could be very interesting.

I don't think this is a good idea.  It adds complexity and it's likely
to impose a performance cost, but it doesn't buy you anything, because
you can achieve that functionality with a MultipleXmlApplication class
that implements the XmlApplication interface, and provides
addApplication and removeApplication methods, and then forwards each
event to the applications that have been added to it.

> The
> userData property also gives users a chance to pass extra information
> to the processor easily, if they wish.

Surely there are cleaner ways to do this sort of thing.

James


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)