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 example.
> - 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 "binary".
> 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.
Granted.
-Erik
