cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [Docs] General Planning
Date Tue, 21 Aug 2001 09:19:33 GMT
On Tue, 21 Aug 2001, Ovidiu Predescu wrote:
> On Mon, 20 Aug 2001 Berin Loritsch <> wrote:
> > [ snip ]
> >
> > There should be 4 FAQ documents:
> > 
> > 1) cocoon2/faq.html  Questions about Cocoon in general (what is it? why
> >                      was it built? etc).
> > 
> > 2) cocoon2/installing/faq.html  Questions about installing and configuring
> >                                 Cocoon (XYZ doesn't work, what should I do?)
> > 
> > 3) cocoon2/userdocs/faq.html  Questions about how to do something in Cocoon
> >                               (I need to serialize XML from a database, how?)
> > 
> > 4) cocoon2/developing/faq.html  Questions about maintaining Cocoon
> >                                 (I've spotted a bug and have a fix, how do I
> >                                  get it committed?  Why is XYZ ThreadSafe?)

I am afraid that even that arrangement will turn into
clumsy monster FAQ documents which are slow to render
by the client. My proposal on a separate thread, to split
the current giant FAQ into topic documents, was only
meant as a stop-gap solution.

The general proposal from Ovidiu below to use a Web-based
FAQ tool is far better. The best that i have seen is
FAQ-O-Matic ...
It has a real nice interface, immensely configurable.
Its most important feature is that it is collaborative
(both on input and on content management). It is a
stand-alone CGI-based application (in Perl i think).

Whichever solution is chosen, we need to be sure that we
can export the content in a structured way to take to a
future Cocoon-based application.
cheers, David Crossley

Ovidiu Predescu continued:
> Should we try to use one of the Web FAQ tools out there? I especially
> like the way the PHP documentation is setup (see for example
> It allows external
> contributors, not only commiters to add their own comments to the
> documentation. It's a very powerful and loosely coupled way of
> collaborating, especially on FAQs, and documentation examples.
> Now I know we may not be very interested in having a PHP system
> running on, but it may be something to get us going
> until we develop a Cocoon based system. We should just use the tool
> that does the job, even if it's "not invented here" (TM) ;-).
> I think the current way of managing the FAQ is making it slow for
> updates and makes people think of alternative solutions. Just look at
> the recent thread on cocoon-users, "reg c2 documentation HOW DO I", to
> see what I mean. Even a simple process as sending an email with an FAQ
> item to one of the committers for inclusion in the FAQ, may be a
> process too much.
> Greetings,
> -- 
> Ovidiu Predescu <>
> (inside HP's firewall only)
> (my SourceForge page)
> (GNU, Emacs, other stuff)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message