[OWASP-ESAPI] Naming ESAPI (was "Re: ESAPI for RIA")

[Kevin W. Wall]

Jeff Williams wrote:
<...snip...>
> Shouldn't we call this one Javascript ESAPI, and not RIA?  There are other
> client languages.

I agree. In fact, this is a bit off the 'ESAPI for RIA' topic (hence switching
Subject header), but I'd like to propose something of a convention for the
names we give the various flavors of ESAPI.

IMO, it can get confusing and we have not been at all consistent on this
mailing list and my concern is that this sloppiness will carry over to
documentation.

For instance, for the Java implementation of ESAPI, I've seen all of the
following at various times:

	ESAPI Java 2.0		and	ESAPI Java 1.4
	ESAPI for Java EE	and	ESAPI JavaEE
	ESAPI 2.0		and	ESAPI 1.4
	Java ESAPI	and	Java ESAPI 1.4	   and	  Java ESAPI 2.0
	etc.

I am proposing that when we refer to a specific implementation _version_,
we use the convention of:

	<prog_language> ESAPI <version>

and if no version is implied,
	<prog_language> ESAPI

where <prog_language> is the programming language or environment that
it is intended to primarily be used in and not necessarily the implementation
language (though generally they are the same).

So, for example, we would have

	Java ESAPI 2.0, Java ESAPI 1.4, Java ESAPI
	.NET ESAPI 1.0, .NET ESAPI
	PHP ESAPI, Haskel ESAPI, JavaScript ESAPI

(Don't even think about calling it ECMAScript ESAPI. ;-)

The reason that I prefer this versus the more common style of

	ESAPI <prog_lang> <version>

is because their can be confusion as to whether or not <version>
refers to the ESAPI version or the programing language version.
(E.g., consider 'ESAPI Java 1.4' or the hypothetical 'ESAPI PHP 5.2'
or 'ESAPI Python 2.6'.)

I think this will cause less confusion to those new to ESAPI. I've already
faced this issue with Java ESAPI for those at my workplace.

Thoughts?
-kevin
-- 
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME