Re: [CocoonInAction] 2 new articles
Erik Bruchez wrote: Stefano Mazzocchi wrote: o We do strongly believe that the XML pipeline language in OPS beats the ... out of Cocoon pipelines ;-) Oh, that's a bold statement :-) Yes ;-) eheh, one step up and two step back. Your pipeline language feels turing complete (haven't proved it but I think it's duable), if that is what you mean by beating the ... out of, well, we have a different definition of '...' :-) Honestly, I wouldn't be able to tell you for sure if it is turing complete or not. XPL was not designed to be a general-purpose programming language, or anything even close. If you try to write a chess program in XPL, you will give up rapidly! In fact, XPL was designed to address a number of practical use cases directly related to processing XML documents / infosets. Yes there are conditionals and iterations, but it stops there. I do see value in more expressive power, but I also see a lot of danger in introducing turing completeness in an XML syntax. Everytime I see if or foreach I puke. XSLT made that mistake first and now everybody is trying to make the same mistake. Not sure why this is a mistake. As far as using an XML-based syntax, I am still of the school that it is a good thing: you can more easily automatically generate programs, even dynamically; creating software that creates a graphical representation of the program is easier; etc. You can also develop a non-XML compact syntax in addition to the XML syntax. This is what Relax NG has done. Let's agree to disagree then. -- Stefano.
Re: [CocoonInAction] 2 new articles
Sylvain Wallez wrote: Look at this page : http://www.orbeon.com/community/cocoon 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 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. 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. o We do strongly believe that the XML pipeline language in OPS beats the ... out of Cocoon pipelines ;-) By the way we now have a draft spec hosted at W3C: http://www.w3.org/Submission/2005/SUBM-xpl-20050411/ We encourage any person dealing with XML (including Cocoon-ers) to have a look at it and to submit feedback on the ops-xpl mailing-list (which intends to discuss XPL 100% independently from OPS): http://forge.objectweb.org/mail/?group_id=168 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. 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. 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. 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. o Minimal need for Java code. Most of the applications you build with OPS don't require any Java code. From what I've heard, Cocoon's approach is still a little different. I guess sitemap actions are pretty obsolete by now, but they are there and people keep talking about them; same for XSP. I write Java code on a daily basis, but I do think that reducing the need for Java code in the presentation layer is a very sound approach, and my definite impression is that Cocoon doesn't go as far as OPS in this respect. Follows on the comparison page a matrix comparing individual features. Maybe that's where there are issues? Then please, let us know (or let me know directly) where the problems are. It's going to be more productive than labeling the comparison matrix as unfair. Anyway, the goal of this long list was to make it a little clearer where the comparison matrix and claims in favor of OPS come from. I hope I have succeeded.
Re: [CocoonInAction] 2 new articles
Wow wow wow... I didn't intend to trigger some kind of civil war ;o) I think that what you say, Erik, makes sense but do you really think it's the right place for that kind of advocacy. I mean... what would you think if you were in your bank talking with your banker and someone from the competitor bank on the other side of the road enters and gives arguments for his own products. Even if some are true, none of them seem fair to me. Personaly I don't think that this is the ideal spot for such a discussion. Maybe you could have made comments on Cocoon In Action website, directly related with the article at the origin of this subject, by reviewing the article of posting comments on forums. Or maybe direct emails to people concerned (like Sylvain for example). Anyway, as I said this was not my first intention, I didn't want to bring that kind of comparison to this list which is (if I remember well) dedicated do Cocoon development. So I sincerely hope that this conversation will not degenerate into some kind of ideological argue. -- Sebastien ARBOGAST
Re: [CocoonInAction] 2 new articles
Well, different people have different needs and different visions on how to develop applications. There is no right or wrong. The comparison at orbeons site may or may not be correct, but Erik and the developers over at Orbeon are trying to market their product. In doing that they made a comparison that, in my view, isn´t particularly objective. A lot of statements about cocoon have no description of the functionality or the possibilities, instead they focus on Not recommended, yes, but limited, possible but not encouraged, Undocumented. May be possible with TrAX. To me this is pure marketing junk. :) However, Erik has the right to voice his opinion on this list as has everyone else. I may not agree with him and I believe most of his claims that Orbeon is a better tool than Cocoon are based on his subjective views and nothing else. I certainly don´t want you to get offended by this mail, Erik. I merely wanted to point that people have different perspectives on things, there are probably things that are great about Orbeon and there are probably things about Cocoon that suck. However, a more in-depth comparison between the two would be interesting, maybe you could describe the process you used when you did your comparison? Best regards, Mats
Re: [CocoonInAction] 2 new articles
Mats wrote: A lot of statements about cocoon have no description of the functionality or the possibilities, instead they focus on Not recommended, yes, but limited, possible but not encouraged, Undocumented. May be possible with TrAX. To me this is pure marketing junk. :) It's interesting to know that this is the effect that comparison matrix can have. This said, I will stop mentioning the name of our project here. As Sebastien pointed out, it is a Cocoon development mailing-list. I just wanted to react to the criticism that the comparison had wrong points, and mention my frustration of not hearing specifics. Now I have heard a couple, and will try to act on that. But keep in mind that it is a very difficult exercise to compare technological solutions, and it is even more difficult to do so without being criticized. I certainly don´t want you to get offended by this mail, Erik. Not at all! -Erik
Re: [CocoonInAction] 2 new articles
Sebastien Arbogast wrote: Anyway, as I said this was not my first intention, I didn't want to bring that kind of comparison to this list which is (if I remember well) dedicated do Cocoon development. So I sincerely hope that this conversation will not degenerate into some kind of ideological argue. Don't worry, this is not going to happen. But I don't think it was out of line from my part to react in this mailing-list: I reacted directly to a particular criticism, and after all this list is public. Also, I have little hope of convincing hardcore Cocoon developers to switch to anything else. This said, don't you think that whether XForms is important or not to Cocoon, whether Cocoon pipelines should be improved or not, etc. are in fact subjects relevant to cocoon-dev? I believe there could be very sound discussions about this on this mailing-list (discussions to which I would refrain to participate because of my obvious bias). Going back into hiding now ;-) -Erik
Re: [CocoonInAction] 2 new articles
Erik Bruchez wrote: Sylvain Wallez wrote: Look at this page : http://www.orbeon.com/community/cocoon 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 outputs - serializers mix concerns by defining both the XML to binary conversion (the actual serialization) and the destination of the serialized data. snip/ 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
Re: [CocoonInAction] 2 new articles
On Dom, 17 de Abril de 2005, 13:52, Sebastien Arbogast dijo: Wow wow wow... I didn't intend to trigger some kind of civil war ;o) I think this is not going to happen. AFAIK, Erick point is: Cocoon community often say the comparison matrix is not fair. OK, lets fix it. And I think this is a correct approach. This is truly fair. As other pointed out, lets better tell him where we think this is not fair. I think that what you say, Erik, makes sense but do you really think it's the right place for that kind of advocacy. I mean... what would you think if you were in your bank talking with your banker and someone from the competitor bank on the other side of the road enters and gives arguments for his own products. Even if some are true, none of them seem fair to me. We are not bankers. This is a public list. If we want to improve cocoon, lets hear what other have to said. :-) Personaly I don't think that this is the ideal spot for such a discussion. Sorry, but if not here, then where? This is the best place to discuss this. This is the official cocoon dev community mail list, I don't want to subscribe to other place or googling to know about this. Maybe you could have made comments on Cocoon In Action website, directly related with the article at the origin of this subject, by reviewing the article of posting comments on forums. Or maybe direct emails to people concerned (like Sylvain for example). Are you doing the same advocacy that you critized few lines above? ;-) Anyway, as I said this was not my first intention, I didn't want to bring that kind of comparison to this list which is (if I remember well) dedicated do Cocoon development. To me comparison is part of development. A path to improve or enhance whatever piece of code? That is good after all. ;-) So I sincerely hope that this conversation will not degenerate into some kind of ideological argue. Nope. I will like to hear Erick points and to make better the matrix posted on the orbeon website. Best Regards, Antonio Gallardo
Re: [CocoonInAction] 2 new articles
Erik Bruchez wrote: [snip] 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. Well, tell you what: rule number one of any CTO/CIO is never to believe in what a web site says about their own products, especially when comparing to other things in either speed or functionality. No matter how honest, one's view is biased. I suggest people to stop pointing fingers and move on. At the end of the day, Orbeon feels the need to draw a matrix chart and we don't. I'm sure they would be happier the other way around ;-) 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. o We do strongly believe that the XML pipeline language in OPS beats the ... out of Cocoon pipelines ;-) Oh, that's a bold statement :-) By the way we now have a draft spec hosted at W3C: http://www.w3.org/Submission/2005/SUBM-xpl-20050411/ We encourage any person dealing with XML (including Cocoon-ers) to have a look at it and to submit feedback on the ops-xpl mailing-list (which intends to discuss XPL 100% independently from OPS): eheh, one step up and two step back. Your pipeline language feels turing complete (haven't proved it but I think it's duable), if that is what you mean by beating the ... out of, well, we have a different definition of '...' :-) Pipeline components as first class citizens in a programming language have been something I've been thinking about for years and recently even more with Ugo's attempts to rewrite the sitemap syntax as a Groovy extension. I do see value in more expressive power, but I also see a lot of danger in introducing turing completeness in an XML syntax. Everytime I see if or foreach I puke. XSLT made that mistake first and now everybody is trying to make the same mistake. I do believe that one day cocoon will unify flowscript and sitemap and it won't probably be an XML thing (no, not even RDF), but some sort of scripting language (probably syntax sugar around groovy or javascript)... but there are a lot of ifs between now and then and don't worry, we'll keep an eye on that because there is a lot to learn from other people's mistakes ;-) http://forge.objectweb.org/mail/?group_id=168 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. my SoC is bigger than yours. ROTFL, I think I have a new entry in my top 10 BS list. - o - Ok, people, enough bikeshedding. Let's get back to work. -- Stefano.
RE: [CocoonInAction] 2 new articles
my SoC is bigger than yours. Ok, people, enough bikeshedding. Let's get back to work. And all this because of an introduction to a Cocoon tutorial. Now I remember why I didn't want to write this part in the first place. Let's SHOW Cocoon's features and let everyone judge for themselves whether they want to use Cocoon or anything else. If we do it well, it'll attract the people willing to work with it and shy away those who prefer something else. Bye, Helma
Re: [CocoonInAction] 2 new articles
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
Re: [CocoonInAction] 2 new articles
A fast checking to the matrix in: http://www.orbeon.com/community/cocoon Pipeline language/Iterations -- In cocoon is posible with flow. Web Application/XForms support -- We don't nothing propetary, we are an OS project. Perhaps non-standard is a better definition for Cforms. Languages/XSLT 2.0 -- Saxon. Languages/JSP -- not encouraged, we have an special JSP block! Languages/Groovy -- built-in. Language/Javascript server side -- built-in. Document formats/PDF support -- In 2 trhough XSL-FO in 2 flavors: iText and FOP. Database support -- Built-in O/R mapping support for Apache OJB. You can also use Hibernate. Best Regards, Antonio Gallardo. On Dom, 17 de Abril de 2005, 16:56, Erik Bruchez dijo: 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
Re: [CocoonInAction] 2 new articles
Antonio Gallardo wrote: A fast checking to the matrix in: http://www.orbeon.com/community/cocoon Antonio: enough. Let's move on. -- Stefano.
Re: [CocoonInAction] 2 new articles
Sebastien Arbogast wrote: Hi, Just some fresh news about our starting project. 2 new articles were published on Cocoon In Action community website. http://www.epseelon.org/cocooninaction - Project objectives - Motivation http://www.epseelon.org/cocooninaction/index.php?module=subjectsfunc=viewpagepageid=6 rant Why is Orbeon the first one? FYI, Cocoon started in 1999. Orbeon claims to be standards-compliant but it's not much more than Cocoon is, and Cocoon's architecture brings much more potential to *integrate* implementation of standards. Yeah, they claim XForms compliance. But how much of XForms? Not that much more than what XMLForm was providing in Cocoon 2 years ago when we decided to abandon it because a server-side XForm implementation is either overly complex or too much limited. Also being a W3C member means nothing regarding the quality of a company: you just have to pay [1] to be a W3C member. /rant BTW, I tried to register on your site to comment on the article, but it constantly refused my login. Sylvain [1] http://www.w3.org/Consortium/Prospectus/Joining -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [CocoonInAction] 2 new articles
Why is Orbeon the first one? FYI, Cocoon started in 1999. Orbeon claims to be standards-compliant but it's not much more than Cocoon is, and Cocoon's architecture brings much more potential to *integrate* implementation of standards. The first one was more a rhetoric formula : you always present the alternative solutions first, and then the one you've chosen because you think there is the best. It's a way to put things in perspective to explain the motivation of this project : it's not only because I worship Cocoon like others worship Firefox ;o), but because I've compared it to other solutions on the market. And in every comparison there are strengths and weaknesses on both sides. Yeah, they claim XForms compliance. But how much of XForms? Not that much more than what XMLForm was providing in Cocoon 2 years ago when we decided to abandon it because a server-side XForm implementation is either overly complex or too much limited. I don't quite agree about that : I find their approach of XForms quite natural in fact, and much more developer-friendly and structured than Cocoon Forms one, even if I agree it is less powerful. And the thing is the current trend seems to tend to a massive adoption of XForms on client-side. So implementing XForms is an asset for them because what you learn for OPS, you will be able to use it out of it in future applications. Whereas for CForms... Also being a W3C member means nothing regarding the quality of a company: you just have to pay [1] to be a W3C member. /rant Yes but it's also a proof that you're deeply involved in the standardization process and work to maximize the use of standards. Of course you can do that without paying the fee to enter W3C, but if I'm not wrong, you can't participate in the process, you can't make the standards yourself, you can just undergo. Don't get me wrong, I don't make propaganda for competition there. I just try to be objective, to present advantages and drawbacks of both solutions in a few lines, to explain why I think (as a user) that Cocoon is a better solution, and why it deserves a few improvements (and especially documentation improvements) to try to make it the ideal solution. Have you ever seen OPS documentation : it's not very rich because as I said OPS has less features than Cocoon, but it's clear, coherent, well-designed and structured, and updated. That's precisely why I came to OPS first even if I had heard of Cocoon, and I'm sure this happens to others. I don't think that we should be afraid of competition. That's what is interesting with Open Source : you can learn from competition, compare to it, and even take good parts out from competition to use them for yourself. And let's not forget the point-of-view issue : you and I are convinced, we know that Cocoon is the best Open Source solution on the market for XML presentation and publication servers, but newcomers don't. Look at this page : http://www.orbeon.com/community/cocoon I don't know exactly if all this information is verified, but I think this type of comparison is a good point. Anyway, this was not the purpose of my article because it's not really for newcomers. I just tried to put things in perspective, inside my own user and developer experience, in order to explain my own initial motivation on this project. BTW I replaced the first one... ;o) BTW, I tried to register on your site to comment on the article, but it constantly refused my login. Here is the standard procedure I've just tested and it should work : - Link to create a new account : http://www.epseelon.org/cocooninaction/user.php - Click on Join Now - Accept the I am over 13 clause - Fill in your username, password and email (at least) ATTENTION : your password must be at least 5 characters ! - don't forget to check I agree to be bound by this website's Terms of Use and Privacy Policy at the end of the form - Click on New user then on Finish - Then your password is displayed again and you can click on Login Now you should be in your account. I don't see you in members list, which means there was a problem during registration. I should change the standard procedure soon to include an e-mail verification but for now, this one should work just fine. If anyone has problems or questions about the use of this site, please let me know here. I don't know this CMS very deeply for the time being, so there can be a few scratches during the first weeks. -- Sebastien ARBOGAST
Re: [CocoonInAction] 2 new articles
There are other opinions in that matter: http://chiba.sourceforge.net/ http://chiba.sourceforge.net/features.html Yes this project is very interesting and I think that I will study it very carefully for my own use. The question I'm asking myself right now is to figure out how I could generate my forms from a more high-level model. I already set that for my data model thanks to AndroMDA and now if I could find a way to design my forms graphically, it would be great. I saw Schema2CocoonForms page on Wiki and as it uses XMLSchema, maybe I could find some GUI tool to design my XMLSchema and then translate it to Cocoon Forms using this utility. On the other hand, as XForms are a standard, I guess I can already find tools to design them graphically. It's to study... -- Sebastien ARBOGAST
Re: [CocoonInAction] 2 new articles
Daniel Fagerstrom wrote: Sylvain Wallez wrote: snip/ Yeah, they claim XForms compliance. But how much of XForms? Not that much more than what XMLForm was providing in Cocoon 2 years ago when we decided to abandon it because a server-side XForm implementation is either overly complex or too much limited. There are other opinions in that matter: http://chiba.sourceforge.net/ http://chiba.sourceforge.net/features.html I know about Chiba. I never said it's not possible, but that it is difficult, XForms being clearly targeted at client-side implementations. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [CocoonInAction] 2 new articles
Sebastien Arbogast wrote: Why is Orbeon the first one? FYI, Cocoon started in 1999. Orbeon claims to be standards-compliant but it's not much more than Cocoon is, and Cocoon's architecture brings much more potential to *integrate* implementation of standards. The first one was more a rhetoric formula : you always present the alternative solutions first, and then the one you've chosen because you think there is the best. It's a way to put things in perspective to explain the motivation of this project : it's not only because I worship Cocoon like others worship Firefox ;o), but because I've compared it to other solutions on the market. And in every comparison there are strengths and weaknesses on both sides. You missed the rhetoric formula, and the text is (was, now) as it talks about opensource XML frameworks, and then The first one is Orbeon, implying some precedence either in age or value. Yeah, they claim XForms compliance. But how much of XForms? Not that much more than what XMLForm was providing in Cocoon 2 years ago when we decided to abandon it because a server-side XForm implementation is either overly complex or too much limited. I don't quite agree about that : I find their approach of XForms quite natural in fact, and much more developer-friendly and structured than Cocoon Forms one, even if I agree it is less powerful. And the thing is the current trend seems to tend to a massive adoption of XForms on client-side. So implementing XForms is an asset for them because what you learn for OPS, you will be able to use it out of it in future applications. Whereas for CForms... Whereas for CForms you can do today things that are totally omitted by XForms because it's a client spec, such as connection and interaction with data outside the form. How can you e.g. validate in an XForm that an input is an existing purchase order ID in your database? Now if XForms is successful in the client (Firefox support is a nice thing, but what about IE?) you can be sure that Cocoon will provide a powerful combo using the CForms infrastructure server-side connected to client-side XForms. Also FWIW, you can use CForms without even knowing that you do. I have a few stylesheets that produce form definitions and templates from raw HTML pages containing a few additional attributes... Also being a W3C member means nothing regarding the quality of a company: you just have to pay [1] to be a W3C member. /rant Yes but it's also a proof that you're deeply involved in the standardization process and work to maximize the use of standards. Of course you can do that without paying the fee to enter W3C, but if I'm not wrong, you can't participate in the process, you can't make the standards yourself, you can just undergo. FYI, at my company we had some contacts with W3C people and we recently received a mail from their PR team saying (tranlsated) : This would be the appropriate time for your company to join the consortium, participate in the numerous W3C activities and share your experiences in the interested working groups. W3C also offers its members a lot of opportunities to promote their activities internationally. What about respecting standards there? Nothing. Join the W3C because its good for your business (and good for W3C's also). Don't get me wrong, I don't make propaganda for competition there. I just try to be objective, to present advantages and drawbacks of both solutions in a few lines, to explain why I think (as a user) that Cocoon is a better solution, and why it deserves a few improvements (and especially documentation improvements) to try to make it the ideal solution. Have you ever seen OPS documentation : it's not very rich because as I said OPS has less features than Cocoon, but it's clear, coherent, well-designed and structured, and updated. That's precisely why I came to OPS first even if I had heard of Cocoon, and I'm sure this happens to others. I totally agree with you on this point. OPS docs are clean, even I they left me frustrated because they leave a number of things at the tutorial level. But what they have is clearly better presented that what Cocoon has. I don't think that we should be afraid of competition. That's what is interesting with Open Source : you can learn from competition, compare to it, and even take good parts out from competition to use them for yourself. And let's not forget the point-of-view issue : you and I are convinced, we know that Cocoon is the best Open Source solution on the market for XML presentation and publication servers, but newcomers don't. Look at this page : http://www.orbeon.com/community/cocoon 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. Anyway, this was not the purpose of my article because it's not really for newcomers. I just tried to put things in perspective, inside my
[CocoonInAction] 2 new articles
Hi,Just some fresh news about our starting project. 2 new articles were published on Cocoon In Action community website. - Project objectives - Motivation - Case Study Application - HealthyCocoon, from Helma's suggestion on this list. Of course every comment or feedback is welcome. You can also use forums to discuss about the different questions to answer before beginning to write the tutorial. I haven't written opening subjects for those forums yet, but they are already activated and you can use them as soon as you are member of the site. Just make sure your posts only deal with our tutorial project. For other discussions about Cocoon documentation, there is the Cocoon dev mailing list. More content will come in the next few days and I already figured out how we can convert any document written in the CMS into Forrest-aware HTML files so integration should work perfectly. Oh... and don't hesitate to give us feedback about the website itself. Design is quite basic for the time being but at least it's functional. Regards. -- Sebastien ARBOGAST
