The Ada Resource Association
Call for Ada APIs
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, and should preferably have the form of an amendment AI (see 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.
# # #