[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX: Next Round

• From: Paul Rabin <rabin@s...>
• To: "XML Developers' List" <xml-dev@i...>
• Date: Tue, 26 Jan 1999 14:05:52 -0500

At 04:41 PM 1/22/99 -0500, david@m... wrote:
>Paul Rabin writes:
> > What SAX extensions would be needed to support multiple event
> > stream inputs and outputs?  Filters that route events to one or
> > more event stream outputs have been implemented.  What is the best
> > way to register the handlers for multiple event stream outputs?
>
>The Java-beans-ish way would be to have
>
>  public void addDocumentHandler(DocumentHandler handler);
>  public removeDocumentHandler(DocumentHandler handler);

If the filter is simply copying events to multiple handlers, then this is
ok.  But if different sets of events are going to different handlers, then
there might be an advantage in distinguishing the handlers in some way,
other than by the order in which they are added.  This could be done either
by using separate setFooHandler() methods, or by an additional argument to
a single setDocumentHandler() method.

> > Support for multiple event stream inputs raises control flow issues.  One
> > solution is to have a new version of parse() that returns immediately
after
> > initializing the parse context, but without generating any events, and a
> > new getNextEvent() method that causes a single call to the appropriate
> > upstream handler to be made before returning.
>
>I don't want to deal with synchronization issues at the SAX layer --
>the idea is that SAX provides the raw information for higher layers to 
>work with.  As long as SAX gives you the basic information about an
>XML document, you can build a rich superstructure for more complex
>processing.

Suppose you have an application that is merging XML documents, where the
semantics of the merge allows serial processing of the inputs.  This can't
easily be done unless the application can poll for events on each parser.
The required synchronization could be implemented in a filter, so that the
application doesn't have to worry about multitasking issues.  The filter
would look like a SAX parser, but with the extensions noted above (or
equivalent).

	Paul



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • the "upwards funarg" problem.
    • From: james anderson <James.Anderson@m...>

• References:
  • Re: SAX: Next Round
    • From: Paul Rabin <rabin@s...>
  • Re: SAX: Next Round
    • From: Lars Marius Garshol <larsga@i...>
  • SAX: Next Round
    • From: <david@m...>
  • Re: SAX: Next Round
    • From: <david@m...>
  • Re: SAX: Next Round
    • From: <david@m...>

• Prev by Date: ADMIN: CD-ROM Archive of Discussion list
• Next by Date: Re: Why SAX needs namespace support
• Previous by thread: Re: SAX: Next Round
• Next by thread: the "upwards funarg" problem.
• Index(es):
  • Date
  • Thread