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.
Good to hear from you.
> content aggregation
> -------------------
>
> Content aggregation at sitemap level is, IMHO, limiting and imposes some
> degree of overlap between concerns.
I tend to agree. I sent a private email to Giacomo for some ideas on
the next version of Cocoon (he's on vacation so he won't see it until
next week). I am wanting to facilitate a better concern map (which
from using Cocoon for a while I have a better idea of how it should
be).
> 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.
Preach it.
> 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>
I see. We have both the XInclude processor and the CInclude processor.
If the XInclude processor can handle the "cocoon:" protocol, we will only
need the standards based version.
> 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.
This approach is necessary many times in real development. You can't
create a site that never has any absolute references if you have all
your images in one directory. Just the same, you can't ensure the
entire site has the same "pipeline" if you can never refer to resources
at the root.
In your paper, you yourself addressed the problem of URLs that change.
This is no exception to that rule.
> 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.
This isn't necessarily a problem though.
> 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.
Cocoon is also used to build the Avalon documenation written in DocBook.
There is even a Stylebook 2 DocBook conversion stylesheet in Avalon.
Talk about power....
> 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.
In the example you outlined, I would tend to say, "Make a decision already!"
Writing documentation or creating a site with semantic markup requires that
the team use a standard for the site. If you don't, you are asking for trouble
later on when you need to maintain the site. Period.
Now, when it comes to transformers that add functionality (such as the
XIncludeTransformer, et. al.), this becomes truly important. In Cocoon 2.1
there is an IntrospectionTransformer that will apply a transformer based on
namespace.
> Ciao.
Ciao.
S/MIME Cryptographic Signature
