http://www.orbeon.com/oxf/cocoon
Well, at a very least the information is incomplete, not to mention that it's a bit biased and somewhere just plain wrong. Some marketing is understandable, but I think that a few corrections are due to make it fair.
However, Orbeon is solicitating comments, so I've put them in CC: I hope that they will be so kind to discuss and possibly update their informations.
Walking through the page:
Plaing wrong stuff ==================
OXF provides the following advantages over Cocoon: [...]
Professional support. The OXF mailing-list provide free support from our responsive development team. Additional professional support from the people who designed OXF can be obtained.
Cocoon here is no difference. There are a lot of free support resources, like mailing lists and Wiki (I might even market the Wiki as a "Knowledge Base"). Additional professional support is also available: there is a whole organization of (currently) six companies supporting Cocoon in Europe in a consistent way (Orixo, that is) and there are quite a few independent companies providing the same services all over the world. Maybe it's time to add a prominent page on the Cocoon web site about it.
Application-Agnostic The Cocoon sitemap was initially designed to handle linear pipelines according to a generation / transformation / serialization pattern suited for Web publishing.
This is quite stressing the truth. Cocoon can be used in every request-response based environment. There is both a CLI command and a bean that allow Cocoon integration in heterogeneous environments. Cocoon is completely abstracted from the Web (Servlet) environment.
Conditionals No. Very limited flow control with actions requiring Java.
Untrue. There are selectors too, at a very least. And there is Flow.
XML Validation No
Uh? Just set your parser as a validating parser and you have validation.
XPointer Support No
The Xinclude transformer has XPointer support.
Support for J2EE Datasources Configuration involves several files and does not appear to be encouraged.
Unfair and wrong: a J2EE datasource can be defined in a snap in cocoon.xconf. There is no need to involve several files and definitely Cocoon does not disencourage using J2EE stuff.
EJB Support Possibly, through XSP.
Wrong! EJB's can be used all over the place and at a very least in Actions, XSP and Flow. Not to mention that nothing forbids writing generators/transformers/serializers based on external EJB components.
XSLT 1.0 Yes, built-in Xalan.
Nope. Cocoon is pre-configured to use TraX, plain Xalan, plain Saxon or XSLTC, just as OXF.
JSP With Tomcat only?
No. I'm not JSP guru, but I don't see any Tomcat dependency. One of the implementation uses the generic servlet RequestDispatcher, so it should be portable across application servers. Besides, there is a specific WLS implementation.
Flexed truth
==============
There are a few points hinted as Cocoon limitations such as sub-pipelines, aggregation, J2EE authentication, XForms. These are actually design choices, all with pros and cons, so blaming cocoon (at different levels) for not supporting it is somehow misleading.
Cocoon strong points
====================
OXF doesn't mention a few Cocoon strong points. I would like to see at a very least:
- Views;
- Pluggable URL-like extensions (the Source interface);
- WebDAV support, as client (stable), server (partial) and proxy (development);
- XML:DB support;
- SAP R/3 connectivity;
- Scheduler components;
- Velocity support;
- Python (Jython) and generic BSF support;
- PHP support;
- Lucene integration;
- Text to XML conversion using generated grammars (chaperon);
That's it for now, but I've sure left out something. I hope that Orbeon is willing to talk about their feature matrix in order to give a reasonable, fair and useful comparison tool to their potential customers.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
