Reinhard Pötz wrote:
Vadim Gritsenko wrote:
Reinhard Pötz wrote:
Tim Larson wrote:
...
+1 'cforms' instead of just 'forms'
I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is obvious because it's within the Cocoon CVS.
WDOT?
Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a little chat on IRC and agreed on the following:
Block Title: Cocoon Forms, or Cocoon Forms 1.0 Block Name: cforms Package: org.apache.cocoon.cforms Namespace: http://apache.org/cocoon/forms/definition/1.0
sorry for missing the argumentation on keeping the 'forms' here, or is this a typo?
NS Prefix: fd
and similar for binding and templating I presume? we might question if reordering the sub-domain and version-no is not more natural then:
xmlns:fd=http://apache.org/cocoon/cforms/1.0/definition xmlns:fb=http://apache.org/cocoon/cforms/1.0/binding
wdot?
Title goes to documentation, samples, wiki, etc. Package name "cforms" and block name "cforms" will allow possibility of parallel development of the next generation "Cocoon Forms 2.0" (block name dforms ;-)), when/if it happens. Namespace suggests that Cocoon Forms 1.0 is one and only official forms framework. Namespace prefix "fd" stands for "forms definition".+1 from me!
Do we have a consensus now? Please chime in on IRC (somebody will have to count votes then), or here :-)
Vadim
in prinipal +1 from me too, except for the small questions/clarifications above.
(sorry, didn't get to irc today)
maybe just adding arguments that might not be needed any more:
another argument for having [cforms] from my side was that you could never confuse it with the known english word 'form' that could mean an HTML form, a paper-form, a whatever formalism or whatnot... in discussions on these lists, and thus possibly introducing confusion that can be avoided
what I liked about 'woody' was that it meant what it meant in a not to be confused way (except for those damn aussies of course :-))... probably this very property was extended into a perception of having a '2nd brand within the cocoon brand'
I think cforms can nicely remove 'the brand within brand' feeling for those that find it necessary, stepping into 'forms' would have been killing the unique-naming-property that was the original reason for looking for a name for it in the first place
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
