> I don't see the point of the XmlProcessor first argument. What's wr=
ong
> with having the implementation of XmlApplication store the XmlProces=
sor
> 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=
);
>=20
> What do the pubid and sysid arguments represent? The document entit=
y?
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);
> >=20
> > public void
> > endProlog (XmlProcessor processor);
>=20
> 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 =C6lfred, because that
is the first point when =C6lfred's DTD query routines will return usefu=
l
results.
> The one major omission I see here is absense of information about th=
e
> location (URL, byte offset, line number etc) of the events. It woul=
d 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:
>=20
> processor.run(new MyXmlApplication());
>=20
> and to run with validation you would use
>=20
> processor.run (new ValidateXmlApplication(new MyXmlApplication));
>=20
> 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.
>=20
> This could be done by having the app ask the processor for the locat=
ion
> 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=20
> "simple" API.
I think that it probably is too fancy.
> > public void
> > error (XmlProcessor processor, String message, URL url, int li=
ne);
>=20
> 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 inclin=
ed
> to handle fatal errors as an exception, and not try to deal with
> non-fatal errors at all in this simple interface.
>=20
> > On the positive side, this interface would let you hang more than =
one
> > application off the same parse, which could be very interesting.
>=20
> I don't think this is a good idea. It adds complexity and it's like=
ly
> to impose a performance cost, but it doesn't buy you anything, becau=
se
> you can achieve that functionality with a MultipleXmlApplication cla=
ss
> 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 informat=
ion
> > to the processor easily, if they wish.
>=20
> 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
--=20
David Megginson ak117@freenet.carleton.ca
Microstar Software Ltd. dmeggins@microstar.com
http://home.sprynet.com/sprynet/dmeggins/