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.
I disagree.
When you have to do stuff like
<xsl:if test="count(//whatever) > 3">
it's the time to realize there is something *dead* wrong with this syntax.
And since the reason why xslt is XML is to allow auto-processing, but tell me: how many times did you have to write a stylesheet that processed a stylesheet?
I think that things like Schematron are big time hacks: the maintance costs of hard-core XSLT are *HUGE*. Just take a look at the xml2html.xslt stylesheet we ship. It takes half an hour just to understand what it does.
...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.
But the real question becomes: who's concern is to 'prepare' the data for the visualization? the view itself or the underlying controller?
I'm not sure there is a clear answer to that, but for sure not one that rules out the other.
...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.
Yes. If done, the above would just be syntax sugar on top of XSLT. Potentially implementing on *part* of it but for sure without extending it or it would be impossible to transform it transparently to XSLT.
Also because I'm lazy and I want to reuse good machinery (XSLTC) when I see it :)
Stefano.
