[I18n-sig] naming codecs

Tamito KAJIYAMA kajiyama@grad.sccs.chukyo-u.ac.jp
Wed, 6 Dec 2000 20:42:44 +0900


Thank you for the quick reply.

M.-A. Lemburg wrote:
|
| > I consider releasing a version of the JapaneseCodecs package
| > that will include a new codec for a variant of ISO-2022-JP.  The
| > codec is almost the same as the ISO-2022-JP codec, but it can
| > encode and decode Halfwidth Katakana (U+FF61 to U+FF9F) which
| > can not be encoded with ISO-2022-JP as defined in RFC1468.
| > 
| > I believe there is a demand for the codec, but I have no idea
| > on the name of the codec.  I'd like to give it a name that is
| > different from all standard encoding names, since the encoding
| > for which the codec works is not defined as a standard
| > (e.g. RFCs).  I'd also like to avoid an encoding name that is
| > likely to be used as a standard encoding name in the future.
| > 
| > Does anyone have a good name for the codec?  Or, how may I think
| > about the naming of a codec?  Any suggestions are welcome.
| 
| Why not simply append another "-<variant>" part to the name,
| e.g. "iso-2022-jp-hw" or "iso-2022-jp-extended" ?

I like "iso-2022-jp-extended", but I wonder if this naming
convention may be used.  There are the standard encoding names
ISO-2022-JP-1 and ISO-2022-JP-2 in addition to ISO-2022-JP, and
also there are ISO-2022-CN and ISO-2022-CN-EXT.  So, a simple
"-variant" part is likely to conflict with a standard encoding
name in the future.  However, an abbreviated and/or tricky
"-variant" part such as "-hw" is not user-friendly.

I also wonder if I am thinking too much...

-- 
KAJIYAMA, Tamito <kajiyama@grad.sccs.chukyo-u.ac.jp>