From owner-sc22docs@open-std.org Mon Sep 6 09:15:25 2004 Return-Path: X-Original-To: sc22docs-domo Delivered-To: sc22docs-domo@ghz.klid.dk Received: by ghz.klid.dk (Postfix, from userid 521) id F0D7A37646; Mon, 6 Sep 2004 09:15:24 +0200 (CEST) X-Original-To: sc22info@open-std.org Delivered-To: sc22docs@ghz.klid.dk Received: from email1.ansi.org (outbound.ansi.org [12.15.192.5]) by ghz.klid.dk (Postfix) with ESMTP id E106D37638 for ; Mon, 6 Sep 2004 09:15:20 +0200 (CEST) Received: by rpb2.nycrnybb.ispnetinc.net with Internet Mail Service (5.5.2653.19) id <3FGJWGVP>; Mon, 6 Sep 2004 03:15:16 -0400 Message-ID: From: Sally Seitz To: sc22info@open-std.org Subject: N 3805-Canadian National Body Report to the SC 22 Plenary Date: Mon, 6 Sep 2004 03:15:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C493E1.41EB7090" Sender: owner-sc22docs@open-std.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C493E1.41EB7090 Content-Type: text/plain ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N 3805 TITLE: Canadian National Body Report to the SC 22 Plenary DATE ASSIGNED: 2004-09-06 SOURCE: Canadian National Body BACKWARD POINTER: DOCUMENT TYPE: National Body Contribution PROJECT NUMBER: STATUS: Pending approval of the addition of this document to the SC 22 Plenary agenda, it will be reviewed under agenda item 7.1. ACTION IDENTIFIER: FYI DUE DATE: DISTRIBUTION: Text CROSS REFERENCE: DISTRIBUTION FORM: open Sally Seitz ANSI 25 West 43rd Street New York, NY 10036 Telephone: (212) 642-4918 Fax: (212) 840-2298 Email: sseitz@ansi.org ___________________________end of cover page, beginning of document_________________________________ Canadian Report to ISO/IEC/JTC1/SC22 Plenary September 2004 Canada Mirrors SC22 with Canadian Advisory Committee JTC1-SC22 (CAC-JTC1-SC22), a member of the Standards Council of Canada. CAC-JTC1-SC22 meets quarterly. Canada is active in WG3 APL, WG5 Fortran, WG9 Ada, WG14 C, WG15 POSIX, WG20 Internationalization, WG21 C++ and the Linux Rapporteur Group. For the 2004 plenary, we raise the following issues. LINUX Resolution 14 from the Tokyo LRG meeting stated that the LRG had completed its assigned tasks. Although there are costs associated with the maintenance of the LRG, there are still numerous issues regarding the standardization of Linux that need further discussion. It has become clear that multiple PAS submissions from the Free Standards Group (FSG) will be needed to add new features and address problems as they arise. For example, see the discussion arising from the following message . This ultimately led to a decision by the FSG to move C++ to a module that will still be required for LSB 2.0 but not submitted to ISO/IEC/JTC1 as part of a PAS submission this fall . Given that the LSB is a binary standard, it is possible that this approach would cause ISO/IEC/JTC1 member countries to reject the PAS submission, or that frequent updates to the whole document will need to be done as soon as the changes to different parts are available, leading to reduced stability of the parent document and reduced acceptance on the part of users of the specification. It is clear that the LSB is too large and unwieldy to be managed as a single standardization unit. It is our opinion that modularization of the document would be useful to address this problem, and to facilitate the review process. We further note that PAS submissions are not subject to the same convergence and formatting requirements as other ISO standards. Normally, it is expected that these issues are addressed as part of the amendment process. It is likely that the LSB 3.0 will be submitted in 2005 to address the shortcomings that have developed with respect to the LSB 2.0, and LSB 4.0 12 months to 18 months later. Following this process, each PAS submission will be obsolete before they come up for renewal, avoiding the JTC1 amendment process and failing to address document issues such as duplicate specification of POSIX interface. To date, JTC1 and SC22 do not have a process to deal with the convergence, compatibility and formatting issues that arise as we try to integrate the LSB into the ISO framework. LRG resolution 12 concerned risk mitigation, specifically recommendation 12.1 urged SC22 to work with the FSG to ensure that emerging technologies are not prematurely specified. This is a difficult problem, particularly when it comes to the standardization of open source software. We are also concerned about the apparent reliance of JTC1 and SC22 upon FSG as the only resource for Linux-based standardization. We note that FSG does not have a mandate to represent the projects within the open source community to standardize. Further, the needs of its membership may not reflect the viewpoint of the open source maintainers. Thus, it is possible that there will be a lack of close cooperation between the FSG and project maintainers in the specification development process. Open source maintainers from the areas covered by the LSB specification were not well represented at either the London LSG or Tokyo LRG meetings. As a result, there was very little discussion of areas of the LSB that might be controversial or premature, aside from POSIX. The problems with C++ have been known for over a year; however, it wasn't until an objection was raised by the C++ library maintainer on the GCC list that any movement occurred in the position of the FSG. SC22 needs to work harder in this area. It is Canada's position that the Linux Rapporteur Group should become a WG with a mandate to develop documents for the Linux Standardization process, to work with the LSB to improve the products being delivered, and to give voice to those important people in the Linux process who are being marginalized by the current process. Failing the formation of a WG, at a minimum the LRG must be continued to report on issues in the following areas: 1) Convergence and formatting of PAS submissions with other ISO standards; 2) Rationalization of the LSB with other standards, such as POSIX, and C++; 3) Modularization of the LSB and other "Linux" standards.; 4) Risk mitigation with respect to future LSB submissions; and 5) Developing policies as to the appropriate pace for updates in an area that is developing rapidly. POSIX It is clear that all attempts to reform WG15 have failed. SC22 has not had a valid report from WG15 in more than 3 years, and it is our understanding that WG15 has not met for more than 3 years and that the convener does not respond to requests for clarification. It is troubling, however, that the Austin Group is continuing to submit documents to JTC1 as though the relationship with WG15 is sound and WG15 is a functioning entity. Furthermore, it is our understanding that some members of WG15 may be attending Austin Group meetings as ISO/IEC/JTC1/WG15 representatives. It is Canada's position that WG15 has ceased to exist as a functioning body, and that all work associated with WG15 reverts to SC22. Furthermore, it is our position that SC22 has no current liaison or participation in the Austin Group, and that either a new relationship must be negotiated, or the Austin Group must be terminated and the Open Group must apply as a PAS submitter to JTC1. WG20 - Internationalization With the moving of the SC22/WG20 ordering project to SC2, participation in person at WG20 has dropped significantly. This concerns us as the need for standardizing i18n functionality is still as significant as it was when WG20 was created, although focus in WG20 has been put from the beginning on sorting. We believe that SC22 should have a TR project in WG20 to survey all functionalities currently in all programming language standards and environment standards (such as POSIX and Linux). Such a project should identify missing functionality and forecast future needs. Such a project would require close coordination with and input from all other SC22 WG's. Sally Seitz Program Administrator ANSI 25 West 43rd Street New York, NY 10036 Phone: (212) 642-4918 Fax: (212) 840-2298 ------_=_NextPart_001_01C493E1.41EB7090 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

ISO/IEC JTC = 1/SC22

Programming languages, their environments = and system software interfaces

Secretariat:  U.S.A.  = (ANSI)

 

ISO/IEC JTC 1/SC22 N 3805

TITLE:

Canadian National Body Report to the SC 22 = Plenary

 

DATE ASSIGNED:

2004-09-06

 

SOURCE:

Canadian National = Body

 

BACKWARD = POINTER:

 

 

DOCUMENT TYPE:

National Body = Contribution

 

PROJECT NUMBER:

 

STATUS:

Pending approval of the addition of this document to the = SC 22 Plenary agenda, it will be reviewed under agenda item = 7.1. 

 

 

ACTION = IDENTIFIER:

FYI

 

DUE DATE:

 

 

DISTRIBUTION:

Text

 

CROSS = REFERENCE:

 

DISTRIBUTION = FORM:

open

 

Sally = Seitz

ANSI

25 West 43rd = Street

New York, NY  10036

Telephone:  (212) = 642-4918

Fax:          &n= bsp;  (212) 840-2298

Email:  = sseitz@ansi.org

 

___________________________end of cover page, = beginning of document_________________________________

         = Canadian Report to ISO/IEC/JTC1/SC22 Plenary =

         = ;    September 2004

 

 

Canada Mirrors SC22 with Canadian Advisory Committee = JTC1-SC22

(CAC-JTC1-SC22), a member of the Standards Council = of Canada.

CAC-JTC1-SC22 meets quarterly. Canada is active in WG3 = APL, WG5

Fortran, WG9 Ada, WG14 C, WG15 POSIX, WG20 Internationalization, = WG21

C++ and the Linux Rapporteur Group. For the 2004 = plenary, we raise the

following issues.

 

 

LINUX

 

Resolution 14 from the Tokyo LRG meeting stated = that

the LRG had completed its assigned tasks. Although = there are costs

associated with the maintenance of the LRG, there = are still numerous

issues regarding the standardization of Linux that = need further

discussion.

 

It has become clear that multiple PAS submissions = from

the Free Standards Group (FSG) will be needed to add = new features

and address problems as they arise.  For = example, see the discussion

arising from the following = message

       = <http://gcc.gnu.org/ml/gcc/2004-07/msg01337.html>.

This ultimately led to a decision by the FSG to move = C++ to a module

that will still be required for LSB 2.0 but not = submitted to

ISO/IEC/JTC1 as part of a PAS submission this fall =

      = <http://gcc.gnu.org/ml/gcc/2004-08/msg00248.html>.

Given that the LSB is a binary standard, it is = possible that this

approach would cause ISO/IEC/JTC1 member countries = to reject the PAS

submission, or that frequent updates to the whole = document will need to be done

as soon as the changes to different parts are = available, leading to reduced stability of the parent document and reduced = acceptance on the part of users of

the specification.

 

It is clear that the LSB is too large and unwieldy = to be managed as

a single standardization unit.  It is our = opinion that modularization

of the document would be useful to address this = problem, and to

facilitate the review process. =

 

We further note that PAS submissions are not subject = to the same

convergence and formatting requirements as other = ISO

standards.  Normally, it is expected that these = issues are addressed as

part of the amendment process.  It is likely = that the LSB 3.0

will be submitted in 2005 to address the = shortcomings that have

developed with respect to the LSB 2.0, and LSB 4.0 = 12 months to 18

months later.  Following this process, each PAS = submission will be

obsolete before they come up for renewal, avoiding = the JTC1 amendment

process and failing to address document issues such = as duplicate

specification of POSIX = interface.

 

To date, JTC1 and SC22 do not have a process to deal = with the

convergence, compatibility and formatting issues = that arise as we try

to integrate the LSB into the ISO framework.  = LRG resolution 12

concerned risk mitigation, specifically = recommendation

12.1 urged SC22 to work with the FSG to ensure that = emerging

technologies are not prematurely specified.  = This is a difficult

problem, particularly when it comes to the = standardization of open

source software.

 

We are also concerned about the apparent reliance of = JTC1 and SC22

upon FSG as the only resource for Linux-based standardization.  We note

that FSG does not have a mandate to represent the = projects within the

open source community to standardize.  Further, = the needs of its

membership may not reflect the viewpoint of the open = source

maintainers.  Thus, it is possible that there = will be a lack of close

cooperation between the FSG and project maintainers = in the

specification development process.  Open source = maintainers from the

areas covered by the LSB specification were not well represented at

either the London LSG or Tokyo LRG meetings.  = As a result, there was

very little discussion of areas of the LSB that = might be controversial

or premature, aside from POSIX.  The problems = with C++ have been known

for over a year; however, it wasn't until an = objection was raised

by the C++ library maintainer on the GCC list that = any movement

occurred in the position of the FSG.  SC22 = needs to work harder in this area.

 

It is Canada's position that the Linux Rapporteur Group should = become

a WG with a mandate to develop documents for the = Linux Standardization

process, to work with the LSB to improve the = products being delivered,

and to give voice to those important people in the = Linux process who

are being marginalized by the current process. = Failing the formation

of a WG, at a minimum the LRG must be continued to = report  on issues

in the following areas:

  1) Convergence and formatting of PAS = submissions with other ISO

     standards; =

  2) Rationalization of the LSB with other = standards, such as POSIX,

     and = C++;

  3) Modularization of the LSB and other = "Linux" standards.;

  4) Risk mitigation with respect to future LSB = submissions; and

  5) Developing policies as to the appropriate = pace for updates in an

     area that is developing = rapidly.

 

POSIX

 

It is clear that all attempts to reform WG15 have = failed. SC22 has not

had a valid report from WG15 in more than 3 years, = and it is our

understanding that WG15 has not met for more than 3 = years and that

the convener does not respond to requests for = clarification.

 

It is troubling, however, that the Austin Group is continuing to submit

documents to JTC1 as though the relationship with = WG15 is sound and

WG15 is a functioning entity. Furthermore, it is our understanding

that some members of WG15 may be attending Austin = Group meetings as

ISO/IEC/JTC1/WG15 = representatives.

 

It is Canada's position that WG15 has ceased to exist as = a

functioning body, and that all work associated with = WG15 reverts to

SC22. Furthermore, it is our position that SC22 has = no current liaison

or participation in the Austin Group, and that = either a new

relationship must be negotiated, or the Austin Group = must be

terminated and the Open Group must apply as a PAS = submitter to JTC1.

 

WG20 - = Internationalization

With the moving of the SC22/WG20 ordering project to = SC2, participation in person at WG20 has dropped significantly. This = concerns us as the need for standardizing i18n functionality is still as significant = as it was when WG20 was created, although focus in WG20 has been put from the = beginning on sorting.

 

We believe that SC22 should have a TR project in = WG20 to survey all functionalities currently in all programming language = standards and environment standards (such as POSIX and Linux). Such a project should = identify missing functionality and forecast future needs. Such a project would = require close coordination with and input from all other SC22 = WG's.

 

Sally = Seitz

Program = Administrator

ANSI

25 = West 43rd Street

New = York, NY 10036<= /p>

Phone: (212) 642-4918

Fax: (212) 840-2298

 

------_=_NextPart_001_01C493E1.41EB7090--