[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAX Filters
- From: David Brownell <email@example.com>
- To: Leigh Dodds <firstname.lastname@example.org>, xml-dev <email@example.com>
- Date: Thu, 19 Apr 2001 09:47:48 -0700
> > The focus of that pipeline framework is multi-stage efforts, though
> > not just transformation. I've not thought how Schematron-esque
> > processing would be done -- you imply they wouldn't just be stages
> > in filter pipelines.
> Its probably closer to your Tee-piece concept, although the other way
> around. The Schematron validator - which would be the actual stage
> in the filter - is generated through a separate transformation (a T-piece,
> feeding *into* the main pipe, rather than splitting off events from it)
What "main pipe"? It's a graph ... there can be many producers,
many consumers ... tee joints send event to two consumers, and
(given any synchronization that may be needed) any consumer can
be fed by multiple consumers! :)
I'll have to think about Schematron a bit more though.
> > I prefer the idea of setting the pipelines up for the task at
> > hand first, then feeding it the data. But I'd agree that there's no
> > reason that
> > the task should not be determined from the envelope wrapping that data; so
> > long as there's a clear delineation between the data and task.
> Would the task necessarily be determined by the envelope?
That's dependent on application architecture. I think it'd be just
as likely that the task is known in advance, perhaps as one of
a handful of options.
> What about delivering an XML document to an XML browser, surely it'd
> want to configure its rendering pipeline based on the particular namespaced
> elements in the document?
So the task is "rendering", known in advance! Is the output
device also known in advance? The 6"x4" two color paged
output is a bit different from 2" square mono PDA screen,
or the IE2 web browser that NT4 ships with.
Answering that question would call for an application to be
architected. It might be preferable to set up a pipeline that's
general enough to handle all supported element types, and
then use pipeline shortcuts to optimize (say, when no SVG is
involved). And it's not clear to me how that application would
divide work between its processing stages, either ...