forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira" ...@upaya.co.uk>
Subject Re: xsl:output
Date Wed, 30 Jul 2003 10:57:36 GMT
On Wed, 30 Jul 2003 12:46:27 +0200, "Juan Jose Pablos"
<cheche@che-che.com> said:
> Upayavira,
> 
> Upayavira wrote:
> > 
> > Don't understand. Do you mean 'why doesn't the serializer read into the
> > xslt stylesheet of the previous transformer to find out if there was an
> > xsl:output node in it'? If so, that really wouldn't make sense.
> > 
> 
> Well, the fact is that the transformer know about xsl:output and instead 
> of ignore it, do something so the serializer knows what to do (copy the 
> elements whatever..)
> 
> > The fact is that xslt wasn't designed entirely with Separation of
> > Concerns in mind. It does in places mix concerns that Cocoon tries to
> > separate. So there are features in XSLT that aren't relevant to Cocoon
> > and shouldn't be used (for example the document() function). In XSLT 2.0,
> > there's more of them too.
> >
> 
> Could you elaborate more on what features from the standard should not 
> be used by cocoon and the alternatives that you know?
> 
> ie.
> 

Standard                        Cocoon

xsl:output                      map:serialize
document()                      aggregation

Then in XSLT 2.0, you can have a stylesheet that produces multiple
documents. I can't see how that would fit with Cocoon's request/response
model. You could achieve such a thing anyway with something like the CLI
to produce your multiple documents.

> >>I mean, I happy as long I can make it happend, but I know that people 
> >>expect xsl:output to work
> > 
> > 
> > Well, we just have to explain to them that Cocoon/Forrest work
> > differently, and explain the benefits of the separation (e.g. you can
> > serialize the results of the same XSL to either XML or HTML, to XHTML,
> > etc, etc, etc, without changing the stylesheet, and thus without
> > requiring multiple versions of the same stylesheet).
> > 
> 
> 
> Possibly there is a lot of beneficts on the "Separation of Concerns" I 
> do not want to argue you that, I am not the one that wrote the standard 
> either but what I see is the result: "Cocoon does not support a standard 
> tag".

Cocoon does not aim to support the whole of XSLT, I would say. So long as
we are clear about what we do support, what we don't, and the reasons
why, I think this is okay. Anyway, the XSLT specification can easily
develop to include functions that _cannot_ be implemented in Cocoon, not
just _shouldn't_.

It seems to me that you are viewing these unsupported tags as failings on
the part of Cocoon. To my mind they are benefits, as Cocoon only supports
those aspects that support and encourage its rigorous application of SoC.

Make sense?

Regards, Upayavira

Mime
View raw message