From rinehuls@access.digex.net Thu Jul 2 00:54:44 1998 Received: from access4.digex.net (qlrhmEbBUV1EY@access4.digex.net [205.197.245.195]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id AAA05705 for ; Thu, 2 Jul 1998 00:54:39 +0200 Received: from localhost (rinehuls@localhost) by access4.digex.net (8.8.4/8.8.4) with SMTP id SAA15119 for ; Wed, 1 Jul 1998 18:54:23 -0400 (EDT) Date: Wed, 1 Jul 1998 18:54:23 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2745 - Disposition of Comments Report on DIS 16262 -ECMAScript Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE __________________ beginning of title page _________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) IOS/IEC JTC 1/SC22 N2745 TITLE: Disposition of Comments Report for DIS 16262 - Information technology - Programming languages - ECMAScript: A General Purpose Cross-Platform Programming Language (Fast-track Process) DATE ASSIGNED: 1998-06-30 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Disposition of Comments Report PROJECT NUMBER: JTC 1.22.16262 STATUS: N/A ACTION IDENTIFIER: FYI DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: SC22 N2706, N2743 DISTRIBUTION FORM: Def Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ____________ end of title page; beginning of report ___________________ Disposition of Comments Report for DIS-16262 15 June, 1998 The following report describes the actions that have resulted from=20 comments received for the ISO/IEC Letter ballot for DIS-16262. All=20 comments received before the deadline of 9 April 1998 are included in=20 this report. This document was approved at the ISO/IEC DIS-16262=20 ballot resolution meeting held 15 June 1998 at Sun Microsystems in=20 Menlo Park, California ECMA TC-39 appreciates all of the comments that have been received.=20 These comments and the resulting improvements to the draft standard=20 provided great benefit to future users of ECMAScript. Comments have been received from the following countries: Denmark (D) France (F) Japan (J) Netherlands (N) USA (U) ECMA=A0 (E) All comments received have been merged into a single document. The=20 sequence of the comments has been arranged to match the paragraphs in=20 the DIS. To identify the original comments tags referencing country=20 and paragraph (e.g. D1, D2, D3, etc., U1.1, U1.2, etc.) have been=20 added. Many of the comments that apply to more then one specific=20 section have been grouped together at the beginning of the report in a=20 section titled General Comments. After each comment the action of the committee is provided. The=20 committee actions are highlighted by the notation: >>>>>> Action:=20 [committee action ] --- [comment on the action] <<<<< This report is divided into two major sections: Comments that apply to across multiple sections -- General=20 Comments Comments that apply to specific sections General Comments are divided into four sections: Editorial; Name of=20 the Standard: Year 2000; and Character Related issues. In some cases=20 comments on specific sections are also covered by the comments in the=20 General Comments section. In some of these cases a reference to more=20 general response has been provided. Comments on specific sections have been arranged by the sections and=20 subsection used in the draft ECMAScript standard. In some cases=20 similar comments have been combined. In these cases the comment tag=20 includes a reference to each of the original comments. General Comments =20 Editorial Issues J-general) --- Minor Technical and Editorial comments: With ECMA-262, JNB found a lot of minor technical and editorial=20 errors. Therefore, JNB would strongly suggest that a technical=20 corrigenda should be prepared of this standard, and be republished=20 after spell checking of the standard document. The followings are just=20 examples and not the complete list of errors. I'm afraid if a work=20 document was published instead of the final version by accident, since=20 there are so many spell errors. =20 >>>>> Action: Accepted --- The committee will endeavor to improve=20 future documents. <<<<< =20 N1) General comment: It is disappointing that this document contains quite a large number=20 of typos and some misplaced sections. We think that the fast-track=20 procedure has not been intended for such textually immature documents.=20 Careful inspection by the editor would have uncovered many problems.=20 Below some of these problems have been indicated: we are unsure we=20 caught all. =20 >>>>> Action: Accepted --- The committee will endeavor to improve=20 future documents. <<<<< =20 U1.50) General comment. Some level-2 and level-3 headings have each=20 word with a leading capital letter and some don't. Make them=20 consistent. =20 >>>>>> Action: Accepted --- Consistent headings will be used. <<<<< U1.51) General comment. It would probably be an improvement to set all=20 reserved words, function names, and operators in headings in a=20 constant-width typeface. Having the level-2 heads 12.7 to 12.10 be all=20 caps whereas those in 12.6.1 to 12.6.3 are not, looks strange. >>>>>> Action: Accepted --- Document corrected to be consistent. =20 <<<<< =20 U2.1) The term "runtime error", "compile-time error" and "error" are=20 all used, but not defined. This document should define how a "compile=20 time error" is recognized, for example by an implementation defined=20 diagnostic message or return code Same with "runtime error" and error.=20 Without these definitions measuring conformance will be impossible. =20 >>>>>> Action: Accepted --- The term compile-time error was removed;=20 error alone should be runtime error (there were only 1 or two cases). =20 (Definition of how the error is surfaced is an environment issue, that=20 is, implemenetation-defined) <<<<< U6.4) Look for all copies of the word "we" and replace with standards=20 wording. >>>>>> Action: Accepted --- Use of "we" will be removed from the=20 document. <<<<< Name of the Standard =20 U5) During the standardization process for ECMA 262, the naming of the=20 standard was dealt with in an unsatisfactory manner with a less than=20 optimal result. The original name put forward to the committee,=20 LiveScript, was agreed on by all members but was withdrawn at the last=20 moment with no alternative proposed. This resulted in a standard named=20 ECMAScript. Because this is not a copyrighted or trademarked label it=20 is unlikely that any implementation of the language will be called=20 ECMAScript. This has and will result in confusion for users as to what=20 the standard means and what language engines support the standard. We believe that in the case of standards applicable to the mass market=20 (where both the contributors to the standardization effort and the=20 public at large have an expectation of interoperability) names are=20 very important, both as an indicator of the openness of the process=20 where the parties cooperating expect to begin to compete from a common=20 footing at the end of the process, and as an assurance to the public=20 that their expectations are forthrightly met (e.g. codewords and=20 numbers are unacceptable when assuring the public that they can=20 connect an appliance into a wall outlet). Where the community of=20 customers are small or well informed, this is less an issue than in=20 the case of ECMA262. Also, the lack of a marketable name and ownership (or at least=20 unencumbered use) of a popular name by ECMA (or any standards body=20 that is unable to assert ownership of their efforts) for a highly=20 visible interoperability standard diminishes that body's ability to=20 generate revenues from the publication and ongoing maintenance of the=20 definitive standard. This can be seen in the commercial publication of=20 other "standards" in the same discipline without regard for the=20 hosting organization's need for a sustaining revenue stream. Lack of=20 ownership will bias future efforts towards less formal consensus=20 efforts not dependent on publication revenues and further undercut the=20 traditional standards bodies. =20 >>>>>> Action: Not accepted --- The committee has not obtained use=20 of the name LiveScript. <<<<< =20 =20 Year 2000 Issues =20 J4.1) Two digit representation of year As discussed in the ECMA-262, Date.prototype.getYear() and setYear()=20 has "year 2000 problem". If the rationale of inclusion of the=20 functionality is only backward compatibility, those methods should be=20 removed form this standard, because (1) this is the first edition of ECMAScript therefore there is no=20 previous version nor edition from the standard view point. (2) this standard allows enhancement of properties and methods,=20 therefore implementations of this standard can provide these method as=20 enhancement. Also, in some methods when the year value between 0 and 99 is=20 specified. the 1900 will be added to the value as a base. This=20 specification may not appropriate to the standard published in 1998 or=20 1999. The default base should be removed or amended. For example add=20 1990 if the value is somewhat between 70 and 99, and add 2000 if the=20 value is between 0 and 69. =20 >>>>>> Action: Partial acceptance --- Please see the Action note at=20 the end of this section on year 2000 issues. <<<<< =20 U3) Paragraphs 15.9.5.5 Date.prototype.getYear() and 15.9.5.38 Date.prototype.setYear() should be removed because, as noted in ECMA- 262 they may contribute to the "Year 2000" problem. The rationale for=20 their inclusion, backwards compatibility (with what, as there are no=20 prior standards), is not sufficient for such a strongly deprecated=20 programming practice. =20 >>>>>> Action: Partial acceptance --- Please see the Action note=20 at the end of this section on year 2000 issues. <<<<< =20 U7) The year 2000 date rollover problem is having profound effects on=20 government and industry software systems worldwide. Systems are=20 already failing due to the erroneous processing of dates that include=20 the year 2000. Most software systems are programmed to recognize 2- digit years in dates as occurring within the 20th century, with the=20 implication that the first two digits of the year are 19. When the=20 year 2000 comes into play, these software systems will more than=20 likely recognize 00 as 1900 instead of 2000, causing consternation=20 among users, system managers, and database administrators. Billions of=20 dollars are being spent on fixing the problem. =20 The U.S. Congress is holding frequent hearings on the progress that=20 Federal agencies have made in repairing systems that support a myriad=20 of government programs. A meeting among representatives of the U.S.=20 Office of Management and Budget (OMB), 27 Federal agencies, and 41=20 states in October 1997 affirmed the action to require 4-digit years in=20 all dates used in data interchange between the Federal and state=20 governments, and that the Federal government would act as lead in=20 further actions as necessary. Further, the U.S. Securities and=20 Exchange Commission (SEC) is examining requirements for publicly held=20 companies to disclose the extent of date processing problems and plans=20 for correcting these problems within their mandatory filings. Other=20 Federal agencies, most notably the Nuclear Regulatory Commission=20 (NRC), the Federal Aviation Administration (FAA), the Environmental=20 Protection Agency (EPA), the Food and Drug Administration (FDA) and=20 others are developing implementation plans for overseeing the=20 correction of date processing problems within regulated industries.=20 NIST spearheaded the government's position when it issued Change=20 Notice 1 to Federal Information Processing Standard (FIPS) 4-1 in=20 March 1996 which highly recommended the use of 4-digit years and=20 deprecated the use of optional 2-digit years. =20 The National Committee on Information Technology Standards (NCITS --=20 formerly X3) Technical Committee L8 has recommended a new date format=20 interchange standard that provides for only a 4-digit year format=20 (NCITS L8 3.30). The recommended standard has been forwarded to ANSI=20 which has placed it on its list of standards to be published. The 2- digit year format has been excluded. The international standard, ISO=20 8601:1988 (under the auspices of ISO TC154), has not been changed. =20 REQUIRED CHANGES =20 The ECMAScript specification provides functions for processing 2-digit=20 and 4-digit years directly (see sections 15.9.5.5, 15.9.5.6, 15.9.5.7,=20 15.9.5.10, 15.9.5.11, 15.9.5.36, and 15.9.5.38) and other functions=20 that use 2-digit or 4-digit years based on the prototype date=20 arguments. The 2-digit year option should be left out of the specification=20 entirely for the following reasons: 1. The Year 2000 problem is based on this option and will provide no=20 end of frustration for implementers who have to justify why this=20 option is still part of the ECMAScript specification, in view of the=20 attention the problem has received already. 2. The liability of resellers and implementers will come more and more=20 into focus as users rely on the court system to determine who is=20 responsible for correcting problems based on this option. 3. The specification allows for implementations with extended=20 capabilities, as long as the extended capabilities do not cause=20 erroneous operation of the standard requirements. The ECMAScript=20 specification is clear in providing two sets of functions that treat=20 dates differently. The lack of 2-digit date processing functions=20 should, ostensibly, not interfere with 4-digit year processing. Two- digit year processing may be implemented within the realm of=20 extensions without causing undue influence on the standard use of the=20 specification. 4. Not withstanding the need to provide functionality of de facto=20 implementations, notes in the specification to the effect that these=20 functions are provided for backward compatibility have no meaning with=20 respect to this standard since there were no previous nationally or=20 internationally recognized standards. >>>>>> Action: Partial acceptance --- Sections 15.9.5.5 and=20 15.9.5.38 have been removed from the normative section of the=20 ECMAScript standard. These sections will remain as informative text=20 describing current practice to allow for a transition to more=20 appropriate programing practice. Related changes will be made in=20 other sections including 15.9.3 and 15.9.4. The committee while=20 discouraging its use has chosen to retain the special function to=20 dates in the range 0 to 99 to be off set by 1900. <<<<< =20 =20 Character Related Issues =20 D3. All references to "unicode" string of characters should be changed=20 to "UCS" strings or characters. This relates at least to clauses=20 4.3.16, 4.3.17 5.1.4 6 7 7.7.4 8.4 11.8.5 11.9.3 15.1.2.4 15.5.3.2=20 15.5.4.5 It is necessary to specify that this means UCS-4, or possibly=20 UTF-8 =20 >>>>>> Action: Partial acceptance --- Please see the Action note at=20 the end of this section on Character issues. <<<<< =20 J3.1 Repertoire of charter In the clause of 15.3.2, the String.fromCharCode is specified. This=20 method is specified based on an assumption that BMP of ISO/IEC 10646=20 can contains every character in the world, since the method has 16bit=20 dependency. Per request from users, right now ISO/IEC JTC l/SC2 is=20 working to specify additional plains of ISO/IEC 10646 with the=20 understanding of 16bit space is not sufficient to encode characters=20 required for some applications. Therefore, this standard also should=20 not have the 16bit dependency, then the return value of the method=20 should be a integer value regardless of 16bit or 32bit. In addition to=20 the above particular problem, JNB does not understand why the method=20 need to be standardized, since I/O functionality is outside of this=20 standard, and this standard allows addition of methods and properties=20 to conforming implementations. If this standard include I/O function=20 as JavaScript or JScript have, JNB can understand the requirement to=20 convert character to character code supported by its platform. but it=20 is not the case of ECMAScript. Also, it is quite bad programming=20 manner to check an attribute of character from its code point. If=20 there is any requirement to check an attribute of character, a future=20 revision of this standard should provide such functionality in the=20 manner being "locale" sensitive. One suggestion might be simply remove=20 the method from the standard, and make it enhancement by the specific=20 implementations. =20 >>>>>> Action: Partial acceptance --- Please see the Action note at=20 the end of this section on Character issues. <<<<< =20 J3.2) Upper-/lower.casing It is widely understood that upper and=20 lower-casing rules are language and/or culture dependent. Therefore,=20 if such language sensitive case conversion in the requirement. the=20 functionality should be provided in the manner of "locale" sensitive=20 in a future revision of this standard. If not, this standard should=20 specify minimum requirement that is common to every language, such as=20 case conversion rule for the Latin characters specified in ISO/IEC=20 646, then behavior of outside of ISO/IEC 646 should be specified as=20 implementation defined. =20 >>>>>> Action: Partial acceptance --- Please see the Action note at=20 the end of this section on Character issues . <<<<< =20 J3.3) Character literal outside of ISO/IEC 646 repertoire The ECMA-262 allows literal representation method such as YuXXXX.=20 Having the format is fine, but the description should be specified,=20 such as "Character short identifiers headed by Yu are defined as=20 follows. " Per request from the ISO/IEC JTC 1/SC22. the ISO/IEC JTC=20 1/SC2 proposed a short hand representation of character name that has=20 one to one correspondence with character long name used throughout of=20 IS0 character set standard, i.e. character code point of ISO/IEC=20 10646. then the second edition of the ISO/IEC TR 10176 that is=20 approved recently recommended the support of the form of literal=20 representation in order to specify character literal in an character=20 code independent manner. The character short identifier looks very=20 similar to the code point of ISO/IEC 10646, but the big difference=20 would be the correspondence between the character short identifier and=20 a character will be maintained even if code point assignment of the=20 character is changed by a corrigenda or an amendment of ISO/lEC 10646.=20 JNB thinks, the change of the definition of YuXXXX may not impact to=20 the actual technical contents of this standard, but contribute to make=20 the standard independent from any encoding system. Also, if the=20 comment 3.1 is accepted, JNB would suggest to specify YuXXXXXXXX form=20 in addition to YuXXXX, so that the character included in ISO/IEC 10646=20 but allocated outside of BMP become able to be represented. >>>>>> Action: Partial acceptance --- reference the following text E1)The second paragraph of clause 2 on conformance need to be=20 improved. A proposal for such an improvement is the following:=20 "A conforming implementation of this International standard shall=20 interpret characters in conformance with The Unicode Standard, Version=20 2.0, and ISO/IEC 10646-1 with UCS-2 as the adopted encoding form,=20 implementation level 3. If the adopted ISO/IEC 10646-1 subset is not=20 otherwise specified, it is presumed to be the BMP subset, collection=20 300."=20 Background information The above proposed text does talk about implementation level 3 as=20 described in 10646, but it does not mean that ECMAScript would have to=20 process a character and a combining sequence as yet another uniquely=20 identified character. ECMAScript can treat a combining sequence as=20 just another 16-bit value. Combining sequences are encoded for use=20 with some base characters especially for Indic, Thai, Arabic and=20 Hebrew scripts. Platforms and application software decides how to=20 process a base character and a combining sequence.=20 Note that combining sequences can be used for Latin as well but the=20 vast majority of Latin script characters are already encoded in 10646.=20 For conformance with The Unicode Standard it is important that=20 combining sequences are not damaged as they go through a process, such=20 as ECMAScript. Unicode supports combining sequences and provides an=20 equivalence algorithm that facilitates comparing precomposed=20 characters with a base character followed by a combining sequence. All=20 that ECMAScript, and other programming languages, need to do is to let=20 a data stream of 16-bit values pass through the process cleanly and=20 with no damage to the data. =20 >>>>>> Action: Accepted --- New wording will be added to the=20 conformance section. Also reference the following text. Resolution to Comments on Character Related Issues To address the Character Related issues changes were made in many=20 sections of the ECMAScript standard. Described below is the wording to=20 added to Sections 2 and 3 to the majority of the comments . Additional=20 changes have been made that clarify when ECMAScript operations refer=20 to codepoints (cc data elements) and not characters as described in=20 the original draft ISO/IEC standard. Text to be added to Section 2 - Conformance.=20 "A conforming implementation of this edition of ECMAScript shall=20 interpret characters in conformance with The Unicode Standard, Version=20 2.0, and ISO/IEC 10646-1 with UCS-2 as the adopted encoding form,=20 implementation level 3. If the adopted ISO/IEC 10646-1 subset is not=20 otherwise specified, it is presumed to be the BMP subset, collection=20 300." Please note that the text below is included here to explain the=20 rationale of the proposed text and does not need to be included in the=20 normative part of ECMAScript.=20 The above proposed text does talk about implementation level 3 as=20 described in 10646, but it does not mean that ECMAScript would have to=20 process a character and a combining sequence as yet another uniquely=20 identified character. ECMAScript can treat a combining sequence as=20 just another 16-bit value. Combining sequences are encoded for use=20 with some base characters especially for Indic, Thai, Arabic and=20 Hebrew scripts. Platforms and application software decides how to=20 process a base character and a combining sequence.=20 Note that combining sequences can be used for Latin as well but the=20 vast majority of Latin script characters are already encoded in 10646.=20 From a Unicode conformance point of view, what is important is that=20 combining sequences are not damaged as they go through a process, such=20 as ECMAScript. Unicode supports combining sequences and provides an=20 equivalence algorithm that facilitates comparing precomposed=20 characters with a base character followed by a combining sequence. All=20 ECMAScript, and other programming languages, need to do is let a data=20 stream of 16-bit values pass through the process cleanly and with no=20 damage to the data.=20 Text to be added to Section 3 - References.=20 Unicode: "Unicode Inc. (1996), The Unicode Standard TM, Version 2.0.=20 ISBN: 0-201-48345-9, Addison-Wesley Publishing Co.: Menlo Park,=20 California"=20 ISO 10646: "ISO/IEC 10646-1:1993 Information technology -- Universal=20 Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and=20 Basic Multilingual Plane"=20 The additional information provided below is only for reference and=20 not for inclusion in the ECMAScript normative part of the standard.=20 The information highlights the contents of the conformance clauses of=20 Unicode 2.0 and ISO 10646:=20 Additional Information from Unicode 2.0 Conformance:=20 This is spelled out in detail in Chapter 3, Conformance, of The=20 Unicode Standard 2.0. Here are the bulleted items:=20 - Byte Ordering:=20 - C1 A process shall interpret Unicode code values as 16-bit=20 quantities.=20 - C2 The Unicode Standard does not specify any order of bytes=20 inside a Unicode value.=20 - C3 A process shall interpret a Unicode value that has been=20 serialized into a sequence of bytes, by most significant byte first,=20 in the absence of higher-level protocols.=20 - Invalid Code Values=20 - C4 A process shall not interpret an unpaired high- or low- surrogate as an abstract character.=20 - C5 A process shall not interpret either U+FFFE or U+FFFF as an=20 abstract character. - C6 A process shall not interpret any unassigned code value as an=20 abstract character.=20 - Interpretation=20 - C7 A process shall interpret a coded character representation=20 according to the character semantics established by this standard, if=20 that process does interpret that coded character representation.=20 - C8 A process shall not assume that it is required to interpret=20 any particular coded character representation.=20 - C9 A process shall not assume that the interpretations of two=20 canonical-equivalent character sequences are distinct.=20 - Modification=20 - C10 A process shall make no change in a valid coded character=20 representation other than the possible replacement of character=20 sequences by their canonical-equivalent sequences, if that process=20 purports not to modify the interpretation of that coded character=20 representation.=20 Additional Information from ISO 10646 Conformance clause:=20 This is spelled out in detail in clause 2, Conformance, of ISO/IEC=20 10646-1:1993. Here is the essence of that clause.=20 2 Conformance=20 2.1 General=20 Whenever private use characters are used as specified in ISO/IEC=20 10646, the characters themselves shall not be covered by these=20 conformance requirements.=20 2.2 Conformance of information interchange A coded-character-data-element (CC-data-element) within coded=20 information for interchange is in conformance with ISO/IEC 10646 if=20 a) all the coded representations of graphic characters within that CC- data-element conform to clauses 6 and 7, to an identified form chosen=20 from clause 14 or Annex Q or Annex R, and to an identified=20 implementation level chosen from clause 15;=20 b) all the graphic characters represented within that CC-data-element=20 are taken from those within an identified subset (clause 13);=20 c) all the coded representations of control functions within that CC- data-element conform to clause 16. A claim of conformance shall=20 identify the adopted form, the adopted implementation level and the=20 adopted subset by means of a list of collections and/or characters. <<<<< Comments by Section French Title F 1) Qualifier: major editorial Rationale: French title inaccuracy Proposed change Change the French title for the following : ECMAScript : un language de programmation multiplate-forme =E0 usage=20 g=E9n=E9ral >>>>>> Action: Accepted --- French title will be changed. <<<<< =20 =20 Table of Contents =20 N2) Contents: (ed) It is requested that annexes containing the collected syntaxes will be=20 provided in the final document. =20 >>>>>> Action: Not accepted --- The committee feels such a section=20 would be useful but will leave this task to others. <<<<< =20 U6.5) Page vi: typo on top of page in PDF version. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 =20 Section 1 - Scope =20 J-E3) We need more than one liner to define the scope of the standard. =20 >>>>>> Action: Not accepted --- The committee feels this scope is=20 clear in conjunction with the other information provided. <<<<< =20 =20 Section 2- Conformance =20 J1.1) Implementation limits and implementation defined matters The ECMA-262 does not specify implementation limits nor implementation=20 defined items, therefore it is considered that conforming=20 implementation of the ECMAScript must meet with everything described=20 in the ECMA-262. Besides, the clause 7.5 says "An identifier is a character sequence=20 of unlimited length" without specifying any implementation limits of l=20 number of characters and numbers of identifiers. It implies that every=20 conforming implementation must support identifiers that consists of=20 millions of characters and accept millions of identifiers in a=20 program. Japanese National Body (JNB) believe that the requirement=20 would be too tough for any implementation.=20 Therefore, JNB would suggest that the ECMA- 262 should have=20 "implementation limits" clause and specifies minimum requirements for=20 program portability in the clause, then provide a clause,=20 "implementation defined matter" and list the items that a conforming=20 implementation can define.=20 For example, specify minimum requirements of length of an identifier=20 as 256 in the implementation limits clause and specify the number of=20 character allowed for identifiers as implementation defined matter, so=20 that such an implementation becomes conformance to this standard that=20 takes first 1024 characters of the identifier as meaningful and ignore=20 the remaining characters.=20 The length of identifiers, the number of identifiers in a program, and=20 the length of a line should be implementation defined. =20 The clause 7.2 introduces the concept Line terminators. But the means=20 of line termination is file system dependent, e.g. FIXED type dataset=20 of IBM System 390 does not have any line terminator character. So, the=20 means of line termination should also be implementation defined, as=20 far as the scope of this standard is general purpose. =20 >>>>>> Action: Not accepted -- Environments must provide line=20 terminator characters. ECMAScript follows Java precedent in this=20 respect. <<<<< =20 J1.2) Direct reference to documents outside of ISO/IEC standard=20 The ECMA-262 directly refers to technical contents of=20 document/specifications outside of de jure standards. The bad examples=20 are of reference to Unicode book and a RFC.=20 Since those documents are out of control of standard body, once the=20 documents are revised, a once-conforming implementation of this=20 standard may suddenly become non-conforming.=20 Therefore, only international de jure standards, i.e: ISO/IEC, can be=20 referred to by normative part of this standard. For example, reference=20 to Unicode book should be replaced with the reference to the ISO/IEC=20 10646, If there is no existing ISO/IEC standard that is equivalent=20 with the technical contents of what referred to by this standard, a=20 clause or a normative annex should be provided in this standard, then=20 specify the technical contents in the clause or annex. =20 >>>>>> Action: Partial acceptance --- The Document has been reviewed=20 to remove references to documents outside of ISO/IEC standards were=20 appropriate. Please see additional information in the Action note at=20 the end of the above section on Character Related issues. <<<<< =20 J1.3) "Discussion" clause ECMA-262 has clauses named "discussion" According to the IS0=20 directives part 3. these clauses should be normative portion of this=20 standard and the contents in the clauses are included in the=20 requirements for conformity.=20 However, my impression on these is different. They sounds more like=20 private notes or memoranda.=20 If the contents of the discussion clauses does not have requirements=20 for conformity, the clause should be NOTES or it should be clarified=20 that the discussion clauses are informative portion of this standard=20 in the conformance clause. =20 >>>>>> Action: Accepted --- Use of "discussion" will be changed to=20 "notes" to make a clear indication that the text is informative. =20 <<<<< =20 J2) Data representation in a datatype Programming language standard that does not have binary/object level=20 portability as its objectives should not specify data representation=20 of a datatype. In order not to restrict freedom of implementation. In=20 order programming language standards to be independent from any=20 encoding technology, the datatype should be specified by repertoire of=20 data that the datatype can contains.=20 In this sense, the String type should be specified as the set of all=20 finite ordered sequence of zero or more character data type, then=20 should have a definition of character type as that the repertoire of=20 the character data type shall be whole/entire repertoire of 1SO/IEC=20 10646, =20 Note that the ISO/IEC 10646 has the concept of subset, so if this=20 standard allows an implementation that support a subset of ISO/IEC=20 10646, the minimal subset should be specified by this standard and=20 actual repertoire of character should becomes implementation defined.=20 The same thing can be applied for the Number type. Usually, a data=20 type for numeric data is specified by limits of the value, e.g., -128=20 through 127.=20 If this standard need to have a wide range of exact integer values,=20 e.g., -2^40 through +2^40 to assure the exact calculation of Date=20 values in milliseconds, this standard should specify so, instead of=20 referring to IEEE 754 and concluding the integer value range.=20 Also. if this standard need some severe requirement on the precision=20 of real (floating) values, this standard should specify so by giving=20 necessary minimum requirements. Many programming languages have tried=20 to make their specifications as, "cross-platform" as possible from the=20 users' point of view. especially for the purpose that numerical=20 algorithms can be programmed in "cross-platform" way. They specify=20 minimum requirements (for all implementation) and introduce constant=20 names such as MAX_VALUE, MIN_VALUE etc. to make platform defined=20 values available to users. Otherwise, an implementation that uses a=20 representation which precision is more accurate/large than IEEE 754=20 becomes not conformity to this standard. For those point it might help=20 to consult ISO/IEC 11404:1995 Information Technology - Language Independent=20 data types. ISO/lEC 10967:1994 Information Technology . Language Independent=20 Arithmetic- part 1: Integer and floating point arithmetic. =20 JNB is skeptical if ECMAScript need special values such as NaN,=20 Infinity, etc. for itself. Infinities are returned when the=20 computation yields "overflow"; ECMAScript has no "Notification"=20 mechanism to handle "overflow": and it might be a way to continue the=20 computation without interruption that ECMAScript requires Infinities=20 as continuation values in those cases. But NaN is yielded only when=20 some of arguments ie already a NaN. ECMAScript could permit an=20 implementation which has representation of Infinities but of NaN.=20 JNB is also skeptical if ECMAScript need such a high precision as of=20 current specification on floating point computation. Thin standard=20 requires some specific real values, such as E, PI, LNlO, be available=20 as closest possible floating numbers in 53 byte accuracy. Nevertheless=20 all the defined functions are left unspecified about their returning=20 values accuracy. If ever high precision computation were mandatory to=20 ECMAScript, those functions should have been specified with severe=20 accuracy requirement on their results.=20 De jure standard should not hinder the future improvement of=20 technology as far as possible. Note that some programming language=20 that has requirements on binary portability, such as BYTE CODE of=20 Java, may need to specify internal representation of data in a=20 datatype. But, JNB does not think that ECMAScript has such binary=20 portability requirement.=20 For improvement of this standard, JNB would suggest that this standard=20 should align with recently approved ISO/IEC TR 10176 and IS0 standard=20 regarding language independent data types. >>>>>> Action: Partial acceptance --- The standard will make it clear=20 that it deals with type-byte encodings of characters. Please see the=20 Action note at the end of the above section on Character Related=20 issues for additional information on ISO/IEC 10646. The committee as=20 chosen to leave the math functions unchanged. <<<<< =A0 N3) Section 2 (ma) The conformance clauses in this section, and in particular the last=20 one leave too much room for non-standard extensions to the language.=20 Such extensions will lead to portability problems. It is unclear how=20 conformity of implementations will be checked against conformance=20 clauses as have been given here. =20 >>>>>> Action: Not accepted --- Though portability will be an issue=20 the current wording reflects the committee's intention. The goal of=20 this first version of ECMAScript was to create a base standard. It is=20 expected that the use of non-standard extensions will be reduced=20 through the development of future versions of ECMAScript. <<<<< =20 U6.6) Clause 2, page 13: If a conforming implementation can support *any* syntax, then how are=20 conforming implementations tested? The conformance clause should be=20 worded differently to identify non-conforming programs. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E4 & N4 & U1.1) 2 Conformance "section 0" should be "section 7.4.3" =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 Section 3 - References =20 D1) The standard needs to be aligned with ISO and IEC standards in the=20 area. These include: on page 1, clause 3, references: =20 ANSI X3.159 programming language C, should read ISO/IEC 9899:1996 including AM1 and TCOR1. ANSI/IEEE 1754 should maybe be "754". Unicode consortium unicode standard 2.0 should be replaced by : ISO/IEC 10646-1:1998 including TCOR 1 and AM 1-9, plus ISO/IEC DIS 14651 International sorting order, and ISO/IEC DIS 14652 Specifications for cultural conventions Then there is no need to refer the non-de-jure Unicode=20 specification. =20 The Java specification is not used normatively, and can be moved to a=20 bibliography section. =20 The specific statements needed of RFC1738 can be incorporated directly=20 in the standard, it is about encoding in characters of control=20 characters. =20 We could not ascertain the normative usefulness of the Ungar and Smith=20 reference, it can most likely be moved to a bibliography section. =20 Then the normative references is only de jure standards. =20 >>>>>> Action: Accepted --- Some of this comment will also be moved=20 to section 4. <<<<< =20 D2) The following references should be added: ISO/IEC 646 (instead of ASCII) ISO/IEC 6429 - for control characters. ISO/IEC DIS 15897 - for reference to locales/fdcc-sets. =20 >>>>>> Action: Partial acceptance --- Reference to ISO/IEC 646 has=20 been added, others are not mentioned. <<<<< =20 J-E1) 3 Reference Only de jure standard referred to be from normative part of the=20 standard that is related with conformance of this standard should be=20 listed in the reference clause. Every reference documents outside of=20 de jure standards and the ones just help to understand about the=20 technical contents this standard should be removed from the clause or=20 move to an informative annex. =20 >>>>>> Action: Accepted --- Document corrected <<<<< N5) Section 3 (ed) It is requested that, where possible, references to IS0 standards will=20 be provided. The following standards have been referenced in the=20 document, but are not mentioned here: ASCII, HTML. >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.2) pp. 1, 3 References, line 1. ANSI X3.159-19989 is the original C standard. That was withdrawn and=20 replaced by the ANSI/ISO C standard ANSI/ISO 9899:1990, adopted in=20 1990. (An addendum was added in 1996, but I think the 1990 version=20 reference will be sufficient.) =20 >>>>>> Action: Partial acceptance --- Document corrected to=20 reference ISO/IEC 9899:1996 <<<<< =20 U2.2 & U6.7) The reference to the C standard should be ISO/IEC=20 9899:1993, not the ANSI document. =20 >>>>>> Action: Partial acceptance --- Document corrected to=20 reference ISO/IEC 9899:1996 <<<<< =20 U4.1) On p. 1, Section 3 (references), the references should be to the=20 ISO/IEC versions of the standards mentioned. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.3 & U6.9) Unicode should be replaced with ISO 10646-1 BMP=20 (universal character) throughout the document. =20 >>>>>> Action: Partial acceptance --- Please see the Action note at=20 the end of the above section on Character Related issues. <<<<< =20 U6.8) Add URL for RFC 1738. =20 >>>>>> Action: Not accepted --- The reference was removed. The=20 description of the mapping was already present. <<<<< Section 4 - Overview =20 J-E2) 4 Overview The first word of the clause 4, i.e. "EMCAScript" should be replaced=20 with "ECMAScript" =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N6) Section 4 (ed) A scripting language is intended for use by both professional and non- professional programmers and therefore there may be -- The implication shown by the use of 'therefore' is unclear. -- The sentence seems incomplete. >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.3) pp. 1, 4 Overview, line -3 Re `informalities and build', either strike `and' or add the missing=20 noun that should follow it. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E5) 4.1 There are "server-side" and "server side." They should be=20 one representation either with or without hyphen. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N7) Section 4.1 led) A web browser provides en .,... (isn't this prescribing too much? 4=20 times) --> A conforming web browser can/may provide en . Typo: error: and abort Typo: clients, and files. and =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E6 & U1.5 & U4.2) 4.2 In the last sentence of the last paragraph,=20 "anddefined" should be "and defined." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N8) Section 4.2 (ed) It is unclear how a syntax can be `relaxed'. A syntax is simply a=20 description. Typo: anddefined Typo: missing full stop =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.4) pp. 2, 4.2 Language Overview, line -4. Should Java be indicated as a trademark here (or possibly in the front=20 matter)? =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E7 & N9 & U1.6 & U4.3) 4.2.1 In the second sentence of the second=20 paragraph, "aprototype" should be "a prototype." In the figure. "Cfp"=20 should be "CFp" in order to be consistent with the description below. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N9) Section 4.2.1 (ed) Comma: contains. share Figure: Cfp -> CFp Figure; There is no meaning given for the normal arrow used form CF to=20 CFp. =20 >>>>>> Action: Accepted --- Document corrected to show legend for=20 solid link. <<<<< =20 U1.7) pp. 3, 4.2.1 Objects, line 8. `The following diagram may illustrate this discussion:' That doesn't=20 sound like it definitely does. Either make the diagram illustrate it=20 or improve the wording. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.8) pp. 3, 4.2.1 Objects, line 13. Strike the colon. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.9) pp. 3, 4.2.1 Objects, line 15. `on the fly' sounds a bit colloquial to me. How about `dynamically' or=20 `at run time'? =20 >>>>>> Action: Accepted --- Document corrected <<<<< =A0 U1.10) pp. 3, 4.2.1 Objects, line 16. Re `any of its properties.' What is the subject referred to by `its'?=20 I guess its refers to an object, but `its' is singular and `objects'=20 is plural. >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.10) Subclause 4.3: This should be broken out as a separate clause. The beginning of=20 clause 4 implies that the clause is informative; it appears that=20 subclause 4.3 should be normative. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N10) Section 4.3.1 (mi) A type is a set of data values. -- Are non-homogeneous sets allowed? In general, the correct functioning of a program is not affected if=20 different data values of the same type are substituted for others.=20 Well , it depends upon what is meant by `in general' and `correct',=20 but as a general statement this seems to be incorrect for any=20 programming language.' =20 >>>>>> Action: Accepted --- Wording has been removed. <<<<< U4.4) On p. 3, Section 4.3.1 (Type), "A type is a set of data values.=20 In general, the correct functioning of a program is not affected if=20 different data values of the same type are substituted for others."=20 This sentence is unclear because the correct functioning of a program=20 does depend on the proper sequencing of values. >>>>>> Action: Accepted --- Wording has been removed. <<<<< =20 U1.11) pp. 3, 4.3.3 Object, line 1. Change `properties which contain' to `properties each of which=20 contains'. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N11) Section 4.3.9 (mi) The notion of a 'variable' has not been defined in this section. =20 >>>>>> Action: Accepted --- Document corrected <<<<< U1.12) pp. 4, 4.3.9 Undefined, heading. Add `value' to the heading as in 4.3.13 and 4.3.16. >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.13) pp. 4, 4.3.11 Null, heading. Add `value' to the heading as in 4.3.13 and 4.3.16. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.14) pp. 4, 4.3.13 Boolean value, line 1. Strike `either'. >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E9) 4.3.15 In some Cases, "Boolean object" is used, but in some=20 other cases, "boolean object" is used. Whether a word like "boolean'=20 should start with a capital letter or not, should be consistent=20 throughout the document. The same thing applies to 4.3.21 of "Number=20 object" and "number object," =20 >>>>>> Action: Accepted --- Document corrected will be made=20 consistent <<<<< =20 N12) Section 4.3.15 (ed) This is an example of . . -- This sections seems to be misplaced. =20 >>>>>> Action: Not accepted --- The committee feels it is correctly=20 placed. <<<<< =20 U1.15) pp. 4, 4.3.15 Boolean object, line 5. Replace `in this case it is' with `the ability'. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N13) Section 4.3.16 (ed) of the type String and is the set of . -- the latter part of that sentence seems misplaced (see also 4.3.17) =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.16) pp. 4, 4.3.16 String value, line 1. it seems to me that a string value is one of the set of all finite=20 ordered sequences not the whole set. >>>>>> Action: Accepted --- Document corrected <<<<< =20 N14 & U1.17) Section 4.3.19 (ed) . . . a number value _is_ =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.18) pp. 5, 4.3.20 Number type, line 1. ``In ECMAScript the set of values represent the double-precision 64- bit format IEEE 754 value ...'' sounds like there is only 1 64-bit=20 format value. Perhaps it should say ``In ECMAScript the set of values=20 represent all the double-precision 64-bit format IEEE 754 values=20 including the special "Not-a-Number" (NaN) value, positive infinity,=20 and negative infinity.'' =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 =20 U1.19) pp. 5, 4.3.22 Infinity, heading. Add `value' to the heading as in 4.3.13 and 4.3.16. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.20) pp. 5, 4.3.22 Infinity, line. Is `Infinity' set in the correct typeface? The values true and false=20 are set differently in 4.3.13. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.1) It appears that "undefined behavior" is not defined anywhere. =20 >>>>>> Action: Not accepted --- The committee feels that these=20 terms are well defined outside of this standard. <<<<< U6.2) Missing definitions: client-server architecture and client-side >>>>>> Action: Not accepted --- The committee feels that these=20 terms are well defined outside of this standard. <<<<< Section 5 - Notation Conventions =20 N15) Section 5.1.2 (ma) . . It defines a set of productions starting from the goal symbol=20 _Input_. that . . .=20 -- This symbol cannot be found in section 7.=20 Common programming languages do not need full parsers for analyzing=20 the lexical structure of a program text. The set-up of this parser=20 cannot be determined because the structure of the grammar is unclear. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N16) Section 5.1.2 (mi) A multi-line comment is likewise simply discarded if it contains no=20 line terminator: but . . . -- it is unclear how a _multi-line_ comment cannot contain a line=20 terminator (but see also a later comment) =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N17) section 5.1.4 (mi) . if an end-of-line character ___ -- is an end-of-line character=20 equivalent to a line terminator? =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.22) pp. 8, 5.2 Algorithm conventions, heading. Upcase C in `conventions' to match all other level-2 heads. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.11) Subclause 5.2: Remove paragraph 1, "We often use ..." Replace "X is Y" with wording that uses "shall". =20 >>>>>> Action: Accepted --- Wording has been changed to remove use of=20 "we". Use of 'shall' is not accepted due to the scope of the changes=20 required. <<<<< =20 J-E9 & U1.23) 5.2 In the last sentence of the third paragraph,=20 "mustbe" should be "must be." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.21) pp. 6, 5.1.5 Grammar Notation, line -7. Change `recursive, that is to say' to `recursive; that is'. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 =20 Section 6 - Source Text =20 D4) clause 6: change ASCII to ISO/IEC 6464 IRV. Four hexadecimal=20 digits are too little to represent UCS characters of ISO/IEC 10646-2=20 (planes outside BMP). =20 >>>>>> Action: Partial acceptance --- Reference changed to ISO/IEC=20 646 IRV <<<<< =20 U4.5) On p. 9, Section 6, they describe the use of Unicode in comments=20 and string literals. We program in English and seldom use Unicode, I=20 would want to be sure that others feel that the approach here is=20 consistent with other programming languages and the intended use of=20 Unicode. =20 >>>>>> Action: Partial acceptance --- Please see section on=20 Character Related Issues above. <<<<< =20 U6.12) Clause 6: ASCII is mentioned but no reference in the References clause. An ISO standard should be referenced rather than the ASCII standard. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 =20 Section 7 - Lexical Conventions =20 D5) Clause 7: strictly speaking control characters are defined in=20 ISO/IEC 6429. =20 >>>>>> Action: Not accepted --- Please see section on Character=20 Related Issues above. <<<<< =20 U1.24) pp. 9, 7 Lexical Conventions, line 1. The source text of a[n] ECMAScript program ... =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.25) pp. 9, 7 Lexical Conventions, line 2. A token is a sequence that comprise[s] ... =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.26) pp. 9, 7.1 White Space, line 2. ... each other[,] but ... =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.27) pp. 10, 7.2 Line Terminators, line 1. Replace =20 ``Line terminator characters, like white space characters, are used to=20 improve source text readability and to separate tokens (indivisible=20 lexical units) from each other. Unlike white space characters, ...'' =20 with =20 ``Like white space characters, line terminator characters are used to=20 improve source text readability and to separate tokens (indivisible=20 lexical units) from each other. However, unlike white space=20 characters, ...'' =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.13) Subclause 7.2: Line terminators should include the Next Line character (I think is it=20 0x84 or 0x85). =20 >>>>>> Action: Not accepted -- ECMAScript follows Java precedent. =20 <<<<< =20 N18) Section 7.3 (mi) The description is unclear about Line terminators in Multi-line=20 comments =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N19) Section 7.3 (mi) The production for MultiLineNotForwardSlashOrAsteriskChar :: SourceCharacter but not forward-slash / or asterisk * seems to be better written as: SourceCharacter but not ( forward-slash / or asterisk * ) This case occurs more often. =20 >>>>>> Action: Partial acceptance --- Would require substantial change=20 to notation; existing production has been clarified. <<<<< =20 U4.6) On p. 10-11, Section 7.3, the syntax for comments seems more=20 complicated than necessary, particularly when things like special=20 Unicode characters are described earlier. Is this the way the similar=20 syntax is done in C or C++? =20 >>>>>> Action: Not accepted --- The committee agreed that the=20 current syntax is correct. <<<<< =20 U6.14) Subclause 7.3.3: Bullets on page 26: exponents appear in font too small. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U4.7) On pp. 11-12, Sections 7.4.2 and 7.4.3, keywords and future=20 reserved words, it is not clear whether the case of the characters is=20 significant. I thought ECMAScript was case sensitive, but I didn't see=20 that mentioned. =20 >>>>>> Action: Not accepted -- The standard makes it clear elsewhere=20 that ECMAScript is case-sensistive. <<<<< =20 E2) 7.4.3 Reserved words The following keywords are reserved in at least one implementation and=20 should be included as future reserved words: abstract boolean byte=20 char double final float goto implements instanceof int interface long=20 native package private protected public short static synchronized=20 throws transient volatile =20 >>>>>> Action: Accepted --- Requested text has been added <<<<< D6) 7.5: DOLLAR SIGN should not be in the identifier list, according=20 to recommendations in TR 10176. 7.5 should refer to the "i18n"=20 specification of ISO/IEC 14652 for definitions of letters and digits. =20 >>>>>> Action: Partial acceptance --- ECMAScript follows Java=20 precedent. A comment will add that $ should only be used for=20 mechanically-generated code. <<<<< =20 U1.28) pp. 13, 7.7.3 Numeric Literals, line -4. ``... ideally using IEEE 754 round-to-nearest ...'' The word `ideally'=20 doesn't sound like good standard's language. What's the implication if=20 the implementer doesn't use this? >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.29) pp 15, 7.7.3 Numeric Literals, line 7. The use of nested parentheses is rather unusual. How about replacing =20 ``A digit is significant if it is not part of an ExponentPart and=20 (either it is not 0 or (there is a nonzero digit to its left and there=20 is a nonzero digit, not in the ExponentPart, to its right)).'' =20 with =20 ``A digit is significant if it is not part of an ExponentPart and -- either it is not 0 or, -- there is a nonzero digit to its left and there is a nonzero digit, not in the ExponentPart, to its right.'' >>>>>> Action: Accepted --- Document corrected <<<<< =20 E3) 7.7.3 Numeric literals This section does not define precisely what is meant by hexadecimal=20 and octal literals that result in Mathematical Values that are larger=20 than can be accommodated in a IEEE double. Since octal and=20 hexadecimal literals only make sense when used in conjunction with=20 bitwise operators, which operate on unsigned 32 bit integers, it would=20 make sense to limit octal literals and hexadecimal literals to=20 specifying unsigned 32 bit integers. =20 >>>>>> Action: Not accepted --- No limit will be used <<<<< D7) in 7.7.4 UnicodeEscapeSequence should be renamed=20 UcsEscapeSequence. Care should be taken that all UCS characters (31- bit) can be handled, e.g. in UcsEscapeSequencee, HexEscapeSequence,=20 and OctalEscapeSequence. >>>>>> Action: Not accepted --- Current text will be used for=20 compatibility. <<<<< =20 J-E1O) 7.7.8 In the last paragraph, last part parenthesis of the=20 second sentence, "(in the sense defined in section 8.4)", the referred=20 section number should be "8.5." Also, in OctalIntegerLiteral :: 0 OctalDigit OctalLiteral OctalDigit OctalLiteral" should be 'OctalIntegerLiteral." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N20) Section 7.8.1 (ed) The notion of 'the header of a for statement' has not been defined. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.30) pp 18, 7.8.1 Rules of automatic semicolon insertion, line 14. Replace ``These are all the restricted ...'' to ``These are the only=20 restricted ...'' =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 Section 8 - Types U1.31) pp. 19, 8 Types, line 2. Strike `called' and put the list ``Reference, List, and Completion''=20 in parens as for the six standard types in the line above. >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.32) pp 19, 8.3 The Boolean Type, line 1. Replace =20 ``The Boolean type represents a logical entity and consists of exactly=20 two unique values. One is called true and the other is called false.'' =20 with =20 ``The Boolean type represents a logical entity having two unique=20 values, called true and false.'' =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.33) pp. 20, 8.5 The Number type, line 7. Instead of ``... all NaN values are the same.'' might it be better to=20 say that ``... all NaN values compare equal''? =20 >>>>>> Action: Accepted --- Indistinguishable will be used in new=20 wording. <<<<< U4.8) On p. 20, Section 8.5 (and then other pages and sections), the=20 number type is described in terms of IEEE 754. (Isn't there an ISO/IEC=20 number for this standard?) In Section 11.5.3, they have some=20 differences in the % operator. There has been some discussion about=20 how this standard is used in Java. I would hope that things are done=20 appropriately here. The use in this proposed standard (and in Java and=20 other languages) might motivate a review of IEEE 754. >>>>>> Action: Partial acceptance --- Reference to IEEE 754 will be=20 changed to IEC 559:1993. Use of the % operator is as intended. <<<<< =20 N22) Section 8.6 (mi) Each property consists of a name. a Value and a set of attributes.=20 This seems inconsistent with section 4.2 =20 >>>>>> Action: Not accepted --- 4.2 is a non-normative overview and=20 therefore simplifies. <<<<< =20 U1.35) pp. 21, 8.6.2 Internal Properties and Methods, line -2. ... implement[ation]-dependent ... =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.34) pp. 21, 8.6.2 Internal Properties and Methods, line 4. Add ``, respectively'' to the end. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.36) pp. 22, 8.6.2 Internal Properties and Methods, line -7. Re `it is used internally ...', is the subject `it' referring to the=20 value of a [[Class]] property? It's probably worth naming the subject=20 explicitly. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E11) 8.6.2.3 The item7., "Return Result(4)"should be "Return=20 Result(6)." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E12) 8.7 in 4 the paragraph, "A Reference consist of two parts, the=20 base object and the property name" should be clarified such as "A=20 Reference consists of two components, the base object and the property=20 name" so that the "part" is actually the "component." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E13) 8.7.4 In the item 6, there should be a forward reference to=20 section 10.1.5 for the newly appeared undefined term, 'global object." =20 >>>>>> Action: Accepted --- Accepted as a helpful clarification. =20 <<<<< =20 J-E14) Section reference. There are three types of section reference=20 in parentheses (see section x.y.z), (section x.y.z), and (x.y.z). It=20 would be consistent and much better to use the one style instead of=20 mixing various formats. =20 >>>>>> Action: Accepted --- Document corrected <<<<< N21) Section 8.8 (ed) There are six standard types . . In section 4.2 these are called=20 built-in types. >>>>>> Action: Accepted --- Wording will be changed. <<<<< =20 J-E15) 8.9 In "abrupt completion," the word "completion" should also=20 be italicized. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 Section 9 - Type Conversion =20 J-E16 & N23) 9.1 In the column of Object, "(see section 8.6.2.5)"=20 should be "(see section 8.6.2.6)." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 E4) 9.3.1 StrWhiteSpaceChr This does not handle Unicode strings that use white space characters=20 other than ASCII. The definition of this should be changed to=20 correspond to the definition of isWhiteSpace in the Java class=20 library. =20 >>>>>> Action: Not accepted --- This will be considered for a=20 future version of ECMAScript. <<<<< J-E17) 9.5 In the step 6, "Result(5)" should be "Result(4)." 918=20 10.1.l and many other sections. There are two formats for=20 "implementation dependent"; with and without a hyphen. It would be=20 better to define the technical term "implementation-dependent" and use=20 it throughout the document. >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.37) pp. 30, 9.8 ToString, line 1. Re `attempts', what happens if it cannot convert its argument? I see=20 no provision for the generation of a runtime error (like 9.9 provides=20 on conversion failures). =20 >>>>>> Action: Accepted --- Use of 'attempts' will be removed. =20 <<<<< =20 D8. clause 9.8.1 the Gay 1990 algorithm needs to be spelled out=20 completely, for portability. =20 >>>>>> Action: Partial acceptance --- The algorithm will be included=20 to avoid the need for a reference. <<<<< =20 =20 Section 10 - Execution Contexts =20 N24) Section 10 (ed) When control is transferred to ECMAScript executable code, we . . The=20 use of `we' is not common in standardization documents. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N25) Section 10.1.1 third bullet (ed) . ..The use of these attributes are described . . .is described, is=20 probably intended here. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.15) Subclause 10.1.1 Change to standards wording "which we refer to ..." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E19) 10.2.4 In the 4th bullet, "object object" should be "object." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.38) pp. 33, 10.1.3 Variable instantiation, lines 1-2. Remove extra vertical space between these lines. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.39) pp. 33, 10.1.3 Variable instantiation, lines 6-7. Remove extra vertical space between these lines. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.16) Subclause 10.1.3 Vertical white space after first sentence -- remove it =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 E5) 10.1.6 Activation Object, and 15.3 Function Objects The arguments property of Function instances should be deleted instead=20 of discouraged. The way it is defined now is over-specified and=20 thread-unsafe. It neither makes sense for future implementations=20 (which may implement threads) nor describes existing practice. =20 >>>>>> Action: Accepted --- Document corrected <<<<< Section 11 - Expressions =20 E6) 11.2 Left-Hand-Side expressions The grammar should not allow nonsensical expressions such as new new=20 foo(), and should not accept Function calls and new expressions on the=20 left-hand-side of an assignment. =20 >>>>>> Action: Not accepted --- There are valid reasons for the=20 rules. <<<<< J-E20) 11.2.3 In the item 2, "section 0" should be "section 8.8." >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-M2) .-From the syntactic rules of 11.4 and 11.5, we can produce not=20 well defined arithmetic expressions such as "-3*-2." =20 >>>>>> Action: The semantics for these expressions is defined by=20 operator precedence rules. <<<<< =20 E7) 11.4.1 The delete operator Step 2 will generate a runtime error if Result(1) is not a reference.=20 This does not appear to be the intent, as in Step 4 GetBase always=20 returns an object (if it returns at all), hence this test is redundant=20 and in Step 5, Objects are required to implement the [[Delete]]=20 method, hence this test is redundant. =20 >>>>>> Action: Accepted --- Will be changed to implementation=20 dependent. <<<<< U1.40) pp. 44, 11.7.1 The left shift operator (<<), line 1. Replace both occurrences of `argument' with `operand'. >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.41) pp. 44, 11.7.2 The signed right shift operator (>>), line 1. Replace both occurrences of `argument' with `operand'. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.42) pp. 45, 11.7.3 The unsigned right shift operator (>>>), line 1. Replace both occurrences of `argument' with `operand'. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 D9) clause 11.9.3 should refer to ISO/IEC 14651 for the complex=20 sorting. We propose that ECMAScript does include a more complex string=20 comparison conforming to ISO/IEC 14651. =20 >>>>>> Action: Not accepted --- This can be considered in a future=20 version. <<<<< =20 N26) Section 11.11 (ed) 6 Call GetValue((Result(5)) Bracket mismatch =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 =20 Section 12 - Statements =20 N27) Section 12.2 (ed) The reference to section 0 seems incorrect. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 E8) 12.2 Variable statement Globals explicitly declared with var should be marked DontDelete. =20 >>>>>> Action: Accepted --- Document corrected <<<<< E9) 12.2 Variable statement, evaluation of Identifier Initializer Step 1 is incorrect: Identifier is not a syntax rule, hence it does=20 not make sense to evaluate it. The intent seems to be "Evaluate=20 Identifier as if it appeared in a PrimaryExpression : Identifier=20 production, see section 11.1.2." However, this could lead to strange=20 behavior when variable declarations appear inside with statements. A=20 betterformulation is "Construct a value of type Reference whose base=20 object is the next activation object on the scope chain and whose=20 propertyname is the Identifier." Step 5 should then be: "Return=20 Result(1)." >>>>>> Action: Partial acceptance --- The concept of this comment=20 is accepted. Exact wording will provided by the committee. <<<<< J5) Ambiguous Syntactic Rules 12.5 The IF statement The following sentence is mandatory just below the syntax rules:=20 'else' shall associate with the nearest 'if among 'if's in the same=20 block (excluding those 'if's which are contained in the inner blocks)=20 that precedes the 'else'? and has no corresponding' ?else'. (The sentence is borrowed from the C language standard.) Without such a sentence the syntax remains ambiguous, since one cannot=20 tell whether if(a=3D=3Db) if(c=3D=3Dd) x=3D 1; else x=3D2; means (1) if(a=3D=3Db) {if(c=3D=3Dd) x=3D 1- else x=3D 2;} or (2) if(a=3D=3Db) {if (c=3D=3Dd) x=3D 1.) else x=3D 2; This phenomena has been well known for languages which have both forms=20 of ifO and if0elseO for conditional branching. Pascal may be consulted with this. It goes: The token=20 'else' shall not occur next to any if-statement which has no 'else'=20 corresponding to its 'if'. >>>>>> Action: Accepted --- Document corrected by adding additional=20 wording. <<<<< =20 N28) Section 12.5 (mi) The syntax given here allows for so-called dangling else problems.=20 These seem not to be resolved. =20 >>>>>> Action: Accepted --- Document corrected by adding additional=20 wording. <<<<< =20 E10) 12.6.3 The for..in statement, evaluation of for(var ...) Step 7 is not needed, provided that the definition=20 ofVariableDeclaration is fixed appropriately, and similarly Step 8 can=20 then use "Result(1)". =20 >>>>>> Action: Accepted --- Document corrected <<<<< U1.43) pp. 55, 12.7 The CONTINUE Statement, line 4. Re ` ... may not be executed ...' The use of `may' in a formal=20 specification can be troublesome, especially when used with the=20 negative. Specifically, does `may not' mean `might not' or does it=20 mean `shall not'? One imposes conformance requirements while the other=20 doesn't. >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.44) pp. 55, 12.7 The CONTINUE Statement, line 5. Replace `at least one' with `a'. It seems to me that the number of=20 nested while or for statements is irrelevant. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.45) pp. 55, 12.8 The BREAK Statement, lines 4 and 5. See the comments for CONTINUE above. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.46) pp. 55, 12.9 The RETURN Statement, lines 4. See the first comment for CONTINUE above. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.17) Subclauses 12.8, 12.9, 12.10: These subclauses refer to a program as "syntactically incorrect", but=20 the corresponding behavior is not clear: what happens when the program=20 fails. Furthermore, this response to bad syntax should be defined=20 early in the document, say, in the Conformance clause. =20 >>>>>> Action: Not accepted --- Error behaviors are described in=20 section 16. <<<<< =20 Section 13 - Function Definition =20 J-E21) 13 In the first paragraph, "the Identifier" is ambiguous in the=20 sense whether it is in the FunctionDeclaration, or in the=20 FormalParameterList. It should be clarified such as "the function=20 Identifier." =20 >>>>>> Action: Accepted --- Section will be changed to clarify=20 meaning. <<<<< =20 =20 Section 14 - Program =20 N29) Section 14 (ed) . 1. Process SourceElements for function declarations .. From the description given, it can't be determined whether this needs=20 to be done left to right or right to left. 1. Evaluate SourceElements. .... . 4. Return Result(1) It is unclear whether the result of step 4 is the result of the first=20 term or of the last term of (1). On two occasions 'is' is printed in italics.=20 On one occasion `is' is written without preceding space. =20 >>>>>> Action: Partial acceptance --- Type style and spacing changes=20 will be made. The committee feels the current wording is clear. .=20 <<<<< =20 =20 Section 15 - Native ECMAScript Objects =20 E11) 15.1 The Global Object The standard should outlaw calling the global object's eval method=20 indirectly. In particular, programs should not extract the global=20 object's eval property except when calling it directly, or assign to=20 the global object's eval property. =20 >>>>>> Action: Accepted --- Document corrected <<<<< D10) clause 15.1.2.4: RFC1738 should be spelled out, it is not very=20 complicated and thus a non-de jure reference can be removed. "ASCII"=20 should be replaced by ISO/IEC 646 IRV. escape() and unescape() should=20 be applicable to 31-bit UCS values. >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E22) 15.1.2.4 In the item 7, "nonblank ASCII characters" should be=20 "nonblank characters. " It should be irrelevant whether they are ASCII=20 or not. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U4.9) On p. 60, Section 15.1.2.4 (escape string), it's not clear why a=20 different format is being used. There also seems to be over=20 specification of some of the rules in this and surrounding sections. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 N30) Section 15.1.3.5 (ed.) (ed)) . 15,6,2. Commas? =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 E12) 15.2.4.2 Object.prototype.toString() This conversion could result in a runtime error, which does not seem=20 to be the intent here. If [[class]] is required to be a string, this=20 conversion is not needed. =20 >>>>>> Action: Accepted --- Change will be made in section 8.6.2. =20 <<<<< =20 E13) 15.4.2.2 new Array(len) This constructor constructs a very large array if given an argument=20 such as -1. The language of the new Array(len) constructor should be=20 changed to require that ToInteger(len) be between 0 and 2^31-1,=20 inclusive; if len is a number outside this range, new Array(len)=20 should signal an error. The same applies to setting the "length"=20 property of an array via [[Put]]. =20 >>>>>> Action: Partial acceptance --- Document changed to reflect a=20 limit of 2^32-1 <<<<< U1.47) pp. 68, 15.4.4 Array.prototype.sort(comparefn), line -6. Replace `compared' with `compares'. >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E23) 15.4.4.4 In the first paragraph and in the item l, the term,=20 "this object," appears which causes some confusion whether "this" is a=20 special "this" or not. Use "the object" or "the array object" to avoid=20 the misleading. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 D12) clause 15.4.4.5. String.prototype.charCodeAt() shall return a=20 integer less than 2**31. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E24) 15.4.4.5 In the first paragraph, the second sentence, "The sort=20 is not necessarily stable." may cause misunderstanding to whom those=20 do not have expertise in the sorting. The precise meaning of the word=20 "stable" should be added or explained. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 E14) 15.4.4.5 Array.prototype.sort(comparefn) Step 3, last paragraph: the phrase "and the result of applying=20 ToNumber to this value is not NaN" is not necessary and creates the=20 erroneous impression that the compare function need not return a=20 number. See earlier "If comparefn is provided, it should be a=20 function that accepts two arguments x and y and returns a negative=20 value if x < y, zero if x=3D y, or a positive value if x > y." While=20 "value" is not a specific as "number", it seems unlikely that the=20 intent was that "negative value" be shorthand for "a value which can=20 be converted to a negative number". =20 >>>>>> Action: Accepted --- Concept of this change is accepted. =20 <<<<< E15) 15.4.5.1 [[Put]](P, V) Array instances always have a length property, hence the first test in=20 Step 9 is not needed. >>>>>> Action: Accepted --- Document corrected <<<<< D11) clause 15.5.3.2: UCS characters are 31 bit, not 16 bit. The right=20 function to call is ToUint32(). >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E25) 15.5.3.2 In the first sentence, "asthe" should be "as the." =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 E16) 15.5.4 Properties of the String Prototype Object, final paragraph The phrase "it is a runtime error if this does not refer to an object=20 for which the value of the internal [[Class]] property is 'String'."=20 should be deleted. It contradicts the note at the end of section=20 15.5.4.4 and as well as the implicit intent. =20 >>>>>> Action: Accepted --- Document corrected <<<<< E17) 15.5.4.4 and as well as the implicit intent. >>>>>> Action: Not accepted --- Numbering error in ECMA comments.=20 This text was a part of the above comment. <<<<< D13) clause 15.5.4.11 and 15.5.4.12 Needs to refer to ISO/IEC 14652=20 specifications in the "i18n" fdcc-set for upper and lowercase=20 equivalences, instead of Unicode values. >>>>>> Action: Accepted --- Document corrected <<<<< U4.10) On p. 76, Section 15.7.3.2 (Number.MAX_VALUE) starts "The value=20 of Number.MIN_VALUE ..." >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.48) pp. 77, 15.8.1.5 LOG10E, line 2. Re ``(Note that the value of Math.LOG2E is approximately the=20 reciprocal of the value of Math.LN2.)'' =20 I'm no mathematician, but I'm guessing that this section was cloned=20 from 15.8.1.4, and that it should read as follows instead: =20 ``(Note that the value of Math.LOG10E is approximately the reciprocal=20 of the value of Math.LN10.)'' =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U1.49) pp. 77, 15.8.2 Function Properties of the Math Object, line -2. Re `[XXXREF]', is a cross-reference missing here? >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-M1) 15.8.2.11 & 15.8.2.12 The behavior in the case that argument x is equal to y is not=20 specified. >>>>>> Action: Accepted --- Document corrected <<<<< =20 J-E26) 15.9.1.1 In the 4th sentence, constants "iMin" and "iMax"=20 appear as if they are ECMAScript constants. However, it looks just a=20 convention in this place, and not used anywhere else. Avoid these=20 constants. =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.18) Subclause 15.9.1.1: Reword "This span easily covers all of recorded human history ..." as=20 specific year numbers in the common era (A.D.) and before the common=20 era (B.C.). =20 >>>>>> Action: Accepted --- Document corrected to remove "iMin" and=20 "iMax". <<<<< =20 U6.19) Subclause 15.9.1.3, para 2: Remove/reword "Of course" =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 D14) clause 15.9.1.4: month numbers should be numbered from 1 to 12.=20 This is analogeous to date number in 15.9.1.5 and conforming to ISO=20 8601. =20 >>>>>> Action: Not accepted --- The committee has chosen to the=20 maintain the current text in order to maintain compatibility with=20 current practice. A new function could be considered for a future=20 version. <<<<< =20 D15) clause 15.9.1.6: week day numbers should be numbered from 1 to 7=20 as argued in comment 14. =20 >>>>>> Action: Not accepted --- The committee has chosen to the=20 maintain the current text in order to maintain compatibility with=20 current practice. A new function could be considered for a future=20 version. <<<<< =20 J4.2 Local time and daylight saving time {15.9.1.7 and 15.9.1.8} The ECMA-262 have a concept of daylight saving time and functionality=20 to convert local time with daylight saving time to UTC. However,=20 without having any good mechanism the one to one correspondence=20 between local time and UTC can not be guaranteed. Let's assume that at=20 2:00 of September lst, the local time will be back to l:OO. In the=20 case, 1:30 of September lst should be converted to what value in UTC?=20 Until no good mechanism is provided, this standard should not support=20 local time and daylight saving time. Again, there is no problem from=20 the view point of backward compatibility and conformance.=20 Implementation can provide those functions as extensions. UTC support=20 would be good enough for this standard. If further revision of this=20 standard introduce the concept of locale, the local time support=20 should be specified with a mechanism of daylight saving support, at=20 that time. =20 >>>>>> Action: Not accepted -- Locale awareness is out of scope of=20 the current standard. Also see section on Year 2000 issues above.=20 <<<<< =20 D16) clause 15.9.1.8: refer to ISO/IEC 14652 for a possible reference=20 to information on daylight savings. =20 >>>>>> Action: Not accepted -- Out of scope of the current standard.=20 This will be implementation-defined. <<<<< =20 N31) Section 15.9.1.8 (ed) . . /t.... ?? =20 >>>>>> Action: Accepted --- Document corrected <<<<< =20 U6.20) Subclause 15.9.1.8: Reword "by whatever means available" as standards words=20 ("implementation-defined"? -- but this would require defining=20 implementation defined). Paragraphs 2 and 3: It is not clear what the required behavior is for=20 a conforming implementation. =20 >>>>>> Action: Accepted --- Corrected wording has been added.=20 <<<<< =20 D17) clause 15.9.1.12 and 15.9.2: please note that year is currently a=20 four-digit integer. =20 >>>>>> Action: Not accepted -- The definitions do not require a 4- digit year. <<<<< =20 D18) clause 15.9.3.1-7: the result rules for year<99 makes it hard to=20 talk about things at the time of the birth of Jesus Christ - it should=20 be removed. The easiness it gives for dates in this century are not so=20 useful just a couple of years from now. This is not a foolproof rule. =20 >>>>>> Action: Not accepted -- Would break many thousands of existing=20 programs. <<<<< =20 E18) 15.9.5.34 setMonth and 15.9.5.34 setUTCMonth Step 2 of the algorithm should refer to 'mon', not 'date'. =20 >>>>>> Action: Accepted --- Document corrected <<<<< D19) clause 15.9.5.39: refer to ISO/IEC 14652 for specifications of=20 date formatting, and ISO/IEC 15897 for references to different=20 locales. >>>>>> Action: Not accepted --- Complete solution to this problem=20 has been determined to be outside the scope of this committee.=20 Results will become implementation dependent. <<<<< =20 =20 =20 Section 16 - Errors =20 U6.21) Clause 16: This clause should be moved to the beginning and, possibly,=20 incorporated in the Conformance clause. =20 >>>>>> Action: Not accepted -- This is not a conformance item. <<<<< =20 ______________________ end of SC22 N2745 _________________________