cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: cocoon blocks and some questions, xml modularization
Date Fri, 31 Jan 2003 08:50:32 GMT

Jakob Praher wrote:
> hi,
> I was reading through the
> wiki page, which is a very interesting read.
> There are some questions which have come to my mind:
> I) 
> One of the things that interests me, is how you want to manage
> specifications of xslts?
> You have to ensure that the blocks stylesheets adhere to the
> specification, this means:
> - the resulting data should have the right data format [xml,txt,pdf,...]
> - the paths for refereing to the stylesheets must be standardized
>    otherwise it is useless to do:
>     <map:transform
>         src="block:skin:/stylesheets/document2html.xslt"/>
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                          must be standardized.
> perhaps some lint like checker is needed for doing the above.

AFAIK there will be no system to standardize on this, as there isn't in 
Cocoon now. In Cocoon you are perfectly able to assemble pipelines that 
do not give meaningful results, like trying to transform with a docbook 
stylesheet to html a Forrest document11DTD stlesheet.

It's up to the "public API" of he block to specify these things.

Probably we will come up to a system that validates (optionally) inputs 
and outputs and sees that they match, but AFAIK it will be a RFE.

Some form of inheritance is planned though, so blocks should be able to 
extend other blocks, thus possibly implementing th esame contract (ie a 
skin implementation block will work as a skin block).

> II) 
> Do you see xslt reuse only at a black box model (this is the natural way
> for cocoon, since it deals with tranformations) .
> Should there be a support for importing stylesheets from other blocks,
> which means that there should be an xslt specification to define some
> templates which must be supported .
> (this is propably an overkill)

Use of blocks from other blocks is planned, but without mandating 
anything that must be supported by default.

> III) 
> What are the problems with the current container in detail?
> I have used avalon in my own applications and like it very much, and I
> would like to see a more detailed description, of what the problems of
> the current ECM Containers are.
> [ I think one of the problems is the static behaviour of configuration,
> and classloading difficulties that come along, but maybe you can tell me
> more about that here ]

Well, Cocoon has worked quite some time with ECM, the point is that ECM 
is not made to play with a block-like concept, as you say. This is the 
main architectural reason why it will change in the future.

> It would be great if we could brainstorm on this using the
> site.
> IV) 
> What time frame do you have for implementing cocoon blocks? 

ASAP ;-)

We are going in "baby steps", you are welcome to help in either or both 
code and discussion :-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message