forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Docbook as forrest-plugin
Date Mon, 25 Oct 2004 02:11:09 GMT
Sean Wheller wrote:
> 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 
> extensability.


> 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 
> files.

Yes, that is how I see it too.

> 2. Folder structure for plugins.
> Does a plug-in have to conform to the folder structure used thus far.

Not necessarily, although it would make sense for us to find a good 
structure and stick to it. The one used so far was originally proposed 
as it largely mirrors threat used in Forrest core. However, the only 
thing that cannot change is the location and name of sitemap.xmap. 
Everything else is controlled within the plugins sitemap.xmap file so 
the plugin authors have full control.

> IOW, do 
> the resources actually have to be a part of the forrest distribution?

No, each plugin brings with it its own set of resources. They can reuse 
things that come in Forrest Core, but they should not contribute 
anything to Forrest core. This is in order to prevent clashes between 

> For Docbook I would consider the following:
> forrest/plugins/
> forrest/plugins/catalog.xml
> forrest/plugins/plugins.xml
> forrest/plugins/sitemap.xmap
> forrest/plugins/docbook/docbook.xmap
> forrest/plugins/docbook/catalog.xml
> forrest/plugins/docbook/custom/ (project/user custom layers, schema and xsl)
> forrest/plugins/docbook/custom/fo.xsl
> forrest/plugins/docbook/custom/xhtml.xsl
> forrest/plugins/docbook/dtd/
> forrest/plugins/docbook/dtd/current/ 
> (link to /usr/share/xml/docbook/schema/dtd/4.2)

Links assume that the resource is available in the linked location so 
this is dangerous. In addition Links don't work on Windows. The plugin 
should provide all resources it requires.

> forrest/plugins/docbook/xsl/
> forrest/plugins/docbook/xsl/fo/current/ 
> forrest/plugins/docbook/xsl/xhtml/current/ 
> (link to /usr/share/xml/docbook/stylesheet/nwalsh/1.64.1)

Same problem with links above.

What is your reasoning for using this directory layout rather than the 
one currently adopted. Unless there is a good reason it would make much 
more sense to stick to the same format as all the other plugins, and 
Forrest core itself - it will be less confusing for developers dropping 
in on the code.

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

If something is released under a compatible license we should distribute 
it with the plugin, otherwise you will be breaking the auto-install 
features of the plugin architecture. The idea is that you simply do 
'forrest run' on a site and it all works. If we start introducing 
pre-requisites then we have to start telling users to "download this, 
install that" before they can do any work.

The other problem with requirements like this is that you have to 
accommodate all the different ways things can be installed. The problem 
gets even worse when you think about supporting all the different platforms.

If the stuff you need is not under a compatible license then we need to 
think of an alternative. In this case I think it would be OK to have an 
ANT script download the requirements and install them (with relevant 
license agreements). However, before we do this we will have to check 
with someone who knows the legal situation better than I.

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

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?


View raw message