OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: SAX2: pull interface

[ 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.


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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS