cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [CocoonInAction] 2 new articles
Date Sun, 17 Apr 2005 20:22:15 GMT
Erik Bruchez wrote:

> Sylvain Wallez wrote:
> >> Look at this page :
> >>
> >> 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 
- serializers mix concerns by defining both the XML to binary conversion 
(the actual serialization) and the destination of the serialized data.


> 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.


> > BTW, I met one of Orbeon's founders and he explained me they started 
> > 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 


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message