From rinehuls@access.digex.net Tue Nov 17 23:36:31 1998 Received: from access1.digex.net (qlrhmEbBUV1EY@access1.digex.net [205.197.245.192]) by dkuug.dk (8.8.7/8.8.7) with ESMTP id XAA26747; Tue, 17 Nov 1998 23:36:10 +0100 (CET) (envelope-from rinehuls@access.digex.net) Received: from localhost (rinehuls@localhost) by access1.digex.net (8.8.4/8.8.4) with SMTP id RAA22917; Tue, 17 Nov 1998 17:35:59 -0500 (EST) Date: Tue, 17 Nov 1998 17:35:59 -0500 (EST) From: "william c. rinehuls" To: sc22docs@dkuug.dk cc: keld simonsen Subject: SC22 N2843 - Minutes and Recommendations from JSG October Meeting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII __________________ beginning of title page _____________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2843 TITLE: Minutes and Recommendations from the SC22/JSG Meeting on October 26-27, 1998 in Tokyo, Japan DATE ASSIGNED: 1998-11-17 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: SG Minutes PROJECT NUMBER: N/A STATUS: N/A ACTION IDENTIFIER: FYI DUE DATE: N/A DISTRIBUTION: text CROSS REFERENCE: N/A DISTRIBUTION FORM: Open 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 minutes _________________ Minutes of Java Study Group Meeting, October 26-27, 1998 in Tokyo, Japan Opening Remarks Because the meeting was attended by only two national body delegations, there are only recommendations and no resolutions. Minutes 1. Conformance of Java standards - such as Multiple levels of conformance (A. Kido, N3-3 and N3-4) Discussion: There may be multiple levels of conformance, as proposed in N3-4. Question: What happens to applications when the features assumed available are not available? Answer: An important question not yet solved. Comment: In US, NIST real-time group addressed extensions and Sun concluded that the only possible action, when resources were not available, was to "exit ungracefully". 2. Subsetting / Profiling Discussion: Presentation, "ISO Java Standardization Profile" by M. Uchiyama, and proposal N3-6 for subsets and Java profiles, including JLS (Java Language Specification), JVM (Java Virtual Machine Specification), JAPI (Java API Specification). The basic idea of a proposed profiling scheme is the concept of "level" and "category". "Level" allows systems without VM and/or some APIs. Level 3 should be equivalent to JDK. "Category" includes correspondents of specifications such as Personal Java, Embedded Java and Java Card. A matrix based on level and category gives a taxonomy of profiles, which are conforming subsets. Each subset would be a part of ISO Java, e.g., JLS ==> ISO Java, Part 1; JVM ==> ISO Java, Part 2; JAPI ==> ISO Java, Part 3. 3. Embedded systems / real-time issues Discussion: Presentation by Tom Plum http://www.raleigh.ibm.com/maillists/rt-java http://www.nist.gov/rt-java To join, send E-mail to majordomo@raleigh.ibm.com with message: subscribe rt-java Upcoming events: * Demo at Embedded Systems 98, week of 1998-11-02, Santa Clara, CA, USA * Requirements Group - "Open" - NIST, next meeting on 1998-12-08 / 1998-12-09 at Chelmsford, MA, US * "Real-Time Extensions to the Java (tm) Platform" - Sun's "Open Process" Expert's Group. Sun requires signing a Non-Disclosure Agreement and a License Agreement to be part of the "Open Process". Generating a requirements document, not a standard. 4. Overview of JIS/TR (Technical Report) (Y. Komachi) Discussion: JIS Technical Report types. Similar to JTC1 Technical Report types. Issue: How does is the copyright legality compatible with US and European laws. Issue: Does Sun have any objection to this? 5. Floating Point Computation (Sun's proposed changes and other work) (Roger Golliver and others) Discussion: Report on Sun floating point proposal -- proposal not ready yet Discussion: Report on a new algorithm to produce "strict" orthogonal IEEE results on extended IEEE architectures (IA-32). Contact roger for details or pass on pointer to interested JIT/JVM developers. Discussion: Java Grande group's efforts to address needs of scientific and engineering uses of Java. Complex arithmetic, relaxation of evaluation rules for higher optimization of fp codes, and High-Performance Java (like HP Fortran). 6. Native Compilation (Salil Pradhan, HP, USA) Discussion: Presentation from HP on static compilation systems. Motivation: users want this, works with existing development systems. Issues: Range checking, it is possible to take advantage of hardware facilities? 7. Handling of Fully Internationalized Character Code - Support of entire repertoire of ISO/IEC 10646 Presentation by Akio Kido, IBM Japan, Ltd. Discussion: Supporting 32-bit characters, as required by ISO-IEC 10646. Current Java characters are 16-bits. Do not specify encoding scheme and size of character data type in the Java language standard, make it processor defined. Mapping between the character datatype in the Java language and Java ByteCode should be done in a processor defined manner. In the other words, the implementation which support full repertoire of ISO/IEC 10646 should have the character data type whose size is more or equal to 31 bits and handle character data character by character not 16-bit by 16-bit. The operation may be translated into multiple Java ByteCode statements where the character data is stored as UTF-16 encoding. Possible change to Java: Amend the current specification of Java 1.1 and make the size and encoding of character datatype as UCS4 encoding in all Java standards including Java language, Java ByteCode, and Java API. Another possible change to Java: Stay the current specification of character datatype as it is, i.e. UCS2, and: * allow to store UTF-16 into the string object; * provide new methods to detect character boundary in the string object; * provide new character manipulation method that handle character data in the string object character by character, not by 16bit unit; * provide new "CHARACTER" datatype and "STRING" class which value space is entire repertoire of ISO/IEC 10646 and which encoding is UCS4; * provide set of functions to convert string object which encoding is UTF-16 to the new "STRING" object that encoding is UCS4, and vise versa. Discussion: The current Java specification has some problems in non-BMP plane support. The primitive character data type "char" can't store UCS-4 data directly because its values are 16-bit unsigned integers. Although the Unicode Standard 2.0 supports surrogate pairs (UTF-16), there are the following problems in the Java specification. * Unicode escapes (e.g., \uFFFF) don't support UCS-4 representation. * Almost all methods in java.lang.Character class don't process surrogate pairs as one character. * Because The "CONSTANT_Utf8" format in class files isn't the standard UTF-8 format, surrogate pairs don't convert correctly. Recommendation: ISO Java standard should support non-BMP planes in UCS-4. For example, additional ideographs will be added to plane 2 in ISO/IEC 10646. Those characters are necessary for reading/writing Japanese documents. Discussion: Whereas, one of important application area of Java is World Wide Web, and in the WWW environment, character encoding of text object in digital documents should be transparent from end user, since the character encoding may be converted from one to another during the data transfer from server to client, or may vary from a Web page to another, and whereas a CC data element, such as Latin capital character "A" with acute accent may be represented by a precomposed character in an encoding, but may be represented by a combining sequence in other encoding, therefore, Java standard may need to have a set of functionality to access to the CC data element in a character string. ISO/IEC 10646 and some other ISO/IEC coded character standards specify combining characters and composite sequence as well as pre-composed form of character. For example, a glyph Latin Alphabet Capital Letter A with Acute may be represented by LATIN CAPITAL LETTER A WITH ACUTE (u00C1) and/or the sequence of LATIN CAPITAL LETTER A (u0041) followed by COMBINING ACUTE ACCENT (u0301). Considering the above duplicate representation of a CC data element, the World Wide Web Consortium (W3C) is now working to establish "Character Model in the Web" and has published requirement document as a technical report: http://www.w3.org/TR/1998/WD-charreq-19980710 In the document, the W3C mentioned about the requirement on the CC data element level comparison regardless of the character representation difference of a CC data element. To achieve the CC data element level comparison, normalization of ISO/IEC 10646 (Unicode) string may be required as a pre-handling of the comparison. Also, the Unicode consortium is working on the normalization technique of Unicode string; see: http://www.unicode.org/unicode/reports/tr15/ The question is whether such CC data element level access should be done at application layer by using existing Java API with hardcoding of Unicode values in the application, or a set of new Java API which enables the access to the CC data element in a Java string object should be provided as standard API of the ISO Java standard. In the latter case, the following two API may be required. Issues: (1) Convert an un-normalized string object to normalized one. (2) Detect CC data element boundary in a string object. 8. Encoder converter API - the converter esp. for character code should be open to users (Y. Mizutani, and M. Suzuki) Discussion: Missing converters for Java JDK. For example, there are converters for ASCII, UTF-8, but not DBCS -- and the converters have inconsistent behavior. 9. JTRON (Java on TRON) Presentation by Yukikazu Nakamoto of NEC on ITRON Project. Discussion: Real-time vs. embedded systems. 10. Internationalized documents for Java (T. Kimura) Discussion: ISO Java standard should specify a mandatory set of internationalized Java documents and a set of support tools for this document internationalization. In addition, reference implementations of the tools may be recommendable. 11. Closer liaison with PAS Submitter (SMI) (A. Kido) Discussion: Request the convener to request to SC22 to request to JTC1 to establish a C type liaison between SMI and the Java SG, in order to ensure tight cooperation between the possible PAS submitter of ISO Java standards (SMI) and possible responsible standardization body under ISO/IEC JTC1 (Java SG). The cooperation will contribute to establish high quality Java standards in timely manner. The establishment of the liaison could be beneficial for both bodies, for example: * Java SG can provide support to SMI for preparation of Java standard text in the ISO/IEC directives part 3 conforming manner. * In order to maximize approval vote at the PAS ballot, SMI can ask Java SG to review and comments to a portion of a draft PAS text, in advance. * Java SG and member bodies of the Java SG can have a chance to express their opinions. comments, and possible conditions for approval vote to the PAS text, before the submission of the PAS text. * In the case if any controversial problems are found through the pre-review of a draft PAS text, suggested in the second item, Java SG may be able to discuss the SMI and look for a compromise. 12. Possible changes to the PAS process being discussed by JTC1 Discussion: There is little JSG can to directly affect the PAS process. 13. Relationship to other distributed computing standards -- CORBA, COM, WWW, etc. 14. Future Meeting Dates: 1999-05-10 / 1999-05-11 in Hawaii, or alternatively 1999-05-13 / 1999-05-14 in Hawaii _________________ end of minutes; beginning of recommendations _______ RECOMMENDATIONS FROM THE SC22/JSG MEETING on October 26-27, 1998 in Tokyo, Japan Recommendation 1 The Java Study Group requests the convener to ask SC22 to recommend JTC1 establish a category C liaison between expected Java standard PAS submitter SMI, and the Java Study Group to facilitate closer cooperation between those groups. See Java SG N 3-3 http://www.itscj.ipsj.or.jp/eg/documents/jsgn33.txt Recommendation 2 The Java Study Group requests the convener to ask SC22 to recommend JTC1 requests SMI presents its submission in the form specified by ISO/IEC Directives, Part 3; in addition, the conformance requirements should be clearly stated in the text. The Java Study Group is willing to support SMI in preparation of the standard text. See Java SG N 3-4 http://www.itscj.ipsj.or.jp/eg/documents/jsgn34.txt Recommendation 3 Whereas, the Java Study Group recognizes that Java is applied in the areas of real-time and embedded systems; and Whereas, these applications require special features or restricted computer resources; Therefore, the Java Study Group requests the convener to ask SC22 to recommend JTC1 requests SMI to allow any Java specifications proposed through the PAS procedures to have standards profiles. See Java SG N 3-5 http://www.itscj.ipsj.or.jp/eg/documents/jsgn35.txt and N 3-6 http://www.itscj.ipsj.or.jp/eg/documents/jsgn36.txt Recommendation 4 Whereas, ISO/IEC JTC1/SC2 is now developing ISO/IEC 10646-2, and defining characters in planes 1, 2, and 14; and Whereas, those characters can not be represented by UCS2; Therefore, the Java Study Group requests the convener to ask SC22 to recommend JTC1 requests SMI provide a means to support the entire repertoire of ISO/IEC 10646, including characters outside the BMP. See Java SG N 3-7 http://www.itscj.ipsj.or.jp/eg/documents/jsgn37.txt and N 3-12 http://www.itscj.ipsj.or.jp/eg/documents/jsgn312.txt Recommendation 5 Whereas, some current implementations of Java do not implement the entire set of coded character sets converters included in SMI's JDK package; and Whereas, this lack of support is an inhibitor to achieve "write once, run anywhere"; and Whereas, the Java Study Group recognizes that there is a requirement for users and IT vendors to add new coded character set converters; Therefore, the Java Study Group requests the convener to ask SC22 to recommend JTC1 requests SMI: 1) Specify a mandatory set of coded character set converters; 2) Specify the behavior of the mandatory set of coded character set converters; 3) Provide a means for users or implementers of Java specifications to add character set converters; 4) Provide a means for users or implementers of Java specifications to modify the behavior of existing character set converters; 5) Provide a means to determine the availability of supported code sets. See Java SG: N3-9 http://www.itscj.ipsj.or.jp/eg/documents/jsgn309.txt N3-10 http://www.itscj.ipsj.or.jp/eg/documents/jsgn310.txt N3-11 http://www.itscj.ipsj.or.jp/eg/documents/jsgn311.txt N3-14 http://www.itscj.ipsj.or.jp/eg/documents/jsgn314.txt Recommendation 6 Whereas, the Java Study Group recognizes that issues of Recommendation 5 also exist for internationalization-related resources such as locale; Therefore, the Java Study Group requests the convener to ask SC22 to recommend JTC1 requests SMI to specify a mandatory set of internationalization resources similar to Recommendation 5. Recommendation 7 The Java Study Group requests the convener to ask SC22 to recommend JTC1 encourages its national bodies to participate in the real-time and floating point discussions in NIST, http://www.raleigh.ibm.com/maillist/rt-java, and Java Grande http://www.javagrande.org Recommendation 8 The Java Study Group requests the convener to schedule the next Java Study Group meeting on 1999-05-10 / 1999-05-11 in Hawaii, US; or alternately on 1999-05-13 / 1999-05-14 at the same location. Recommendation thanks The Java Study Group thanks to ITSCJ for their hosting of the JSG third meeting. The Java Study Group thanks the drafting committee: Frank Farance of Farance Inc., and Masami Suzuki of Microsoft. The Java Study Group thanks Mariko Takeuchi, Tomomi Haruhana, Junsuke Miyazaki for secretarial, clerical, and logistics help. ___________________ end of SC22 N2843 ________________________________