Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 99832 invoked by uid 500); 17 Jun 2003 05:03:04 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 99819 invoked from network); 17 Jun 2003 05:03:04 -0000 Received: from fw.otego.com (HELO limbo.otego.com) (195.216.81.146) by daedalus.apache.org with SMTP; 17 Jun 2003 05:03:04 -0000 Received: (qmail 20812 invoked from network); 17 Jun 2003 05:03:12 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 17 Jun 2003 05:03:12 -0000 Date: Tue, 17 Jun 2003 07:03:12 +0200 (CEST) From: Giacomo Pati Sender: giacomo@limbo.otego.com To: cocoon-dev@xml.apache.org Subject: Re: [vote] FOM design methodology In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sun, 15 Jun 2003, Stefano Mazzocchi wrote: > There are two possible methodologies I see: > > 1) big to small -> give users all possible freedom and restrict that > freedom once we understand potentially problematic usages. > > 2) small to big -> give users the least possible freedom based on some > required functionality and grow as the users express their needs. > > The actual FOM design reflects methodology #1. > > The FOM design that was proposed by myself and Ricardo follows > methodology #2. > > Now, the vote I ask is: > > which methodology would you like to be applied? #1 -0 #2 +1! Giacomo