cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: Forms proposal
Date Fri, 14 Jul 2000 20:07:59 GMT
> > It can be possible to "compile" XSLT in a way that they become
> > Generators rather than Transformers. And inlining XSLT extentions like
> > we do today with XSP taglibs.
> >
> > IMHO, XSLT should not work as a Generator (either compiled or
> > interpreted).
> Hmm... why?
> (Compilation or interpretation make no difference to the model you are
> talking about, or hardly any other XSLT model, for that matter.  So let's
> set that completely aside.)
> > But almost everyone in the XSLT WG doesn't seem to agree with me on this
> > :-(
> I'm not sure I, or the rest of the XSL WG, have heard your arguments
> articulated.  Certainly today the XSLT model is a transformation.  To me,
> there is a very thin line between transformation and generation... I think
> of generation as a type of transformation.

I don't know what Stefano's arguments are, so this is my personal view.
Imho there is not an unique possible answer. Maybe it's a matter of taste.
If you see XSLT as "functions" you are right, generators are "functions"
that have no input parameters.
But "functions" are not necessarily right for every job.
Seeing how XML is usually generated you can see that XSP is much 
easier to use; the template mechanism is just too complicated to write
but even more to read, because it doesn't resemble the output XML
visually speaking.
To make an example, schemas are much more popular than DTDs not
only because they haver other possibiliies, but because they are more
I see the Cocoon pipeline as a sound processing chain:
wave input or generators, filters, and amp.
You can produce sounds with filters, but it's just not their job.
Maybe I'm being naive...


View raw message