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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
