cocoon-dev mailing list archives

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

 > That is the exact definition of a marketing document rather than an
 > objective comparison ;-)

Then I agree, it is a marketing document ;-) This is just an
impossible task: when you are so into a platform or technology, how
can you be actually fair to others, in spite of your efforts? Then if
you were not that much into it, you would not see any benefit in
comparing it with others. Validation should rather come from
third-parties, but then how do you make such third-parties aware of
what makes your platform different? That's a catch-22 :-)

 > 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

I reckon. Working on it though...

 > 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

Debatable... But it's a little bit like variables in Java or XSLT, for

 > - serializers mix concerns by defining both the XML to binary
 > conversion (the actual serialization) and the destination of the
 > serialized data.

This has actually been fixed since then, with a split between
"converters" and "serializers". BTW this is not directly related to
XPL, rather to the way it is used, the bottom line being that XPL only
deals with XML infosets and doesn't know natively about "text" or

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

Sounds good.

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

I don't think I agree with that. Those are usually available as
separately named pipeline inputs and outputs (therefore separate
documents / XML infosets), or requested with particular XML processors
(components). If you need the result of all of those in a page view,
then you may want to aggregate them. But the best practice is to
create a "nice" page model document which contains exactly the
information that needs to be presented in the page view.

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



View raw message