Re: [ANN] Small, simple Java-based XML output library
Enzo Maggi wrote: <snip/> > For example, a program that do something usefull with XML, like counting > the tags :->. > My application writes XML programmatically with SWAN-output and I would > like just to change / attach / derive a piece of code that computes the > result. > Now, In order to do this, I must have a complete new implementation of > the class hierarchy. (Correct me if I am wrong)... > The computation could be of course something interesting, like an > XSLT-like transformation limited to the child:: and attribute:: axis. > > - If SWAN-output was an interface, let's say, a protocol, we could have > bridges between SAX an SWAN. That is, a class that takes a SAX flow and > produces the set of "SWAN" callbacks accordingly. I don't think I'm following you on this. What's wrong with the SAX interfaces for this purpose? It seems to me that an interface for swan callbacks would just be a reinvention of the SAX interfaces. As it is, you can always implement a SAX ContentHandler that filters SAX events, augmenting or otherwise changing the events before passing them on to another ContentHandler in the chain. Is there some reason why this doesn't meet your need? The SAX interface is more unwieldy than the Swan API, but I think any generic interface for the purpose of filtering XML output is going to end looking pretty much like SAX. Note that all output does actually get channeled through the top level FragmentResult or DocumentResult (since it has the references to the SAX Handlers), so you could theoretically create subclasses of these 2 classes and override the "output(Result)" method, I believe, to see what is being output. The only problem with this is some of the classes are not public, so they would be completely opaque. This is easy to change, but I'm just not sure why the SAX interfaces are not sufficient for this purpose. One other possibility, if you are interested, is something else I'm working on that sits as a layer on top of SAX and is designed for handling input rather than output. Perhaps it would be a bit friendlier than implementing a SAX ContentHandler, but it involves a bit more overhead as you need a SAX adapter that maintains some contextual state and translates events to the alternative interface. On the plus side, though, you have access to more contextual state than SAX provides, and you can dispense with those "startPrefixMapping" and "endPrefixMapping" calls (they are handled automatically). I haven't released this yet, but it will be released shortly and the code is there in my CVS repository if you want to check it out. The Javadoc for the relevant package is at: http://swan.sourceforge.net/javadoc/core/net/sf/swan/xml/reader/package-summary.html To use it you would instantiate a ContextHandler and use it as the SAX ContentHandler. Provide an implementation of the InfosetProcessor interface, and set is as the InfosetProcessor for the ContextHandler.
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