First of all, congratulations for finishing your thesis successfully!
I think, we all are waiting for your "return" in autumn. But until
then: have nice vacations!
And now to something totally different...
> Stefano Mazzocchi wrote:
>
> 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.
>
If I understand you right, you can already do this by simply using the
generator you want and then using the CIncludeTransformer, or did I miss
a point?
I agree, you are right, that the implemented content aggregation is not
suitable for creating (I try to avoid the verb generate) dynamic (e.g.
user dependant) content.
But I am not sure, if this is a concern of Cocoon itself. I see it rather
in another module/project (or whatever) which builds on top of Cocoon 2,
e.g. a portal engine using Cocoon 2 as a base.
This engine itself uses the facilities provided and creates a user-dependent
portal, e.g. by implementing a generator does both tasks you mentioned
above.
> 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.
>
When I implemented the cocoon: urls I wasn't sure about this either.
Personally, I think there are only some cases where you need to refer
to the root sitemap from your subsitemap. I think it is very difficult
to maintain as well. If a subsitemap refers to anything on the root sitemap,
you can't change the root sitemap as you would perhaps like to, because
this could brake the subsitemap and therefore your website.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: [EMAIL PROTECTED]
================================================================
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
