Rob, > 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?
What is your problem with the sitemap doing the aggregation? I'm not against stylesheet modularization (apart from the obvious cacheing issues), but not for aggregating different content sources into a single rendered 'page'. > 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 agree the current situation is bearily optimal, and I'm trying to commit my solution RSN. > I wanted to provide help to the project but it is set up in a > way that > is very counterintuitive to me. Thanks for trying to help us out, but believe me, many of us have been doing quite sophisticated XSLT in the past (like you are aiming at), and Cocoon has been based on the lessons this difficult course taught us. Decomposing XML transformation into several simple, often parallel processing steps is consider to be a best practice nowadays, there exist even submissions to the W3C formalizing this pipeline definition: http://www.w3.org/TR/xml-pipeline/ HTH, </Steven> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
