|
ISO Working Group asks Ada Community
for Candidate APIs for Standardization
Pascal Leroy
Principal Software Engineer
Rational Software Corp.
Chair, Ada Rapporteur Group
As part of the next revision of Ada, planned for 2005, there has been a lot of
interest in the Ada community for the standardization of reusable components and
APIs to existing services. It is felt that such standardizations would improve
the marketability of the language as well as day-to-day programmer productivity.
For most of these APIs, the proper standardization vehicle is a secondary standard
(that is, a standard referencing the Ada standard, but standardized as a separate
process). For relatively small APIs, inclusion in an existing annex is also an
option, although this might delay the language standardization process.
The Ada Rapporteur Group (ARG) is the technical committee in charge of proposing
amendments to the language to WG9, the ISO working group on Ada. While the ARG
will conduct (based on input from the Ada community) the revision of the core
language and annexes, it doesn't have the resources to develop proposals itself
for the standardization of reusable components or APIs. The ARG will oversee the
development of secondary standards, but this is best accomplished by cooperating
with external groups developing the substance of such standards.
We would like to ask the Ada community to submit proposals for the standardization
of APIs. Proposals should be sent to
ada-comment@ada-auth.org, and
should preferably have the form of an amendment AI (see
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00248.TXT
for an example). While all input will be carefully reviewed, the ARG will act as
a filter to retain only those proposals that have a sufficient level of maturity
and usefulness, and will provide feedback to the authors. Criteria that will be
used for evaluating the proposals include:
- Benefits of the standardization. Presumably the advantage of standardization
is that it brings uniformity and portability among implementations. However, there
is a significant overhead associated with a formal standardization process, so in
some cases a de facto standard may bring practically the same benefits at a much lower cost.
- Usefulness of the API. APIs which have been conjured up solely for the
purpose of writing a proposal, or which have been used by a very small group of
users, are less likely to be generally useful than APIs which have been available
for years and have benefited from feedback from a large user base.
- Quality and precision of the proposal. At a minimum, the proposal must
include a set of Ada specifications, and a semi-formal description of the semantics
of each declaration, such as can be found in the annexes of the Reference Manual.
A rationale showing examples of use, explaining the choices that were made, the
alternatives that were considered, and why they were discarded, would also be
much appreciated.
- Community consensus for the proposal. Proposals with a substantial consensus
of the Ada community or the appropriate subcommunity are preferred over proposals
made by an individual or small group. This is not to say that a proposal primarily
authored by an individual is necessarily bad (indeed, it is likely to provide a
more consistent proposal), but to encourage authors to seek input/approval from
as many potential users of the API as possible.
- Portability and language usage. The definition of the API must not depend on
implementation-defined characteristics of a particular compiler, although it is
acceptable to require the compiler to support some Specialized Needs Annex (or
part thereof). As much as possible, the API should only use the features of Ada 95
(as opposed to those that are under consideration for the 200Y amendment) although
we realize that this may not be practical in some cases.
- Implementation. A publicly available reference implementation would be useful,
although this is not a strict requirement, as in some cases that may cause
intellectual property issues.
- Test suite. A test suite ensuring conformity to the specification should be
provided at some point during the standardization process. This is especially
important for standards for which no publicly available reference implementation
will be available. This doesn't necessarily mean that there will be a formal
conformity assessment process like there is for compilers, but it will help
implementers ensure that they comply with the standard.
It is anticipated that the groups submitting proposals will keep ownership of the
standard during the entire standardization process, although the ARG will provide
guidance regarding that process and continuous feedback on the contents of the proposal.
# # #
|
