[
Lists Home |
Date Index |
Thread Index
]
- From: "Clark C. Evans" <clark.evans@manhattanproject.com>
- To: David Megginson <david@megginson.com>
- Date: Tue, 18 Jan 2000 13:41:29 -0500 (EST)
On Tue, 18 Jan 2000, David Megginson wrote:
> There are two different ways that an event-based interface can work:
> the event supplier can push events out to the consumer, or the
> consumer can pull events from the supplier.
Yes. I very much like the push interface for branches
(elements), however, a pull interface for the leaf
content would be extremely useful, and perhaps more
efficient. See the Character Tugging post.
I think SAX would be far improved if it continued
to push elements, but allowed for leaf characters
to be pulled.
> SAX is very much a push interface, but some people have asked if it
> might be possible to add optional support for pull, so that you can do
> something like
>
> Event e = xmlReader.nextEvent();
Pull interfaces are great for reading, and push
interfaces are great for writing. You can go
from pull to push without problem; however going
from push to pull requires extra buffering, novel
communication or multi-threading.
Thus, a pull interface is not ideal for a multi
stage process; due to the push->pull conversion
between each stage. Of course, receiving push
is a bit annoying, but a nested object handler
can transparently mitigate this concern.
However, you can allow for "pull" at the leaves of
a "push" with little to no effort. In fact, it
may be more efficient...
> Questions
> ---------
>
> 1. Is this adequate for the people who want pull? I really don't want
> to define a separate object for each event type (especially when we
> allow arbitrary extension handlers).
I'd just like leaf content to be pulled... the extension handler
seemed like a complicated solution for a simple problem.
> 2. Is it OK that a single call to nextEvent() might generate two or
> three events in some cases?
>
> 3. Would any of the parser writers out there want to support this?
What is better is Paul Miller's nested handler idea,
(XMLIO) letting a ContentHandler return a sub-handler to
receive all of the child events for a given element.
ContentHandler beginElement(...)
Combined with a CharTug, this works beautyfully...
I have a SML interface and parser which works
this way. It's pretty.
Clark
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.
|