RFC: Simple XML Event-Based API for Java

[David Megginson]

James Clark writes:

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

The advantage is that the same XmlApplication object can work with
more than one XmlProcessor at the same time (though it is not required
to be able to do so).

 > >   public void
 > >     startDocument (XmlProcessor processor, String pubid, URL sysid);
 > 
 > What do the pubid and sysid arguments represent?  The document entity?

Yes.  I suppose that they are redundant, given
XmlProcessor.getPublicId() and XmlProcessor.getSystemId(), so they
could go if the XmlProcessor argument stayed.

 > >   public void
 > >     startProlog (XmlProcessor processor);
 > > 
 > >   public void
 > >     endProlog (XmlProcessor processor);
 > 
 > Why do you need startProlog() and endProlog()?

Convenience only: users could infer the end of the prolog from the
start of the document element.  The end of the prolog (or at least, of
the document type declaration) is important for Ælfred, because that
is the first point when Ælfred's DTD query routines will return useful
results.

 > 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.

I think that it probably is too fancy.

 > >   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.

A wise suggestion.

 > > 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.

Perhaps -- it would be most useful, again, when an XmlApplication was
being used with more than one XmlProcessor.


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)