The Ada Application Programming Interfaces (API) Working Group (APIWG) is chartered by the Special Interest Group on Ada (SIGAda) of the Association of Computer Machinery (ACM) to define a mechanism for, and to provide for, the management for Application Programming Interfaces (APIs) for the Ada programming language.
APIWG is SIGAda's response to an ISO/IEC JTC1/SC22 WG9 request to SIGAda and Ada-Europe to propose a mechanism for managing Ada Bindings that are not covered already via formal standards. These Ada bindings, as they evolve and mature, can become recognized as defacto standards supplementing the formal standards maintained by ISO/IEC JTC1/SC22 WG9. APIWG provides a lightweight process to manage Ada Bindings available to the Ada community without the formalism required by ISO. The intent is that SIGAda (through APIWG), Ada-Europe, and WG9 can work together to provide a valuable service to the Ada community for managing Ada bindings to APIs.
An Ada Binding is a compilable API written in the Ada programming language. An API is an interface that allows an application to communicate with an operating system or another application. APIs fall into three categories: Standardized APIs, Registered APIs, and Unmanaged APIs.
Standardized APIs are those provided in the Ada Language Reference Manual or through secondary ISO Standards, for example, the Ada Semantic Interface Specification (ASIS).
Registered APIs are those Ada Bindings/APIs made publicly accessible via that particular API's web page. For the purposes of the APIWG, there are two categories of Registered APIs: Registered Private APIs and Registered Public APIs.
Each Registered Private API has an individual or organization that is responsible for it. The APIWG Chair is responsible for the updating of information about Registered Private APIs on the APIWG web page. These APIs are usually developed and/or maintained by a third party. Anybody, particulary a developer of any Ada API, can submit their API to the APIWG Chair to make it publicly available from the APIWG web page, with appropriate permissions from the developer, as a convenience to the Ada community. Additional useful artifacts are encouraged to be provided, when available (e.g., tutorials, examples, lessons learned, known problems, etc.) either from the original developer or from other parties. Registered Private APIs are not considered to be standards. They should be viewed as potentially valuable artifacts to the Ada community. Depending upon intellectual property right issues, links may be provided for Registered Private APIs on APIWG's web page.
Procedures will be established to make it easy to submit a Registered Private API.
If the submitter is not the developer, the APIWG Chair will seek all the necessary permissions from the owner/originator to place the API and its related artifacts on the APIWG website so that they are publicly available. If permission is granted, the source code for the API and all available artifacts will be added to the APIWG's web page for that API.
Registered Public APIs are those Ada bindings to APIs that are evolved through an open consensus process managed by the SIGAda APIWG. APIWG Subgroups are established and are responsible for the maintenance and evolution (including possible development) of each Registered Public API. Upon approval, the APIWG Subgroup is provided access to a web page dedicated to that API; the Subgroup also has an electronic mail list. This API's web page (on the APIWG website) can be used to document the API and provide artifacts (examples and tutorials as well as the consensus process used to evolve the API). The mail list will be used to conduct the business of the API's Subgroup, coordinate the consensus process, and notify interested parties of major API events. Changes to the API are controlled via a consensus-based process in the API's Subgroup.
Procedures will be established to make it easy to submit a Registered Public API.
Unmanaged APIs are APIs that are neither standardized nor registered (as defined above). Links to useful Unregistered APIs may be provided on the APIWG Home Page.
Currently the vast majority of Ada bindings to APIs are Unmanaged. These Ada bindings are frequently hard to find. Once found, there is frequently little information concerning how to best use the API or on lessons learned from its use. When these Ada bindings are updated (if they are updated), there is no announcement to the Ada community on the availability of the updated API. Frequently these bindings do not evolve with updates to the base API, needed maintenance, or Ada language changes.
One of the goals of APIWG is to provide a current set of Registered Public APIs on the APIWG web page.
For Registered Private APIs, the API is provided unchanged. This could be the best option for a contributor who has developed an API and desires a mechanism to make it more publicly available. A developer can simply provide the API and associated artifacts to the APIWG Chair.
For contributors who has developed APIs that are not (or may not be) publicly available, they may submit their APIs as Registered Private APIs. All that is needed in this case is a link or other information which may describe that API so that potential users may discover it. Such information can then be sent to the APIWG Chair to be "catalogued" on the APIWG web page.
When a new API is added to the APIWG Home Page, the APIWG Chair will make an announcement to the general Ada community (via, SIGAda-Announce, the WG9 email list, and the Ada-Europe email list - usually no more frequently than once a month). Once an API is added to the APIWG Home Page, volunteers may provide other useful data to the APIWG Chair for posting with the API. (e.g., tutorials, examples, known problems, lessons learned).
The SIGAda APIWG Chair is responsible for:
An APIWG Subgroup is established for each Registered Public API for which a request is made. Each Subgroup Chair is responsible to the APIWG Chair for the maintenance and evolution of that particular Registered Public API. The Subgroup is responsible for evolving the API (either by consensus of all members of that Subgroup or by the APIWG's voting procedure). This evolution includes the baselining of the API, versioning of new releases, and identifying associated artifacts (e.g., tutorials, lessons learned).
API Mailing lists will be established for each APIWG Subgroup. The mail list will be open to any interested party, who will then be considered to be a member of that Subgroup. The mail list will be used to conduct the business of the API's Subgroup, coordinate the consensus process, and notify interested parties of major API events. The mail list is archived on the ACM server to maintain a record of the consensus process and provide a historical context to new members of the Subgroup.
Each API's Subgroup is responsible for setting the current version of their particular API. Notification of the latest version should be posted to the web, announced through the quarterly Ada Letters publication, and announced through the API mail list as needed. New versions would be added to the monthly announcement on the SIGAda-Announce mail list to the SIGAda Membership. Similar announcements can be made to Ada-Europe mail lists, Team-Ada, and the WG9 maillist.
APIWG Subgroup Chairs are responsible for:
APIWG and its Subgroups invite members of the Ada community to:
Membership in the APIWG or any of its Subgroups is open to any interested party. Members are responsible for their own expenses. The APIWG Chair must be a member of both ACM and SIGAda. It is strongly recommended that all other members of APIWG and its Subgroups be either a member of ACM or SIGAda or a member of Ada-Europe, but this is not a requirement.
All mail lists (the main APIWG list as well as all Subgroup lists) are set up so those subscribed can freely post to the mail list. However, the mail list is moderated so that non-member postings can be regulated, in particular, to filter out spam. The mail list moderator must be an ACM and SIGAda member (usually the APIWG Chair or a Subgroup Chair).
Last update 31 December 2002, comments to Clyde Roby (ClydeRoby@ACM.Org)