> Glenn, Keld, Ken, Yves, et al,
> I have a question for all of you regarding this terminology debate.
What is the goal
> here? Are you trying to nail down precision in the terms for use in
> The reason I ask this is that I'm trying to understand the goal of the
> have in the past assumed that they are written to explain the
standards to the people
> who need to implement them. Having attempted to read a few, I think
my assumption to
> be incorrect.
I think any document, especially standard specifications, should call
everything by its proper name. Otherwise it leads to misunderstanding
and as an implementer like you Andrea, I see side effects in APIs, and
Take some of the Windows docs on font where they use charset instead of
encoding, ANSI for any non-DOS coded character set, etc. I spent enough
hours doing I18N classes trying to explain to very puzzled programmers
why they should specify ANSI_CHARSET in the lfCharset parameter of a
LOGFONT to use really a Cyrillic font but CHARSET_SHIFTJIS for a
Japanese one. Or explaining to intrigued and somewhat frazzled
colleagues that their Korean "ASCII" file was in fact a "plain text"
file in codepage 949 and that a conversion from ASCII to EUC-ko would
not quite work as well as 949 to EUC-ko.
Microsoft docs are getting better now (at least for that), and my
colleagues are now (usually) calling a cat a cat, but meanwhile I
learned to care about the value of precise terminology. So I really
would like to see the little standard I have the chance to work on use
the right name for that darn charset/codeset/encoding attribute.
In the other hand, and without taking anything away from their useful
help, I think some of the points Ken, Keld, Glenn, John, etc. discuss
are a little above my head :-) but they probably need to be discussed
and this list is probably the right place for that.
Also: I do like your warning about too much precision Andrea. I'll
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:37 EDT