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]