Subject: SC 22 N 3243 - Late Comments Received from Sweden on SC 22 N 3204

From: Matthew Deane <[email-masked]>
Date: Fri, 1 Jun 2001 11:11:28 -0400

ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)
 
ISO/IEC JTC 1/SC22 N 3243
 
TITLE:
Late Comments Received from Sweden on SC 22 N 3204, FCD Ballot on FCD 1989,
Information
Technology - Programming Languages - Cobol

DATE ASSIGNED:
2001-06-01
 
SOURCE:
National Body of Sweden

BACKWARD POINTER:
N/A
 
DOCUMENT TYPE:
National Body Contribution

PROJECT NUMBER:
22.01.07
 
STATUS:
These comments on SC 22 N 3204 were received from O-member Sweden after the
summary of voting (SC 22 N 3239) was issued.  They are circulated to SC 22
members for information and SC 22/WG 4 is asked to review them along with
the other comments contained in N3239.
 
ACTION IDENTIFIER:
ACT
 
DUE DATE:
  
DISTRIBUTION:
Text

CROSS REFERENCE:
SC 22 N3239

DISTRIBUTION FORM:
Def
 
Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
Matt Deane
ANSI
25 West 43rd Street
New York, NY  10036
Telephone:  (212) 642-4992
Fax:             (212) 840-2298
Email:  [email-masked]

_________end of cover page, beginning of comments___________________________

Comments on FCD 1989 (COBOL), accompanying a NEGATIVE Swedish vote.

1. clause 2: Normative references:

	1.a. There is no need to reference ISO/IEC 646.

	1.b. Reference ISO/IEC 10646-2:2001 (FDIS approved).

	1.c. Reference amendment 1 (forthcoming) to IS/IEC 10646-1:2000.

	1.d. ISO/IEC TR 10176 is a *guideline*, and cannot not be referenced
normatively.

	1.e. ISO/IEC 14651:2001 is now an approved standard.

	1.f. The reference to DTR 14652 should ONLY point out the one
specific part that is
		used: toLower/toUpper. Note that case mapping is language
dependent, and
		that the mechanisms given in 14652 is not powerful enough to
express the
		special cases properly.  (See Unicode Technical Report 22,
and the
		SpecialCasing.txt file in the Unicode character database.

	1.g. ISO/IEC 1001:1986; magnetic tape formats seems irrelevant for
the
		programming language level.  Any magnetic tape formats
should be
		handled at the OS device drivers level, not in any
programming language.

	1.h. Reference, and use later on, IEC 60559 (a.k.a. IEEE 754, IEEE
floating point).

	1.i. Reference, and use later on, LIA-1 (ISO/IEC 10967-1:1994; note,
		however, annex E of LIA-2).  LIA-1 is "Language independent
arithmetic-Integer
		and floating point arithmetic".

	1.j. Reference, and use later on, LIA-2 (ISO/IEC FDIS 10967-2:2001).
LIA-2 is "Language
		independent arithmetic-Numerical functions".

2. Arithmetic/numeric operators/FUNCTIONS:

	2.a. For +, -, *, /, **, - (unary), ABS, ACOS, ASIN, ATAN, COS, E
(exp_F(0)), EXP, EXP10,
	     FRACTION-PART,  INTEGER (floor),  INTEGER-PART, LOG, LOG10, MAX
(numerical),
	     MIN (numerical), MOD, PI (cycle_to_rad_F(2,1)), SIGN, SIN, TAN,
	     IS [NOT]...THAN (for numeric values): refer to 10967-1 and
10967-2 for their semantics.

	2.b. Similarly for input/output of numeric values.

	2.b. Add constants/FUNCTIONS for the parameters and derived
constants required by 10967.

3. Syntax:
	Allow DOT OPERATOR for *; for the negation/subtraction operator
allow MINUS in addition
	to HYPHEN-MINUS; allow LESS-THAN OR EQUAL for <=, and allow
	LESS-THAN OR SLANTED EQUAL (soon standardized) for <=; similarly for
>=.

4. clause 4: Definitions

	4.a. def 4.25: byte is strangely defined.
	4.b. def 4.26 and 4.27: a numeral is not the same as a digit (a
numeral often consists of
		several digits; and there are also roman numerals, and CJK
numerals);
		These definitions are also objectionable in that two
different kinds of "characters" are
		defined; Further, the note is highly objectionable, a
"surrogate" is NOT a character!

	4.c. def 4.29: "cell"??

	4.d. def 4.50:  There is a CURRENCY SIGN in 10646 (U+00A4); there
are also other currency
		symbols in 10646.  It is certainly not (just) the $ sign.

	4.e. the term "collation" is not defined.

	4.f. the dichotomy between "character" and "national character" is
bogus, and must be removed
	      from the entire document. Instead have a (new) datatype
specifically for Unicode
	      (recommended encoding form: UTF-16).  For string constants
N"..." should transcode 
	      from the source character encoding to Unicode (UTF-16).  There
should also be escapes
	      so that characters that cannot be expressed in the character
encoding used for the
	      program source still can be expressed.  Compare Java's \uxxxx
(unfortunately UTF-16
	      code unit oriented) and XML's &#xnnnn; (character code
position oriented; much better).

	4.g. "native" character set is a bogus notion.  Many systems today
can handle multipe
	       character encodings simultaneously (usually by transcoding to
Unicode).

	4.f. replace "numeric character" with "common digit" (as opposed to
all other digits in
	     some scripts, as well as other numeral characters that aren't
digits).

	4.i. def 4.184: note that "surrogate pair" is a notion that only
exists for UTF-16 and no other
	     encoding.

5. clause 8 (language fundamentals):

	5.a. clause 8: "the computer's coded character set" is a bogus
notion.  Many systems are
	      capable of supporting multiple coded character sets in
parallel.  Remove the notion
	      that there can be just one (or two) coded character set
supported by a given computer!

	5.b. "Alphabets identify coded character sets for representing data
on external media or
	      collating sequences, or both." Why are the orthogonal notions
of external media and
	      collating sequences handled together?  They are absolutely not
tied to each other at all!
	      Break up this inappropriate tie!

	5.c. 8.1.1. Note 2: UCS-2 is outdated.  Do not refer to it in any
way, anywhere.

The FCD for 1989 is filled with similar objectionable misunderstandings
regarding characters and character handling.  The entire draft needs to be
redrafted, on very very many places, to remove these misconceptions.  The
text is certainly not ready to move on to DIS stage, but should be taken
back to Working Draft stage.

_______end of comments________________________________