Cocoon 3.0 is a full rewrite of Cocoon by the people with experience from the earlier versions. It is designed to meet the demands of modern web applications. This means:
- Cocoon 3.0 aims to become the best platform for RESTful services
- You can use Pipelines without being tied to the Servlet API
- It is easier to integrate your own Java code into a pipeline
- Superfluous packages are cut out of the platform
A more detailed post on the changes planned for Cocoon 3.0 is written by Reinhard Pötz, one of the driving forces behind the new Cocoon version.
4 comments:
The approach sounds right but I am baffled by one thing: there is no mention in this big plan that the pipeline engine would be based on XProc (http://www.w3.org/TR/xproc/), or at least provide that as an alternative. So what's the point? Incredible...
-Erik
If I read the latest material on Cocoon well, I think the real question is whether Cocoon still intends to be an XML Pipeline platform or whether it intends to be a Component Pipeline platform, accidentally providing simple XML Pipelining mechanisms.
I am not sure about that though...
Why is it that when I search for Orbeon and Cocoon, most articles consider them as competitors?
To me, it seems that Orbeon concentrates on the front end and Cocoon (especially 3.0) concentrates on the back end. With REST as a neutral party in the middle, it is a perfect native XML (+ a little Java) combination.
Out of curiosity: why do you think Cocoon needs XProc?
Standardization? At this point XProc is still a Working Draft...
Couldn't the cocoon-pipeline and cocoon-sitemap modules be easily replaced by XProc implementations without impact on any other module?
Just questions from a neutral outsider. I am genuinely looking for a combination between the two technologies.
Adriaan,
It is true that in the beginning Orbeon was positioned as a competitor of Cocoon. This hasn't been the case for many years now. Orbeon Forms still relies on XML pipelines for the underlying infrastructure and the implementation of lightweight services, but it has decidedly moved towards being a forms platform, including the XForms engine, the Form Runner runtime, and the Form Builder tool. Since it is now clearer that Cocoon is abandoning the front-end, Orbeon and Cocoon are now even less in competition.
(This said, we routinely implement REST services in Orbeon. I am not sure how much new functionality Cocoon 3 will bring on top what we already have in Orbeon to implement services.)
Yes XProc is a working draft, but it will reach Candidate Recommendation soon, and implementations are already in the works (http://xmlcalabash.com/). And standardization is as much about the process than about the resulting spec. Members of the XML processing working group (including us) have worked together to gather ideas from various existing implementations. The process has put together these ideas to come with a unique language. This is almost the ideal of a standardization process.
The reason I think Cocoon would need XProc is that the core of Cocoon is an XML pipeline engine, with a pipeline definition language (a subset of the "sitemaps"). It sounds unreasonable to me to start new developments involving XML pipelines without even looking at XProc as a core requirement.
-Erik
Thank you for writing this, Erik! I will dive into XProc, Calabash, the ways to implement services in Orbeon vs. in Cocoon 2.2/3.0 and report back later on this weblog.
And I agree with you that any upcoming W3C Recommendation should at least be considered. The attitude should be "Comply or Explain". I did not see any recent explanations...
Post a Comment