cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <>
Subject Re: [report] xml-site update
Date Tue, 04 Jun 2002 00:32:00 GMT

Just as a reminder, I also agree with Rob's point of view and would like to
better understand why his suggestions are not commonly acceptable.

----- Original Message -----
From: "Robert Koberg" <>
To: <>
Sent: Sunday, June 02, 2002 2:47 AM
Subject: Re: [report] xml-site update

> Hi,
> Steven Noels wrote:
> >Rob,
> >
> >>I don't suppose anybody else could address the issue. Or is Steven the
> >>only one? I believe he was the one who gave the advice to not use
> >>document and include/import. Do others feel that you can/should use
> >>
> >>
> >these?
> >
> >If document() and xsl:import/xsl:include is what you want, i.e. putting
> >everything in one big XSLT transformation (which might be technically
> >possible but hard to maintain),
> >
> It certainly is technically possible (many people already do it this
> way). As for maintenance, I don't understand why you think it is more
> difficult to maintain.
> >instead of using the Cocoon pipeline and
> >aggregation approach, I think it will be hard to find partisans for this
> >on this or Forrest's list.
> >
> I really want to understand why it is better to use pipelines and
> (sitemap) aggregation in the case of the forrest project.
> Anyway... the actual question(which seems to get ignored...) I have been
> asking was: if not this way then how is a cocoon app (forest in
> particular) supposed to handle things that are commonplace in XSLT.
> For example, the first question was about xsl:import/xsl:include. I
> offered componentized XSLT for forrest - very clean and very easily
> maintained. You are saying it is easier to maintain by aggregating these
> things through the sitemap rather than using a simple <xsl:include
> href="banner.xsl"/>. Why is it easier to maintain with aggregation?
> The second question had to do with using information from the book.xml
> to provide link information (through XPath's document function).
> Currently you hard-code those links. That is hardly something that can
> be considered easily maintainable. How will forrest handle this?
> I wanted to provide help to the project but it is set up in a way that
> is very counterintuitive to me.
> best,
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message