Erik Bruchez wrote:
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 guess it's because that would lead us to a useless bikeshedding war between comparisons.
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.
That is the exact definition of a marketing document rather than an objective comparison ;-)
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.
IMO you did a very good job at making XForms a strong marketing item for OPS (XForms comes first in OPS docs, before the pipeline language!). But your implementation is very far from being compliant to the W3C spec, and the way you use it mixes concerns (see pipeline data below).
o We do strongly believe that the XML pipeline language in OPS beats the ... out of Cocoon pipelines ;-)
I admit XPL is elegant (and I told you so). There are a few points that hinder this elegance though:
- it's hard to read, as it contains a lot of references to tie inputs to outputs
- serializers mix concerns by defining both the XML to binary conversion (the actual serialization) and the destination of the serialized data.
<snip/>
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.
So what is the <map:flow> about? Defining page flow controllers. It is declared in the sitemap because the sitemap is the entry point of every request coming into the system, and because sitemaps also define subcomponents in a large application.
Now OPS also has its mixing of concerns in the pipeline data where a single document mixes everything: xforms instance, description of the request, page data, etc.
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.
Yes, Cocoon is inconsistent in some places. But this inconsistency comes from the incredible amount of features it provides and the fact that it was built by a large group of developpers.
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.
FYI, we discussed here back in 2002 something called "flowmap" for months without coming to a satisfying solution, when someone came with flowscript. And programmatic page flow offers a tremendous power without much price. Any declarative page flow XML language ends up with control structure that turn it into some kind of programming language.
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.
XSLT 2.0 has only one OSS implementation which is Saxon. People can use it right now by adding saxon.jar in their application and decommenting an entry in Cocoon's configuration.
<snip/>
> 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 ;-)
Sorry, from our conversation I understood this was Cocoon 1. I stand corrected.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
