Return-Path: 
 <cocoon-dev-return-12665-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 27953 invoked by uid 500); 19 Apr 2001 19:59:21 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 27881 invoked from network); 19 Apr 2001 19:59:20 -0000
Date: Thu, 19 Apr 2001 21:43:35 +0200 (CEST)
From: giacomo <giacomo@apache.org>
X-X-Sender: <giacomo@lap1.otego.com>
To: "cocoon-dev@xml.apache.org" <cocoon-dev@xml.apache.org>
Subject: Re: ContentAggregation HOWTO?
In-Reply-To: <3ADF0C8D.8F9C4DAE@apache.org>
Message-ID: <Pine.LNX.4.31.0104192132320.1379-100000@lap1.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N



On Thu, 19 Apr 2001, Berin Loritsch wrote:

> I see we have the first iteration of content aggregation in
> Cocoon CVS, this is excellent.  Since there are no docs, and
> I can't remember far back enough as to what the final verdict
> was, I am guessing as to how it is used, and need feedback
> to see if I got it.
>
>
> In the sitemap, we have a pipeline model set up like this:
>
> <map:match pattern="news/aggregate.xml">
>   <map:aggregate element="page" ns="http://foo.bar.com/myspace">
>     <map:part src="slashdot/slashdot.xml" element="slashdot" ns="http://foo.bar.com/slashdot"/>
>     <map:part src="moreover/moreover.xml" element="moreover" ns="http://foo.bar.com/moreover"/>
>     <map:part src="isyndicate/isyndicate.xml" element="isyndicate" ns="http://foo.bar.com/isyndicate"/>
>   </map:aggregate>
>   <map:transform src="stylesheets/news/news.xsl"/>
>   <map:serialize/>
> </map:match>
>
> By looking at this, it looks like the aggregator generates XML
> something along these lines:
>
> <page xmlns="http://foo.bar.com/myspace">
>   <slashdot xmlns="http://foo.bar.com/slashdot">
>     <!-- results of asking sitemap for "slashdot/slashdot.xml" -->
>   </slashdot>
>   <moreover xmlns="http://foo.bar.com/moreover">
>     <!-- results of asking sitemap for "moreover/moreover.xml" -->
>   </moreover>
>   <isyndicate xmlns="http://foo.bar.com/isyndicate">
>     <!-- results of asking sitemap for "isyndicate/isyndicate.xml" -->
>   </isyndicate>
> </page>
>
> And the result is transformed by "stylesheets/news/news.xsl"
> and we serialize the results as HTML.
>
> I have three questions (beyond am I right?):

You are right :)

> 1) Can we have resources that the end user cannot navigate to,
>    but we can use for aggregation?  IOW can we dynamically create a
>    menu that is only accessible by the aggregator?

Technically no problem but adds needed semantic in the sitemap. There
has been one back when Stefano was writing the Commandline mode. He
needed a way to flag which pipelines (specifically map:match elements)
may not be included into a crawl of the LinkTranslation phase. There has
been many suggestion but no implementation.

> 2) Does the Aggregator strip the root element from the included
>    event pipeline and replace it with the one specified in the
>    sitemap?

Nop. In fact it adds a new root element and puts the aggregatet part of
the content under it.

> 3) Is it possible to do more structured aggregation?
>
> Number three is necessary for XForms processing.  If I want to
> embed the XForm instance data (so I can process the results in XSLT)
> according to the spec, then I need to have a construct like this:
>
> <xform xmlns="http://www.w3.org/2001/02/xforms" id="advertisement">
>   <submitInfo target="update-ad"/>
>   <model>
>     <!-- XForms schema for instance -->
>   </model>
>   <instance model="advertisement" xmlns="http://www.infoplanning.com/advertisment">
>     <ad id="12" disposition="draft">
>       <image>ad/12.gif</image>
>       <description>
>         This is a sample ad.
>       </description>
>     </ad>
>   </instance>
> </xform>
>
> Later in the form, I will refer to this.
>
> Are there any plans to support the more complex aggregations
> where a template is required?

Transparent XInclude. It's in the todo list assigned to Paul Russell. I
dunno if it will be ready for May 1st because we still have not
discussion how such a component (its the still NullSAXConnector
component that should be replaced by a XIncludeSAXConnector IIRC) should
be accessing the internal request methods of the sitemap engine.

The current sitemap based CA approach uses a flat structure.

Giacomo



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