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 12:54:11 GMT
Sean Wheller wrote:
> On Monday 25 October 2004 11:43, Nicola Ken Barozzi wrote:

>>>>>2. IMO plug-in is an object that adds a content type class,
>>>>>configuration, and resources to forrest. I would actually change the
>>>>>directory name from plugins to frameworks.
>>>>-1 It simply does not make sense. A framework is something used to build
>>>>upon (IOW white box), while a plugin is the exact opposite.
>>>Yes, and build upon it we do.
>>No we don't. We *use* it, not build upon it. *We* drive DocBook, not the
>>other way around. I think you don't understand how the word 'framework'
>>is commonly used in our context.
> I'm suggesting that the perception may need to change when one considers the 
> plug-in architecture. 

I'm having difficulty understanding the change you are proposing, see below:

> 1. I would envisage that everything that defines a markup vocab and 
> transformation will move out of forrest back to their own realms.

If this does not break the skinning capabilities of Forrest then this is 
great. But remember skinning is more than creating a meaningful XHTML 
display. I want all the other output formats too.

> 2. I would advocate that forrest not have an internal XML format for content 
> storage. Let somebody else do that.

There are good reasons for Forrest using an internal format, but it is 
not advocated as the source format, it is only an *option* for source 

Viewing it as an internal (intermediate format) we need it to enable the 
multiple output formats we want Forrest to generate. Imagine input 
format a and b, and output formats 1 and 2. Without an intermediate 
format we have multiple output stylesheets (O):

A -> O1 -> 1
A -> O2 -> 2
B -> O3 -> 1
B -> O4 -> 2
C -> O5 -> 1
C -> O6 -> 2

= Six stylesheets

With an intermediate format (X) we have less stylesheets to maintain:

A -> I1 -> X -> O1 -> 1
A -> I1 -> X -> O2 -> 2
B -> I2 -> X -> O1 -> 1
B -> I2 -> X -> O2 -> 1
C -> I3 -> X -> O1 -> 1
C -> I3 -> X -> O2 -> 1

= 5 Stylesheets

Now try adding an extra output format:

With no intermediate this would require 3 more styles sheets (one for 
each input format), with an intermediate we need 1 more stylesheets (for 
the output side).

Now add another new output:

No intermediate requires 3 stylesheets (one for each input format), with 
an intermediate we still only need one styles sheet (to convert from the 

If we now add an input format we need 4 stylesheets (one for each output 
format) if we do not use an intermediate. With an intermediate we only 
need one stylesheets (for the input -> intermediate)

and so on...

Forrest needs an intermediate format, it does not need to be 
Document2.0, which is why we are moving towards a subset of XHTML2, but 
it does need an intermediate. No-one is forcing the user to write their 
docs in that format. We do here in Forrest because we happen to like it, 
but some of our staff here use - you use Docbook etc.

> 3. Let the user decide on which format they want to store information.

This is what we are doing. See above.

> 4. Let forrest know how to use this content class through the plug-in 
> architecture, and plug-in adaptor.

Yes, this is the direction we are going (and thank you for your help 
with a Docbook plugin)

> 5. Concentrate on forrests ability to take XHTML output from a plug-in, skin 
> it and make it accessible.

This assumes that all XHTML is equal. See below for an example of why 
taking raw XHTML simply does not work in some cases.

> IMHO, this make forrest far more powerful. The power of forrest should be in 
> being able to read an XHTML string, skin it using powerful skins and 
> displaying information. As you say KISS.

There are good reasons why we will not be supporting the full XHTML2 
specification. These have been discussed at length in the past and are 
available in the archives, linked to in previous mails for you and also 
linked to in the issue tracker.

That being said, if you can make the Docbook system work using the 
XHTML2 output from the Docbook XSLT sheets then that is what should 
happen within the Docbook plugin. One of the main advantages of the 
plugin system is that it enables us to use the best technique for each 
individual format. For example, in the OOo plugin there is now support 
for Impress files. I tried to do the same thing with Powerpoint by 
exporting HTML, but it is extremely difficult because of the way they 
use styles to format the slide. XHTML allows styles to be overridden 
thus preventing our skinning system from working. Stripping the output 
of all style information also fails as the source data is not in the 
same logical order as it's display data (they use CSS positioning to put 
it back in the right order).

Plugins are intended to allow the best solution for each source format - 
see your points 3 and 4.


View raw message