My first thought while reading this was that I'm really unsure if we need such limitations. Honestly, I don't know. What happens if we "forget" something in this mission statement?
And if we really need this, at least a category for tools is missing. Carsten Steven Noels wrote: > > Howdie, > > when establishing the Cocoon TLP with the ASF board, we received the > comment that the then-submitted mission statement of the Cocoon TLP was > self-referencing or recursive, i.e. the Cocoon TLP had as a goal the > prosperity of the Cocoon project, with "Cocoon" not being properly > defined as a tangible goal on its own. So if the Cocoon community would > decide now to start developing a J2EE container (godforbid), we would > be allowed to by our mission statement. > > I'd like to submit a better mission statement for the upcoming board > meeting, keeping in mind future subprojects like Lenya and Forrest (or > blocks being spun off as subprojects such as the portal). Looking at > what differentiates us from other technologies and frameworks, I feel > we should include notions as: > > - Java-based (or do we want our mission statement to be > technology-neutral?) > - XML/SAX-based pipelines > - the sitemap as a centralized request handling configuration mechanism > through decoupling of URI space with request response construction > - different runtime environments (Servlet/CLI/Portlet) > - technical frameworks such as continuation-based flow control, form > handling, templating transformers > - functional frameworks such as the portal, linotype > - applications based on top of all this such as Lenya & Forrest > > I'll try to wordsmith this into a short mission statement, but I'd like > to hear whether this categorization makes sense to you. > > Cheers, >
