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.
Sincerely,
Don