On Tue, 21 Aug 2001, Ovidiu Predescu wrote:
> On Mon, 20 Aug 2001 Berin Loritsch <[EMAIL PROTECTED]> 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 ... http://faqomatic.sourceforge.net/
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
> http://www.php.net/manual/en/functions.php). 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 xml.apache.org, 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 <[EMAIL PROTECTED]>
> http://orion.nsr.hp.com/ (inside HP's firewall only)
> http://sourceforge.net/users/ovidiu/ (my SourceForge page)
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
