Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > I like the "XML Pipeline" framework I developed, for example, in no
> > small part because it doesn't ignore lexical and declaration handlers.
> > Which means that it supports more complete "pass through", unlike
> > anything based directly on XMLFilterImpl. (So my XMLWriter is
> > able to record the DTD information when it matters...)
>
> That sounds more useful to me. Is the only required change [extends
> XMLPipelineImpl] instead of [extends XMLFilterImpl]?
Sort of -- "EventFilter" is the convenience class. (And "TeeConsumer"
for a fan-out version.) Here's a URL for recent javadoc:
http://xmlconf.sourceforge.net/java/apidoc/gnu/xml/pipeline/EventFilter.html
That javadoc contrasts the pipeline approach with "XMLFilterImpl".
A "pipeline" stage is basically an EventConsumer implementation,
such as EventFilter; they chain. Some key points include:
- doesn't mix producer and consumer roles
- talks all the SAX2 handlers (decl, lexical ...)
- supports "fan in" and "fan out", but not "parent" chaining
I've had requests to release that under a non-GPL license, so the
current stuff is under the "GPL with library exception" license.
That's what the GNU C library uses; it's friendly to proprietary
applications. (Don't tell Microsoft ... :)
- Dave
|
