On Thursday, June 13, 2002, at 08:06  AM, Steven Noels wrote:

> we would be able to host this.

Great news, Steven.

> this seems however like a core documentation effort. Could you please 
> synchronize your efforts with Diana's and Forrest's? The last thing we 
> want to happen is the documentation effort being fragmented.

If we work separately: fragmentation and diminished overall value to 
users.
If we work together: the sum is greater than the parts, i.e. value-added 
for users.

My hopes:

1. That wiki results (from any wiki effort, not just a dictionary one) 
can be harvested, edited, and incorporated into core Cocoon docs on a 
periodic basis. This helps the user experience by saving time (when they 
lack time to navigate though wiki-like stream-of-consciousness posts, 
just to find a definition.) It also facilitates i18n efforts. In other 
words, I want the effort to be owned by the community, in the fullest 
sense, so it can be used for other documentation/learning tool needs, 
without restriction.

2. That developers provide some feedback. I too am seeing a lot of 
confusing issues over descriptions of components behavior within 
existing docs. I think this is due, in part, to the Java object model 
not always having direct analogies to the user experience (which may not 
include examining the code for answers).

One example (there are many others like this):
1. Quote: 
http://xml.apache.org/cocoon/userdocs/generators/extractor-generator.html
FragmentExtractor is a transformer-generator pair which is designed to 
allow sitemap managers to extract certain nodes from a SAX stream and 
move them into a separate pipeline. The main use for  this is to extract 
inline SVG images and serve them up through a separate pipeline, usually 
serializing them to PNG or JPEG format first.

Questions a new user may ask:
Sitemap manager: Is this a person or a Cocoon component?
Separate pipeline: Where/what is this "separate" pipeline? But what if I 
have only one pipeline declared in my sitemap?

3. That we implement, when possible, an XML-based 
approach/implementation of wiki, to facilitate integration with Forrest 
documentation architecture.

-- Diana





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to