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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SAX Filters

> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: 19 April 2001 17:48
> To: Leigh Dodds; xml-dev
> Subject: Re: SAX Filters


> 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!  :)

Hmm, I'd not thought of it quite in that way. I'd just assumed there
would be a main source of events, and a primary sink, allowing
for T-pieces along the way. Neat.

> I'll have to think about Schematron a bit more though.

Its a T-joint. Upon receiving events from its main input, it 'evaluates'
a seconday branch. This branch produces a Schematron validator
which is the action is performed by the T-piece.

IOW, the T-joint is a transform. The precise definition of the transform
is defined by evaluating the secondary pipe. The T-piece then sends
the output of the transform to its consumers.

> > 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!


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 thought that perhaps these renders could be downloaded,
installed, configured, etc during the pipeline stage so that they're
available in the second stage.

So while the task may be "rendering" the implementation may
be different depending on what was fed through the pipe.

Anyway, just some musings.

I'd be interested if anyone has any pointers to design
patterns/architectures for XML applications (rather than
XML documents).



Leigh Dodds, Systems Architect       | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic |    sine necessitate"
http://www.xml.com/pub/xmldeviant    |     -- William of Ockham