On 29 Jul 2004, at 20:40, Tony Collen wrote:
Steven Noels wrote:
&snip;
IMHO, simplicity has to do with predictability. XML grammars have this, scripting languages don't. While the use of a non-XML (scripting?) grammar for the site/flowmap might be clever, it might reduce the predictability. Too much magic for my poor brains. And even XML happens to be abused at times.
Scripting languages (and programming languages in general) are easy to create, all you need to do is define the grammar and tokens, and feed it all to something like JFlex/BYacc to create a parser. Perhaps it's easier said than done. Granted, I've done nothing with parser generators, but in the end I think it's the same.
Agree, but I'm not convinced that we are just aiming for a simpler syntax. I feel we're moving away from declarative, and I'm convinced that this might reduce the predictability of Cocoon's behaviour and usage model.
I've been jotting down sitemaps in shorthand notation myself ...
match *.html
generate {1}.xml
transform 2html.xsl
serialize html... a bit like the humiliated XML used in httpd.conf, but IIUC, what is being suggested ATM is the introduction of the usual programming language constructs in Cocoon's request handling configuration syntax.... isn't its quest for Turing-completeness one of the reasons why XSLT has been shunned by real developers: being too much and too little of a programming language at the same time? With a programming language-like sitemap language, we might end with the same result.
I read mod_rewrite as an example, and I remember without looking up that the documentation of that module is the only one with a special foreword explaining/warning how wildly exotic it is.
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source Java & XML An Orixo Member Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
