Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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
|
