> If by "xml filter" you mean SAX's XMLFilter interface... > > The simplest approach to writing SAX filters is to just have a single > object implement ContentHandler and pass the filtered data to another > ContentHandler. Our SAXResult is set up to wrap itself around an > sax.ContentHandler, so it can happily talk to a filter of this type. > > Unfortunately, sax.XMLFilter is intended to wrap itself around a > sax.XMLReader and to actually be able to control the operation via its > parse() method... so the metaphors collide. > > Simplest workaround I can see right now would be to implement a > sax.XMLReader that wraps around a Transformer, and pass that to the > XMLFilter. That feels like it ought to be straightforward, and *might* > actually be something we'd want to ship as a standard Xalan utility > class...
That sounds well out of my ability range... But if anybody would like to have a go / knows another solution, the basic idea is this: We have four XMLFilters, all simply extract information from the xml and are separate for maintainability. Two of the XMLFilters work on the source xml, two work of the result of the transform. Currently, its easy enough to implement: XMLFilter -> XMLFilter -> Transform as a chain. But I would like to implement: XMLFilter -> XMLFilter -> Transform -> XMLFilter -> XMLFilter Is this currently possible? The way I've done it so far is to write out the result of the transform, then read it back in for the final two XMLFilter's... not really the chain philosophy. cheers andrew --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003
