Stefano Mazzocchi wrote: > In that case I agree: like I said, if you need to do your stuff without > Cocoon around, or without a precise way (xpipe?) to define how a > document is processed, document() is the way to go. That's the only > argument I acknowledge.
The problem appears to be that there aren't many (any?) stand-alone xinclude processors and XML pipeline processors out there, not the mention the lack of standardized interfaces, descriptions (for pipelines) and behaviour. Cocoon is breaking ground here, but for many purposes having to use full Cocoon is just too heavyweight (and too monolithic). What about applying to standards organisations for pipeline descriptions and Java interfaces to xinclude, pipeline, FO and SVG processors? Cocoon could provide a host experience and would make a great testbed. J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
