From rob@koberg.com Thu Apr 18 21:14:15 2002 Return-Path: Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list forrest-dev@xml.apache.org Received: (qmail 24534 invoked from network); 18 Apr 2002 21:14:15 -0000 Received: from adsl-64-173-57-75.dsl.snfc21.pacbell.net (HELO mail.koberg.com) (64.173.57.75) by daedalus.apache.org with SMTP; 18 Apr 2002 21:14:15 -0000 Received: from koberg.com ([192.168.1.1]) by mail.koberg.com (8.11.2/8.11.2) with ESMTP id g3ILGEx19863 for ; Thu, 18 Apr 2002 14:16:14 -0700 Message-ID: <3CBF3787.8090506@koberg.com> Date: Thu, 18 Apr 2002 14:15:51 -0700 From: Robert Koberg User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9) Gecko/20020310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forrest-dev@xml.apache.org Subject: Re: entry points [was:Re: Ok, I give up] References: <500D5D20-530A-11D6-89D1-0030653FE818@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Diana Shannon wrote: > Robert: > >> How about defining different entry points to cocoon. Example tracks: >> 1. total newbie - very basic stuff to get them started >> 2. experienced web developer but inexperienced at java or XSLT >> 3. experienced web developer with java but inexperienced with XSLT >> 4. inexperienced (serious) web developer that knows XSLT well >> 5. ??? > > > Very good idea. We could develop audience profiles for these groups > that include assumptions about concepts most likely to need > reinforcement, based on pre-Cocoon preconceptions. This stuff pops up > all the time on the user list, like folks wanting to override a > serialization configuration from a stylesheet's xml:output method. > >> Everybody seems to be coming from cocoon at different angles. Define >> what is common to all and then split out to the entry points. > > > Couldn't agree with you more. However, Cocoon as "glue technology" has > an extremely varied potential user base. Yes, that was what I was trying to address. > Also, think about how many flavors of experienced web developer types > there are. I'm not saying it shouldn't/couldn't be done, but the > audience comes with a lot of potential "baggage." I would keep #2 as generic as possible. Over time, the users can fill in the bulk of the specifics for a particular way in. I personally fã,ëª this level of involvement would need a hierarchical organization of contributors - not common ownership... hence some type of user management. But that could be put off well into the future, I guess, until there is a solid system in place. > > >> For something like #4, speaking from experience, I would like to see >> how you take an app that uses the XSLT/XPath document function to >> aggregate content and turn that into a cocoon app that aggregates >> content before the final transformation. I could provide the >> XSLT/XML that aggregates content in the final transform using >> document(), but I would not trust myself to give the best cocoon >> conversion :( > > > So how does that translate, ideally, into documents that fill up a > learning path? Is this a tutorial directed specifically at audience > #4? Or a combination of documents? If so, what types of documents? I tried to use that as an example of - "here's how you do it with XYZ technology" - "and here is how we would optimize it for/with cocoon." I guess it would be a tutorial/philosophy thing. Perhaps there is a page - "What do you want to do with Cocoon?" That page is set up to look like a well organized FAQ that strings the user out to something that they recognize. The path explores how they would normally do things and compares that to how it should be done in cocoon (always linking to more details). After they get exposed to cocoon in a light that allows them to see, the path takes them into the common cocoon learning/docs. That path brings them to the central idea of cocoon with respect to their needs. best, -Rob