I think you guys are doing a great job. From looking at the CVS commits
and the mail logs this project has never been so healthy and I think I
can finally say that Cocoon is a project that is going to last,
community wise.
This, people, is not so obvious as you would expect: I'm talking about
years in the future, not a few months. After watching many OSS projects
and bootstrapping a few, I believe that Cocoon has the right balance to
keep going for a long time, despite the changes in the development team.
This said, feeling very proud of having started all this and feeling
honored of seeing so many people working actively on such a great
project, I have some small comments to make on the design decisions that
were made in my absence.
Of course, not being there when the design decisions were made, I'm
absolutely happy with the state of the project, I'm just writing you my
comments that you might find helpful.
If not, well, at least I made myself heard. :)
content aggregation
-------------------
Content aggregation at sitemap level is, IMHO, limiting and imposes some
degree of overlap between concerns.
An example clarifies this in detail: suppose you want to create some
JetSpeed-like application using Cocoon2. Aggregation on the same
resource (say '/') should depend on user identity and its preferences
(think my.netscape.com) which might be stored someplace in a database,
LDAP, file, memory, session, cookie, you name it.
This is not possible if the aggregation controls are hardwired into the
sitemap.
It has been recently noted how there is no component that "aggregates".
Sure, you could say: ok, let's make a pluggable aggregating component to
make this user-preferred portal possible.
Yes, that's a solution, but I believe the design mistake here is that
"aggregation" is seen as "generation" while I see it as
"transformation".
Suppose you have something like this:
generator -> layout page
transformer -> aggregator
now you can have a generator produce the outline of the page and the
transformer (sort of server-side XInclude for XML Inforsets) produce the
aggregated content. The layout might use a specific namespace that is
used to react further namespace behavior on the transformer. For example
<lay:layout xmlns:lay="../cocoon/layout"
xmlns:agg="../cocoon/aggregate">
<agg:include agg:src="hello.xml" agg:ns="http://www.blah.com"/>
</lay:layout>
where "hello.xml" is
<page>
<p>HelloWorld!<p>
</page>
which leads
<lay:layout xmlns:lay="../cocoon/layout"
xmlns:agg="../cocoon/aggregate">
<page xmlns="http://www.blah.com";>
<p>HelloWorld!<p>
</page>
</lay:layout>
or something like that.
Cocoon:/ protocol
-----------------
While I consider the concept of being able to refert to sitemap
generated resources directly with a specific protocol very good, I
question the necessity for the ability to access the root of the
sitemap.
I'm still not sure myself about this, but I believe that it might lead
to concern overlap between the different people responsible for the
different sitemaps.
One of the original goals of the sitemap semantics were that they must
be fully "relocatable": this means that you can mount your sitemap on
"/news" one day and on "/new-news" the next without having to tell the
people responsible for the "news" sitemap.
It's true that the use of absolute paths doesn't break sitemap
relocability, but we must avoid something like
cocoon:/../logo
since *this* breaks relocability since it assumes something on the mount
point of the sitemap and this is *bad*!
Also we must ask ourselves if the ability of having absolute access to
nternal resources might result in contract failure between the concern
islands responsible for the current sitemap and the root sitemap.
I honestly don't know, let's see if my comments trigger something.
now some RT I'm having in the back of my mind
namespace-reacting trasnformations
----------------------------------
There are a bunch of discussions on stylebook/anakia/cocoon these days
going on and I'm happy that Donald set up the Cocoon-By-Cocoon site
since it gives us (finally) a serious place to show off our power.
The usual "my DTD is better than yours" flames will start firing as soon
as we decide what DTD to use.
I heard comments such as "I don't like <link> because I'm used to type
<a> and I end up with <link src="..."></a>". There is no way we can
settle this even if we make the tools available to automatize this.
At the same time, it's pretty piece of cake to do transformations
between tagsets if the semantic meaning is equivalent: if the guy likes
<a>, that's totally fine for me, as long as it's semantically
consistent.
For "semantically consistent" I mean that <a> is always used instead of
<link> and that there is the chance of knowing what that <a> means for
that particular guy.
Now, suppose you want to generate documentation but you "don't" know in
advance the schema used for it. All you know is that your pipeline
expects "docbook" from some point on and you do have some "adaptation
stylesheets" that transform these simplified but semantically equivalent
DTDs into docbook.
So, visually, you have:
generator -[docbook]-> transformer -[fo]-> serializer -[pdf]-> client
but if you don't know in advance the markup used you need to adapt
generator -[???]-> adaptor -[docbook]-> ...
There are two ways to identify the semantic context of the document:
1) DTD/Schema
2) namespace
In the firts case, the behavior is straightforward: depending on the
DTD/Schema, apply a different transformation sheet.
In the second case, if the namespace used is one and only one, the same
behavior applies. Otherwise, the writing of the stylesheets is more
complex since it must copy over all the other tags that don't belong to
the namespace that want to adapt.
Bah, anyway, food for thought.
Ciao.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
