cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Date Thu, 11 Apr 2002 10:14:24 GMT
At 4:21 pm +0200 10/4/02, Ulrich Mayring wrote:
>>Stefano Mazzocchi wrote:
>> In short: stylesheets's declarativeness was designed to make their
>> contracts less solid ("if this template matches, run it, otherwise do
>> nothing and don't even signal it"). It's very easy to have 'dead parts'
>> of your declarative code.
>> This is a *feature* when it comes to 'what-if' scenarios but Jeremy has
>> been using them in a procedural case and this, IMO, sacrifices contract
>> solidity, expecially in a multi-authored environment like this one.
>Yes, I understand what you mean here. It's unproductive and error-prone
>to model procedural scenarios with declarative algorithms. Either change
>the scenario to become declarative or change the modelling language to
>become procedural - any mixture of the two will not work.

I obviously find this pronouncement a bit disturbing .....

The general idea for making (content-editing) pipelines that have a 'drain'
to output modified content via a WriteableSource has been in development
(on and off) for several months now. It has come out of discussions on
cocoon-dev and privately, with numerous collaborators.

Is the problem with the whole concept, or merely my implementation of it?

For example:

During the 'put' phase in <slash-edit/>, the instance, having been
assembled from the Request by an XSLT, it is then processed with the
generated Validator XSLT.

Next an 'adaptor' XSLT checks there were no Validation errors before
wrapping the instance in a <source:write/> tag so that the
SourceWritingTransformer (later in the pipeline) can output it to the

Is it these tiny, one-job adaptor XSLTs and the logic they perform causing
you these problems, or is it the whole concept of incrementally adapting
content in the pipeline?

Thanks for any assistance.

regards Jeremy

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <>     		 <>
   <phone:+44.[0].20.7737.6831>             <>

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

View raw message