forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: describe Forrest in 50 words
Date Wed, 27 Apr 2005 07:31:02 GMT
Ferdinand Soethe wrote:
> David Crossley wrote:
> DC> I think that it confuses people. Forrest can have multiple
> DC> source input formats, so this description conflicts with that.
> I changed that back an forth a couple of times and finally took
> 'formats' out. Not just because the repetition sounds bad, but mostly
> because to me 'input formats' suggests file of different formats
> (whereas I wanted to broaden the meaning to all input including
> databases, streams etc.)
> DC> I had never heard of the term, so i had to Google.
> DC> The results did not help to allay my concern.
> Yes, this may be an important issue since we also address a lot of
> programmers looking for documentation. How about spending an extra
> word on
> 'Apache Forrest is a standards-based framework for documentation and
> Single Source Publishing'

Let me try to say it another way: I am very unhappy with
this term "Single Source Publishing". Forrest does not
restrict people to a single source. I can devise a
sitemap that gets various input from many different
sources and aggregates it. That is not "single source".

> DC> This term "unified output" has lost the intention
> DC> of what Ross suggested earlier in this thread.
> DC> So if we are not using the original meaning then
> DC> i think that we should dump it.
> I wouldn't drop it because I consider the unifying function is one of
> the most important features for both documentation and SSP. I figured
> I could cut it short because this won't be self-explanatory for people anyway.
> Looking up the original text
> RG> "Thus Forrest can present a unified document structure and design at the
> RG>   output stage regardless of the chosen input formats."
> Not sure the meaning gets lost, but we can always write something like
> 'Apache Forrest is a standards-based framework for documentation and
> Single Source Publishing, transforming different input to a unified
> document structure and design at the output stage'

That is getting back to the original idea, except for
the single source bit.

> DC> Do we really need to mention a limited list of output formats?
> I definitely would because these are the foundation for most
> publishing tasks. So here extensibility is nice, but the fact that we
> do HTML and PDF out of the box will be more important for perhaps 90%
> of the users. Or am I missing something?

The limited nature of the list. Many products can output HTML
and PDF. It seems to limit the idea of multiple outputs.
Also, tacking the words HTML and PDF onto the end of
"unified output" doesn't seem to work. HTML is a mess, not unified.

Anyway, i am not going to fight that one if people want
to mention specific outputs. My main gripe is the SSP.


View raw message