[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX Filters
> > 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|