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

> > I wanted to be able to expose filters pipelines for easy construction by
> > users, as well as allow multi-stage transforms (a la Schematron) to be
> > hooked in as desired as well.
> 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 sort of user, though?  The first applications of that pipeline
> framework addressed command line usage, where XML syntax
> for pipeline specs was counter-indicated.

The same users, only I was asssuming more XML knowledge. Basically
people who are happy with XML, but don't want to start hacking Java
to configure filters.

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

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?