J.Pietschmann wrote:
> 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
Well, there is
org/wyona/xml/XPSAssembler.java
org/wyona/cms/cocoon/transformation/IncludeTransformer.java
I have programmed it about two years ago and integrated it into
Wyona/Cocoon two months ago. But it still needs some refactoring such
that I will be able to submit it as a patch to Cocoon.
Michael
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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
