Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 889 invoked from network); 17 Apr 2005 20:37:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Apr 2005 20:37:32 -0000 Received: (qmail 97750 invoked by uid 500); 17 Apr 2005 20:37:30 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 97561 invoked by uid 500); 17 Apr 2005 20:37:29 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 97545 invoked by uid 99); 17 Apr 2005 20:37:29 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from blossom.betaversion.org (HELO blossom.betaversion.org) (62.140.213.100) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 17 Apr 2005 13:37:28 -0700 Received: by blossom.betaversion.org (Postfix, from userid 101) id C6F2B1D0310; Sun, 17 Apr 2005 21:37:14 +0100 (BST) X-AntiVirus-Version: ClamAV 0.84rc1/837 X-AntiSpam-Version: SpamAssassin 3.0.2 X-AntiSpam-Status: No (score=0.0/limit=7.5) Received: from [128.30.5.240] (30-5-240.wireless.csail.mit.edu [128.30.5.240]) by blossom.betaversion.org (Postfix) with ESMTP id E3E391CB9E5 for ; Sun, 17 Apr 2005 21:37:12 +0100 (BST) Message-ID: <4262C90D.3080803@apache.org> Date: Sun, 17 Apr 2005 16:37:33 -0400 From: Stefano Mazzocchi Organization: Apache Software Foundation User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [CocoonInAction] 2 new articles References: <4260D62C.2050403@apache.org> <426138F8.8040709@apache.org> <4262AA8F.8080103@bruchez.org> In-Reply-To: <4262AA8F.8080103@bruchez.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Erik Bruchez wrote: [snip] > I don't believe the comparison can be all wrong, or even all unfair, > even if there is certainly subjectivity in it, and even if we mainly > mention OPS's strengths rather than weaknesses. Well, tell you what: rule number one of any CTO/CIO is never to believe in what a web site says about their own products, especially when comparing to other things in either speed or functionality. No matter how honest, one's view is biased. I suggest people to stop pointing fingers and move on. At the end of the day, Orbeon feels the need to draw a matrix chart and we don't. I'm sure they would be happier the other way around ;-) > Just looking at the main points we make: > > o Our belief that XForms is an excellent choice is subjective, but > there are some good arguments for XForms, server-side and > client-side (hey, I am giving a talk about server-side XForms at > XTech 2005), and we hope to convince people who think the same to > use OPS. That's not denying Sylvain's excellent work on Cocoon > Forms. > o We do strongly believe that the XML pipeline language in OPS beats > the ... out of Cocoon pipelines ;-) Oh, that's a bold statement :-) > By the way we now have a draft spec hosted at W3C: > > http://www.w3.org/Submission/2005/SUBM-xpl-20050411/ > > We encourage any person dealing with XML (including Cocoon-ers) to > have a look at it and to submit feedback on the ops-xpl mailing-list > (which intends to discuss XPL 100% independently from OPS): eheh, one step up and two step back. Your pipeline language feels turing complete (haven't proved it but I think it's duable), if that is what you mean by beating the ... out of, well, we have a different definition of '...' :-) Pipeline components as first class citizens in a programming language have been something I've been thinking about for years and recently even more with Ugo's attempts to rewrite the sitemap syntax as a Groovy extension. I do see value in more expressive power, but I also see a lot of danger in introducing turing completeness in an XML syntax. Everytime I see or I puke. XSLT made that mistake first and now everybody is trying to make the same mistake. I do believe that one day cocoon will unify flowscript and sitemap and it won't probably be an XML thing (no, not even RDF), but some sort of scripting language (probably syntax sugar around groovy or javascript)... but there are a lot of ifs between now and then and don't worry, we'll keep an eye on that because there is a lot to learn from other people's mistakes ;-) > http://forge.objectweb.org/mail/?group_id=168 > > o The separation of concerns issues have been discussed on cocoon-dev > by fervent Cocoon-ers: the sitemap for example is quite a mixup of > different things. Of course there is some separation of concern in > Cocoon, there is no denying this, but for example OPS separates > clearly the concept of "sitemap + page flow" (which we call "page > flow" because it declares pages as well as the relationship between > them) from pipelines; the OPS page flow clearly separates page views > and page models, and encourages developers to follow this > model. Hence the claim that OPS has greater separation of concerns. "my SoC is bigger than yours". ROTFL, I think I have a new entry in my top 10 BS list. - o - Ok, people, enough bikeshedding. Let's get back to work. -- Stefano.