[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [ANN] Small, simple Java-based XML output library

java xml reader

Enzo Maggi wrote:

> 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

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:

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.


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.