cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <>
Subject RE: [report] xml-site update
Date Sun, 02 Jun 2002 09:10:31 GMT

> 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:



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

View raw message