Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 95583 invoked from network); 29 Mar 2004 14:48:18 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 29 Mar 2004 14:48:18 -0000 Received: (qmail 49962 invoked by uid 500); 29 Mar 2004 14:48:09 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 49912 invoked by uid 500); 29 Mar 2004 14:48:09 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 49877 invoked from network); 29 Mar 2004 14:48:08 -0000 Received: from unknown (HELO confixx.bestiole.ch) (66.111.0.243) by daedalus.apache.org with SMTP; 29 Mar 2004 14:48:08 -0000 Received: from [192.168.0.166] (michel.wod.ch [62.220.137.25]) by confixx.bestiole.ch (8.11.6/8.11.6) with ESMTP id i2TEm3P16382 for ; Mon, 29 Mar 2004 16:48:05 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: <518C4D5A-7E64-11D8-B430-000A95AF004E@codeconsult.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <116807A3-8190-11D8-B3E1-000A95AF004E@codeconsult.ch> Content-Transfer-Encoding: quoted-printable From: Bertrand Delacretaz Subject: Re: What can I do? Date: Mon, 29 Mar 2004 16:47:57 +0200 To: dev@cocoon.apache.org X-Mailer: Apple Mail (2.613) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Le 29 mars 04, =E0 16:32, Brian McCallister a =E9crit : > On Mar 25, 2004, at 8:57 AM, Bertrand Delacretaz wrote: > >> >> I don't know what kind of energy and time you have, but If you feel=20= >> like creating a better infrastructure for our docs it'd sure be=20 >> welcome. Many great ideas have been floating around but it's still=20 >> stuck at the ideas stage at the moment. >> > > Well... the docs have good content, and good formatting, and these are=20= > well seperated, but navigating and finding things is tough... Same feelings here. > Probably the hierarchy and flow of the documentation needs to be=20 > abstracted from the content and look-and-feel. Looking through=20 > documentation can be modeled as navigating a graph of tangentially=20 > related elements, and, as Stefano recently pointed out, RDF models=20 > graphs. I think even a simple dynamic navigation system based on keywords=20 ("sitemap" "generators" "FileGenerator" etc) and document types=20 ("reference" "tutorial" etc) would be much better than what we have=20 now. > Maybe we need a system for handling arbitrary RDF based element graphs=20= > and building navigational constructs based on the mappings. The=20 > constructs could be output to XML and formatted somehow into a=20 > navigable structure (maybe transformed into Perl and presented as a=20 > windows-help style app). Doing this in a performant manner may require=20= > static compilation, but I suspect an optimized system allowing dynamic=20= > compilation of the data can be done -- possibly using a Flower Pot=20 > metaphor for the design. But the question is: who will water the flowers then ;-) > ...If only there were a good tool around designed to abstract the=20 > content, look and feel, and user interface elements of=20 > documentation.... Hmm..I might be able to help in selecting a tool...but, similar to the=20= Flower Pot problem, the question is: who is going to work the tool ;-) > -Brian (with tongue firmly in cheek) - Bertrand (similar mood in the second half)