Simple XML Event-Based API for Java

Don Park donpark at
Wed Dec 17 09:06:48 GMT 1997

>I would interpret those as classes that create and consume XML (text
>strings). Perhaps they should be called EventProducer and EventConsumer
>or XMLEventProducer and XMLEventConsumer. The former would depend on the
>package mechanism to avoid clashes with other kinds of Event systems.

XMLEventBlahBlah implies something that has to do with XMLEvent objects
which does not exist.  The fact that the API being worked is said to be
event-based does not imply that central product of the API are events.  It
could have just as well been described as callback-based XML parser.
Furthermore, I do not see how XmlConsumer and XmlProducer imply that they
work with XML text string.  Those names imply only that they are interfaces
for classes that consume and produce XML data.

As far as reducing dependency on package mechanism, there is a point of
balance where class names are unique enough without requiring package
specification for most of the situations.  I do not see how XmlEventBlah is
significantly better than XmlBlah.  If there is any confusion, it is cleared
up by import statements or prefixing package names.  org.w3c.xml.XmlConsumer
is not very long and is needed only in the instantiation call.

BTW, some attention should be paid to JavaBeans method signatures if you are
planning on having simple XML event-based parser packaged as beans.

My comments are just comments, pure and simple.  Any effort on the XML
parser is a movement in the right direction no matter whether I have a bone
to pick with its design.  I sure do appreciate the effort you guys are
putting in.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list