From mdeane@ANSI.org Fri Jun 1 17:11:43 2001 Received: from email1.ansi.org (email1.ansi.org [216.173.49.99]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA61614 for ; Fri, 1 Jun 2001 17:11:43 +0200 (CEST) (envelope-from mdeane@ANSI.org) Received: by email1.ansi.org with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 11:11:36 -0400 Message-ID: <2F81C8110D55D411882A0020356797B2194EAA@email1.ansi.org> From: Matthew Deane To: "'SC 22 Distribution List'" Subject: SC 22 N 3243 - Late Comments Received from Sweden on SC 22 N 3204 Date: Fri, 1 Jun 2001 11:11:28 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) 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: mdeane@ansi.org _________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________________________________