<snips cause="commenting on some specifics only"/>
...IMHO, the template language which is closer to the optimum is XSLT but only with one change:
FORGET THE XML SYNTAX!
+1
This is happening to some extent with the wiki syntax vs XML documents: if there is a good enough structured text syntax (like wiki), people will tend to use it rather than the XML equivalent (like xdocs).
That is, unless real good XML editors are widely available, but this is not the case today, IMHO programmers prefer writing structured ASCII than XML because of the tools available.
...3) no ability to call extensions...
Extensions are usually needed in the view, not to implement logic but to work around the view language limitations. A good example is date formatting/parsing/conversion in XSLT, where going to java makes it so much easier that fighting with XSLT's limited parsing and formatting abilities.
...then we can have the following templatesheet:
namespace ("ns") { "http://whatever"; }
template ("/") { <html> <head> <title>{list/@name}</title> ...
Looks obiously much better (for humans) than the current XSLT syntax.
Hovewer, if a new language is created which is Cocoon-specific, I think the syntax should be as close as possible to XSLT (with flow- and cocoon-specific extensions if needed), only written in structured text instead of XML.
Otherwise, the risk is that people would not bother to learn a different language after having possibly invested a lot of energy in learning XSLT, if they perceive this new template stuff as being a different language instead of just a different way of writing the same thing.
Also, if the new language can be easily mapped to XSLT by parsing/transforming, it could be useful outside of Cocoon, for example as an editing language in XSLT-aware IDEs.
And finally, sticking to XSLT-like syntax would allow people to refer to existing XSLT docs and tutorials, which is a huge advantage in jumpstarting a new template language.
-Bertrand
