Re: SAX Filters

[David Brownell <david-b@pacbell.net>]

> Well I suppose it depends on how the "rendering" is actually being
> carried out. I was envisaging a two phase process: a pipeline
> that constructs the internal DOM of the browser. This DOM would
> then be 'visited', in a second stage, by renders for particular namespaces.

I'd envision processes that don't require a DOM, and which
play to SAX strengths:  single pass, wherever possible.


> I thought that perhaps these renders could be downloaded,
> installed, configured, etc during the pipeline stage so that they're
> available in the second stage.

One way to do that would be to have a "switch" filter.  Tee joints
are not the only data flow branching model, only one simple idiom.

A "switch" node in a pipeline could do stuff like:

    - Ignore all events till particular types of elements start;

    - Use those element types to choose a "next consumer"
      output pipeline, receiving element and children;

    - Be configurable, so those element types (and their
      output pipelines) need not be hardwired.

I could see how that sort of node could benefit from an XML
syntax to describe a filter network.  ID/IDREF would suffice
to handle the linkups.  Given some experience with how such
filter networks are used (set them up manually at first :) such
a syntax shouldn't be tough.

Example applications:  pulling footnote content out of inline
context and putting it at end-of-chapter.  Mining links,
names, images, tables.  Doing all the above, single pass.
(Surely there are more interesting examples, too.)

The role I'd see for DOM is as a temporary holder in
some of the filter nodes.  Say, as one way to create
"footnote" nodes.  In some cases, such temporaries
might be processed and then immediately deleted.
Save a lot of space, particularly on large docs ...

- Dave