On Tuesday, July 24, 2001, at 11:25 am, Stefano Mazzocchi wrote:
> 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".
...
The "what is a generator" question you raise is one I was thinking about
the other day.
Wouldn't it be a lot tidier if we decided that anything that takes an XML
input and transforms it in some way to create an XML output should be a
transformer and that Generators should simply be means of obtaining raw
input in a suitable form for processing.
This means that the ServerPagesGenerator would be a Transformer taking XSP
as input (from a Generator).
> 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
I'm comfortable that this access to the root sitemap is valuable. The
root provides a mechanism for handling 'global' or 'common' elements of a
site independent of the location of subsitemaps.
Stuart.
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
