I think that the concept of events are implicit in the interfaces that
are being defined and may well be explicit in the documentation for it.
The only reason that we don't call them startElementEvent,
endElementEvent, endPrologEvent etc. is because it would be redundant.
ON THE OTHER HAND -- should we actually using Event Objects as SP does?
The nice thing about event objects is that they can be subclassed to add
more information. An example would be James' request for line number
information. That means that an XAPI "level 2" producer could easily
produce data for a "level 1" consumer without a problem.
They can also be "lazy" in the sense that they don't have to construct
(e.g.) a dictionary object for attributes unless the start-element ASKS
for attributes. Is Java object construction too slow for us to use real
objects?
> 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.
I'm not religious on this issue, but the only definition of "XML Data" I
know of is PR-xml-971208.
"This specification describes the required behavior of an XML processor
in terms of how it must read XML data and the information it must
provide to the application."
In other words, XML Data is angle-bracketed text that conforms to
PR-xml-971208.
Paul Prescod