David M Williams wrote:
You say you favor an "event" approach, but I thought the lack of events
was the very definition of a "pull parser" and event driven approaches
were the "push parsers"?
The word "event" is overloaded a lot when talking
about XML programming. Personally, I have used the
term in the past in reference to push based APIs
like SAX and XNI. But when I talk about events, I
am really talking about the fact that the document
information is reported as a series of discrete
items. So whether it's pushed at you or you pull
it, they're both events in my mind.
To clarify, I meant to say that I prefer the event
*object* approach. This means that the information
items are encapsulated within discrete objects
instead of requiring the application to call a set
of methods based on the item type.
I haven't worked with or even studied the API ... but the spec itself
seems to have a higher than usual number of sections that say they are
"optional". That always makes be think some people in the inner circle
want it, no one can work out the details in time for agreement, so its
left optional, and those that implement/gain acceptance first then
support that part of the standard defacto, without proper public review.
Another problem with all these optional components
is that some parsers will implement them and some
won't. In the end, users will have to rely on a
specific parser implementation and lose the ability
to swap parsers at will.
My own interest in this API are those that allow another parser to be
written on the "output" of the "pull" operation. So, things like 'skip'
and 'backup' are important. I did see that 'skip' would be supported,
but never heard about 'backup' (there was a section that "random access"
was part of this spec, which I think is ok).
The only way to truly make a "skip" operation fast,
instead of being just a convenience, is to implement
it at the parser level and not from the output. By
the time it hits an external filter all the work has
been done already so there's very little to gain but
convenience.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
