cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: coping with XSLT
Date Tue, 02 Dec 2003 10:20:05 GMT
Le Mardi, 2 déc 2003, à 10:28 Europe/Zurich, Adrian Petru Dimulescu a 
écrit :

> this may not be exactly the best place to talk about general XSLT 
> issues
> but I'll do it anyway, you'll see in a second why....

It could be seen as off-topic but I think you make an interesting 
point: for many people working on publishing stuff, XSLT is an often 
unnecessary barrier to productivity.

> ...How do you make Cocoon largely used say, in a software team, when 
> the
> main transfomation language is XSLT ? That ugly, difficult to write,
> close to impossible to read, XML-based functional language? I honestly
> find myself almost inconsciently trying to avoid XSLT. When I have an
> XSLT task, I find something else to do, it's almost freudian....

I've been doing a lot of XSLT in the last few years, and although it is 
a real pain to *write* I like its power a lot. Or rather, the power of 
XPath, which IMO is the key to being efficient with XSLT.

I think there are two problems with XSLT:
a) the XML-based syntax is a pain

b) the tree-based processing model is foreign to a lot of people, who 
then try to write procedural code in XSLT, with lots of xsl:for-each 
and xsl:choice constructs. They might get there eventually but it's 
painful and slow, and often way too complicated.

For me there's not much to do about b), someone willing to take 
advantage of XSLT has to learn the processing model and how to use it 
properly. But simpler scriptable transforms could be interesting as a 
starting point.

About a), something could be done for sure: there are some attempts at 
simplified syntaxes for XSLT, which could make it a *lot* easier and 
more fun to work with.

This has been discussed here previously, cannot find the references ATM 
but anyway nothing concrete has happened yet.

I've been (wild-)thinking about combining Tim Larson's 
EffectTransformer ( 
with interpreted code to make it easier to write scriptable transforms 
but it's just a wild dream at this point.

I have collected a few links to interesting stuff about this, see


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

View raw message