RFC: Simple XML Event-Based API for Java

[Don Park]

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


XmlApplication can not store the XmlProcessor in the member variable because
it is an interface.  I am very happy to see that XmlProcessor and
XmlApplication are interfaces rather than classes.  Of course, it would help
to have some sort of Factory or Manager.

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


This is exactly why I proposed XmlFilter.  XmlValidator derived from
XmlFilter can be used to add validation at runtime.  Each class and
interfaces should have a clearly intended role.  Stringing XmlApplications
along like some kind of Unix app is not something I would like to see people
do.  I would rather see folks developing XmlFilters to be intentionally used
as converters or by-product producers.

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


Support of multiple event listeners is the norm in the Java world.  As they
say "When in Texas, wear cowboy boots".  I have no concern about performance
cost since Java loops are not very expensive compared to method invocations
and object instantiations.  If we were really concerned about performance, I
would recommend giving up the use of String.  Pool of marker/cursor into a
string buffer will improve performance by a factor.

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


I do not think so.  Just as every Mac developer loved having RefCon to hang
thing onto, I like userData.  Could I have get/setStudData methods?;-)

Don



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)