JTC1/SC22
N3805
From: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
<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
Phone: (212) 642-4918
Fax: (212) 840-2298