You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sebastien Arbogast <se...@gmail.com> on 2005/04/16 00:23:40 UTC
[CocoonInAction] 2 new articles
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=subjects&func=viewpage&pageid=6>
- Case Study Application<http://www.epseelon.org/cocooninaction/index.php?module=subjects&func=viewpage&pageid=4>->
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
Re: [CocoonInAction] 2 new articles
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Erik Bruchez <er...@bruchez.org>.
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.
-Erik
Re: [CocoonInAction] 2 new articles
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Antonio Gallardo <ag...@agssa.net>.
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
Posted by Erik Bruchez <er...@bruchez.org>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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 that turn it into some kind of programming language.
> 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.
XSLT 2.0 has only one OSS implementation which is Saxon. People can use
it right now by adding saxon.jar in their application and decommenting
an entry in Cocoon's configuration.
<snip/>
> > BTW, I met one of Orbeon's founders and he explained me they started
> OPS
> > because they were frustrated by Cocoon 1. Now Cocoon people also were
> > frustrated, and this led to Cocoon 2.
>
> Actually, we were frustrated with Cocoon 2. That was back in 2002, and
> our company's web site was made with Cocoon 2 at the time. I also had
> a couple of personal web sites running on Cocoon 2. Just setting the
> record straight ;-)
Sorry, from our conversation I understood this was Cocoon 1. I stand
corrected.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [CocoonInAction] 2 new articles
Posted by Erik Bruchez <er...@bruchez.org>.
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
Posted by Antonio Gallardo <ag...@agssa.net>.
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
Posted by Erik Bruchez <er...@bruchez.org>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
Mats wrote:
> 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. :)
+1.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [CocoonInAction] 2 new articles
Posted by Mats <ma...@alma.nu>.
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
Posted by Sebastien Arbogast <se...@gmail.com>.
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
Posted by Erik Bruchez <er...@bruchez.org>.
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.
> BTW, I met one of Orbeon's founders and he explained me they started OPS
> because they were frustrated by Cocoon 1. Now Cocoon people also were
> frustrated, and this led to Cocoon 2.
Actually, we were frustrated with Cocoon 2. That was back in 2002, and
our company's web site was made with Cocoon 2 at the time. I also had
a couple of personal web sites running on Cocoon 2. Just setting the
record straight ;-)
-Erik
Re: [CocoonInAction] 2 new articles
Posted by Sylvain Wallez <sy...@apache.org>.
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
>own user and developer experience, in order to explain my own initial
>motivation on this project. BTW I replaced "the first one"... ;o)
>
>
Thanks. The new version makes it clear that you explain your own path
through XML frameworks and that _you_ met Orbeon first. That wasn't what
was implied by the previous version.
BTW, I met one of Orbeon's founders and he explained me they started OPS
because they were frustrated by Cocoon 1. Now Cocoon people also were
frustrated, and this led to Cocoon 2.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [CocoonInAction] 2 new articles
Posted by Sebastien Arbogast <se...@gmail.com>.
> 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
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [CocoonInAction] 2 new articles
Posted by Sebastien Arbogast <se...@gmail.com>.
> 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
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
<snip/>
/Daniel
Re: [CocoonInAction] 2 new articles
Posted by Sylvain Wallez <sy...@apache.org>.
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=subjects&func=viewpage&pageid=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 Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director