Sylvain Wallez wrote:
>> Look at this page : >> http://www.orbeon.com/community/cocoon >> I don't know exactly if all this information is verified, but I think >> this type of comparison is a good point. > > We looked at it, and some points in this comparison are clearly wrong.
Sorry to interfere on Cocoon's dev list: I admit that I keep an eye on it, especially when I see the name of my company and product :-) Be assured that this email is written in all friendliness. As Sylvain mentioned, we met once, and I have met Bertrand (who like me operates out of Switzerland) a couple of times now, and I have no reason to believe that these two Cocoon-ers in particular are anything but great people.
I would like to say that after this Orbeon PresentationServer (OPS) / Cocoon comparison was first mentioned in cocoon-dev, when it was still called the OXF platform, we got some feedback and promptly updated the page. But it's not the first time since then that I read on cocoon-dev that the comparison is incorrect / unfair / evil / heretic (because it dares pretend that something out there may do some things better than Cocoon!) - ok, I am making that up, but that's a little how it looks to me. But we have yet to get a single feedback email telling us exactly what's wrong with the current version.
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. 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 ;-) 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):
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.
o The OPS platform consistency has been defended on this very mailing-list by Cocoon-ers who have read the OPS documentation and/or tried the platform. On the other side I have read here from how Cocoon can be a complex web of different things that are difficult to sort out. I don't think that it is unfair for us to mention that we believe that more consistency is a benefit, and to claim that OPS has more of it.
o Declarative Page Flow. Ok this is arguable, as some people will love Cocoon's JavaScript-based (and more programmatic) approach, which is very flexible and a very interesting model. So far we believe that the more declarative you get, the better.
o Commitment to XML standards. See the XForms section. And also, we love having XML Schema and Relax NG tightly integrated with pipelines. We also believe that it is important to integrate XSLT 2.0 and XPath 2.0 early. So we encourage users, through documentation, tutorial and examples, to use those technologies, and that's what I call being committed to XML standards. And we also believe that this has benefits.
o Minimal need for Java code. Most of the applications you build with OPS don't require any Java code. From what I've heard, Cocoon's approach is still a little different. I guess sitemap actions are pretty obsolete by now, but they are there and people keep talking about them; same for XSP. I write Java code on a daily basis, but I do think that reducing the need for Java code in the presentation layer is a very sound approach, and my definite impression is that Cocoon doesn't go as far as OPS in this respect.
Follows on the comparison page a matrix comparing individual features. Maybe that's where there are issues? Then please, let us know (or let me know directly) where the problems are. It's going to be more productive than labeling the comparison matrix as unfair.
Anyway, the goal of this long list was to make it a little clearer where the comparison matrix and claims in favor of OPS come from. I hope I have succeeded.
> BTW, I met one of Orbeon's founders and he explained me they started OPS > because they were frustrated by Cocoon 1. Now Cocoon people also were > frustrated, and this led to Cocoon 2.
Actually, we were frustrated with Cocoon 2. That was back in 2002, and our company's web site was made with Cocoon 2 at the time. I also had a couple of personal web sites running on Cocoon 2. Just setting the record straight ;-)
-Erik
