cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuart.roeb...@adolos.co.uk>
Subject Re: [C2][Important] Content aggregation again. Resolution needed.
Date Mon, 22 Jan 2001 10:23:40 GMT
Aggregation is something that I would value a lot in the kind of real-life work I'm doing with
Cocoon 2 at the moment.  So I'll add my thoughts...

On Sunday, January 21, 2001, at 10:28 PM, Paul Russell wrote:

> * Ross Burton (ross.burton@mail.com) wrote : 
> > Paul Russell wrote: 
> >  
> > > There have been a few posts about content aggregation, most of which 
> > > point to previous discussion on the subject. We need to actually 
> > > *discuss* the implementation of this and make sure we get it right. 
> > > Origionally, Stefano's proposal was to use URLs to refer to the items to 
> > > aggregate, but I am not sure this is the best way to go, as in my 
> > > opinion it makes things complicated to administer and set up. 
> > URLs are a bad idea IMHO, unless they all use a custom protocol cocoon: 
> > which hooks directly into the sitemap again. These cocoon: URLs should 
> > access either defined pipelines, or resources. 
>  
> My feelings exactly. I don't like 'hacking' the Java URL infrastructure 
> either, if I can avoid it. I'm not sure how useful using named pipelines 
> is going to be -- suspect we'll only know when we start using 
> aggregation in earnest. 

As I understand it, what is being proposed is that aggregation allows various XML documents
to be combined.  Each input document would be placed within a named element in the output
XML document.  Thus...

Taking the documents:

input1.xml:
	<?xml version="1.0"?>
	<name>
		Fred Bloggs
	</name>

input2.xml:
	<?xml version="1.0"?>
	<country>
		Japan
	</country>

And the sitemap section:

    <map:match pattern="combined.xml">
     <map:aggregate>
      <map:part name="part1">
       <map:generate src="input1.xml" />
      </map:part>
      <map:part name="part2">
       <map:generate src="input2.xml" />
      </map:part>
     </map:aggregate>
     <map:serialize type="xml" />
    </map:match>

Would give:

	<?xml version="1.0"?>
	<aggregation>
	 <part1>
	  <name>
	   Fred Bloggs
	  </name>
	 </part1>
	 <part2>
	  <country>
	   Japan
	  </country>
	 </part2>
	</aggregation>

Or something to that effect.


The discussion about URLs is, as I understand it, about how the aggregation mechanism accesses
XML which has been generated directly from the sitemap.  If I understand this correctly, this
question isn't unique to the aggregation concept, because there could be good reasons (I have
them every day!) why one would wish to access XML generated from the sitemap without aggregating
it with other content before processing.  e.g.

If you have a bit of sitemap like the following:

    <map:match pattern="result1.xml">
		<map:generate src="input.xml" />
		<map:translate src="stylesheet1.xslt" />
		<map:translate src="stylesheet2.xslt" />
		<map:translate src="stylesheet3.xslt" />
		<map:translate src="stylesheet4.xslt" />
		<map:translate src="stylesheetX.xslt" />
     	<map:serialize type="xml" />
    </map:match>

    <map:match pattern="result2.xml">
		<map:generate src="input.xml" />
		<map:translate src="stylesheet1.xslt" />
		<map:translate src="stylesheet2.xslt" />
		<map:translate src="stylesheet3.xslt" />
		<map:translate src="stylesheet4.xslt" />
		<map:translate src="stylesheetY.xslt" />
     	<map:serialize type="xml" />
    </map:match>

It would be great if you could do:

    <map:match pattern="result.xml">
		<map:generate src="input.xml" />
		<map:translate src="stylesheet1.xslt" />
		<map:translate src="stylesheet2.xslt" />
		<map:translate src="stylesheet3.xslt" />
		<map:translate src="stylesheet4.xslt" />
     	<map:serialize type="xml" />
    </map:match>

    <map:match pattern="result1.xml">
		<map:generate src="sitemap:result.xml" />
		<map:translate src="stylesheetX.xslt" />
     	<map:serialize type="xml" />
    </map:match>

    <map:match pattern="result2.xml">
		<map:generate src="sitemap:result.xml" />
		<map:translate src="stylesheetY.xslt" />
     	<map:serialize type="xml" />
    </map:match>

(You'll probably tell me that this is already possible - if so, my apologies!)

This kind of mechanism, seems to me, to help to provide the basis on which to cache and speed
up duplicate processing, as well as making the sitemap more easily maintainable.


Finally, what has been proposed, appears to be adding in the facility to have submatches within
a match.  This, again, doesn't appear to be uniquely useful in aggregation.  It is a kind
of 'case' statement facility which allows for optional processing (or in this case optional
generation) within a match.  (Apologies again if I'm behind things here, because I'm not aware
that this kind of facility is currently available in Cocoon 2).

If I understand this correctly, this could also be implemented separate from aggregation,
and provided where it might be useful, e.g.:

    <map:match pattern="page*.xml">
		<map:generate src="input{1}.xml" />
		<map:translate src="stylesheet1.xslt" />
		<map:translate src="stylesheet2.xslt" />
		<map:translate src="stylesheet3.xslt" />
		<map:match pattern="page_one.xml">
			<map:translate src="stylesheet_pageone.xslt" />
		</map:match>
		<map:translate src="stylesheet4.xslt" />
     	<map:serialize />
    </map:match>

I don't think I've said anything new hear, but hopefully it will help to raise issues or clarify
things for folk (including myself!).

Stuart.




-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                             http://www.adolos.com/
Mime
View raw message