Re: SAX Filters

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

> > http://xmlconf.sourceforge.net/java/apidoc/xml/pipeline/package-summary.html
> 
> Thanks for the link, I've actually been tinkering with something similar,
> only the syntax for the PipeFactory is itself an XML document:
> 
> <pipe>
>   <filter class="...Java class name..."/>
> </pipe>

No problem ... a "Factory" is a pure convenience in any case,
configuring each pipeline component could in general require
direct interactions between the components.  Some folk like the
model of using bean properties, others don't ... but large filter
networks may need some work to hook into the rest of the
application's processing framework.  I'm not concerned with
that syntax, so long as it works for the various applications.


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

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.


> I'd come across an earlier version of xmlconf, but hadn't realised it was
> still under development on sourceforge.  (Perhaps my time would be
> better spent contributing to that).

Well, the XML conformance bits are rather incidental to the Java code
there, and neither has gotten much new work lately.  (Though Curt has
recently put some DOM tests in...)

It's likely that the Java library work would be happier with some other
home.  One possibility that's come up is to move that work to an FSF
server ... there should be a GPL'd Java/XML framework to use with
GCJ based systems.


> I was aiming on working up to having filters that would read a RDDL document
> when namespace callbacks were generated, and then perhaps configure the
> rest of the pipeline to include additional filters, depending on the task at
> hand.

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.

- Dave