Content aggregation and caching

[Giacomo Pati <gi...@apache.org>]

The more I think about content aggregation (always with caching in mind)
the more I think we have to choose a way to do it at the sitemap level.

There has been content aggregation at the transformer stage by xinclude
which, following Stefanos explanations, is hard to cache because a
Transformer which depends on its input isn't predictable for caching
*before* pipeline production takes place.

Another approach was content aggregation at the generator stage which
needs a hole in the sitemap engine to call it recursively and also this
"aggregating generator" needs to go through the caching evaluation
itself separately. And the possibility to recursively call the sitemap
engine from a sitemap component is something I wouldn't give to sitemap
component writers because I think it can be harmful if used the wrong
way.

I've reviewing several old mails mainly the ones from Paul Russel, Berin
Loritsch and Stefano Mazzocchi (see references at the end). I think we
need additional semantics in the sitemap to allow content aggregation
with full caching capabilities without having to do any hacks within
sitemap components and without allowing recursive calls into the sitemap
engine by those components.

Ok, so I will take those several proposals about it and try to formulate
syntax and semantics to hopefully combine the good aspects of them.

  <map:aggregate                element="page"     
ns="http://foo.bar.com/myspace">
    <map:part src="/header"     element="header"   
ns="http://foo.bar.com/heading"/>
    <map:part src="/nav"        element="nav"/>
    <map:part src="body"        element="content"/>
    <map:part src="/news/today" element="news"     
ns="http://foo.bar.com/news"/>
  </map:aggregate">

The <map:aggregate> initializes a aggregation. It can be embedded
wherever you would place a generator. The attribute "element"
(mandatory) tells the aggregator to use that element as the root element
for the aggregation with an optional namespace defined using attribute
"ns".

The <map:part> element collets content from a cocoon URI pointed to by
attribute "src". It is important to have a cocoon URI here which
separately points to the actual resource included. This way you can
include file resources as well as external resources (e.g. http-urls).
You can switch the resource without touching the aggregation declaration
(this comes from a suggestion made by Stefano). Also note that url
starting with a slash will be evaluated through the root sitemap whereas
others by the "current" sitemap to respect the possibly mounted
sub-sitemaps (maybe this might break some SoC). The optional attribute
"element" adds the named element around the included content and the
optional attribute "ns" (which can only be specified if the element
attribute is present) defines its namespace.

Every <map:part> is internally represented by a XMLPipeline object
(mentioned in a previous mail from myself) which is fully embeded in the
caching evaluation process and can itself state if it is cachable as a
hole by ANDing all the cachable states of its pipeline components and at
the end the aggregation itself can state if it is cachable (which I
haven't yet pondered to a solution).

Now, please your comments :)

References:

Paul Russel:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98010605909618&w=4
Berin Loritsch:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98029028728910&w=4
Stefano Mazzocchi:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98276811210569&w=4

Giacomo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org