forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <>
Subject Docbook as forrest-plugin
Date Sun, 24 Oct 2004 18:43:28 GMT

I've been researching the new plug-in architecture and have some questions. 
Perhaps the team can give me some direction.

1. Seems from the mail archive that the general decision is to move all 
"frameworks" out under the "plug-in" architecture. If this is so, then the 
"plug-in" functionality becomes a core component of forrest NOT a sub-project 
I am in favor of this approach because it dramatically improves 

2. Plug-in or framework? Seems that forrest now has a plug-in architecture 
into which frameworks can be plugged. Is the framework to be considered a 
plug-in. How does Docbook or TEI suddenly become a plug-in? It's a framework 
that is plugged into the forrest plug-in interface. IMO, the plugin for 
Docbook should do no more than to specify the locations of Docbook schema, 
stylesheets, and user Docbook customization layers through configuration 

2. Folder structure for plugins.
Does a plug-in have to conform to the folder structure used thus far. IOW, do 
the resources actually have to be a part of the forrest distribution?
For Docbook I would consider the following:


forrest/plugins/docbook/custom/ (project/user custom layers, schema and xsl)

(link to /usr/share/xml/docbook/schema/dtd/4.2)

(link to /usr/share/xml/docbook/stylesheet/nwalsh/1.64.1)

I figure that since, Docbook will be a framework under the "plug-in," that a 
prerequisite to installing the Docbook "plug-in" is that the DTD and XSL's 
are installed. This dramatically reduces "swelling" and makes the "plug-in" 
easy to install and maintain. All development to Docbook is with the Docbook 
community and not on forrest resources.

However, these means being able to support the Docbook processing models. My 
approach would also be to avoid transformation to any intermediate forrest 
format. Let Docbook do the bit it was designed for. Let forrest just take the 
input and integrate the content into the rendered project. For example 
implimentation of XHTML1.0 now will automatically enable XHTML2.0 when the 
Docbook stylesheets implement it. Forrest has no need to be concerned with 
Docbook XHTML2.0.

The site.xml and tabs.xml can be generated using the current method or the 
IMSmanifest method. Tough I am still not sure how to get forrest to add/wrap 
its own adorning features.

I know this is rough, but ideas I need.
Sean Wheller
Technical Author

View raw message