forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <>
Subject Re: Docbook as forrest-plugin
Date Mon, 25 Oct 2004 07:06:20 GMT
On Monday 25 October 2004 04:11, Ross Gardler wrote:
> How would Forrest be able to skin these files if it does not conform to
> the internal structure of Forrest. All we could do would be to embed the
> output XHTML, we would lose all skinning features. Since the whole point
> of Forrest is to produce consistent output from various input formats
> wouldn't this method prevent Forrest from achieving it's goals?

I don't believe so. We need to devise a way to skin any output that originates 
from the transformations provided by another framework.

In some instances, such as Docbook or DITA, there are XSL packages already 
available. At present I see that Forrest tries to develop and maintain its 
own XSL's internally. I agree that in some instances this is required, but I 
think its inefficient to do so when package XSL's already exist. People are 
required to maintain and enhance each XSL. In addition, it takes time to get 
the XSL's to the point where they handle all problems.

As the number of different file formats increases, so does the load to develop 
and maintain in internal XSL's. It seems that instead of building these 
XSL's, we should be enhancing and customizing on the XSL's of other 

A typical forrest XSL for Docbook will therefore be no more than a 
customization layer that does an xsl:import of the Docbook stylesheet and 
customizes it for use by forrest. The output of the transformation should 
always be a standards based format.

The natural choice here is XHTML "-//W3C//DTD XHTML 1.0 Transitional//EN." 
This output can easily be piped into the skinning system. The document DTD 
would be depreciated in favor of XHTML. Seeing that there is already a desire 
to move to XHTML 2.0 this makes sense, and is an almost natural progression 
path for the project.

CSS can do the formatting under forrest skinned site, as it does today. Again, 
most projects already have CSS, so it's just a case of "cascading" to include 
the framework specific CSS for formatting of the body. A forrest plugin would 
therefore extended forrest core to provide the configurations and 
customizations required in order that output from a base framework may be 
piped into forrest.

When XSL's don't exist for the base frameworks the plugin will provide XSL's. 

Does anyone think this can work?

Sean Wheller
Technical Author

View raw message