cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Foster <jafos...@uwaterloo.ca>
Subject ToC, SoC, and Views
Date Sat, 05 Jan 2002 16:16:51 GMT
With respect to the new outline for documentation I would like to suggest 
that we leverage the concept of "views" and present the same content in 
different ways for different audiences.  As I see it, there are 5 audiences 
for the documentation.

Four of these (Manager, Logician, Author?, Stylist) are described by the 
"pyramid model of web contracts" which, assuming that we have remained true 
to this vision, are still the backbone of the Cocoon concept of web 
publishing.(*)  The fifth audience are the multi-talented individuals, who 
I imagine actually make up most of the Cocoon adopters at this point, who 
are trying to introduce a Cocoon-based solution and are doing everything 
themselves.

The new ToC currently in CVS feels very "O'Reilly-ish", and in my opinion 
is oriented at the multi-talented audience, possibly focusing on the 
Manager and the Logician.

On the list the term "SoC" keeps being raised either in support or in 
rebuttal of a proposal.  One thing that rarely seems to happen is the 
identification and elaboration of these Concerns.

<grumble>It's all well and good to say "Nope, SoC makes this a bad idea", 
but it would be nice to know what concerns are being overlapped and why the 
concern exists at all.  Some heuristics that say "For X, think like a 
manager.  For Y and Z, think like a  consumer..." would at times make 
things a lot clearer.</grumble>

Given the importance of SoC, I think the Cocoon documentation should 
reflect the different Concerns that form the basis of Cocoon.  Using views 
and hyperlinking it should be possible to use the same, or very similar, 
source materials and arrange them appropriately.

Hopefully this didn't come across too negatively.  That wasn't the intent.
   It's just that sometimes things seem to focus so much on low-level issues 
that I start to wonder if Cocoon still has an overall vision that is being 
shared collectively.  Now that Cocoon2 has been released, isn't it time to 
focus a little on how to use it?  Thus far the focus is on how to construct 
a SiteMap and while the SiteMap is important, I'm left to wonder if it has 
completely supplanted the original Cocoon vision.

Jason Foster

(*) The Cocoon documentation states:

> The model that Cocoon adopts is the "pyramid model of web contracts" which 
> is outlined in the picture below and is composed by four different working 
> contexts (the rectangles)
>
> *	Management - The people that decide what the site should contain, how 
> it should behave and how it should appear
> *	Content - The people responsible for writing, owning and managing the 
> site content. This context may contain several sub-contexts - one for each 
> language used to express page content.
> *	Logic - The people responsible for integration with dynamic content 
> generation technologies and database systems.
> *	Style - The people responsible for information presentation, look & 
> feel, site graphics and its maintenance.
>
> and five contracts (the lines)
>
> *	management - content
> *	management - logic
> *	management - style
> *	content - logic
> *	content - style
>
> Note that there is no logic - style contract. Cocoon aims to provide both 
> software and guidelines to allow you to remove such a contract.

If I approach this model from the perspective of someone new to web 
publishing (eg. I used to do all of my web pages in DreamWeaver and host on 
GeoCity.) the current documentation and discussion does not make at all 
clear what the contracts actually mean, what the guidelines for removing 
the logic-style contract are, and in general how Cocoon *thinks*.  In my 
opinion this is what is needed, now that I can download Tomcat and Cocoon 
and be ready to go in 10 minutes!  While the examples that come with Cocoon 
show you *how* to do certain things, they don't go into the *why* much at 
all.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message