Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 86932 invoked by uid 500); 3 Apr 2003 10:32:49 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 86835 invoked from network); 3 Apr 2003 10:32:48 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 3 Apr 2003 10:32:48 -0000 Received: (qmail 3992 invoked from network); 3 Apr 2003 10:33:00 -0000 Received: from unknown (HELO apache.org) (stefano@80.105.91.155) by pulse.betaversion.org with SMTP; 3 Apr 2003 10:33:00 -0000 Message-ID: <3E8C0E00.3040102@apache.org> Date: Thu, 03 Apr 2003 12:33:36 +0200 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] the quest for the perfect template language References: <5FD5906B-6599-11D7-BF6E-000393CFE402@codeconsult.ch> In-Reply-To: <5FD5906B-6599-11D7-BF6E-000393CFE402@codeconsult.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Bertrand Delacretaz wrote: > 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 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 ("/") { >> >> >> {list/@name} >> ... > > > 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.