OII Standards and Specifications List

I*M Europe
OII Home Page
What is OII?
Standards List
OII Guides
OII Fora List
Conference Reports
Monthly Reports
EC Reports
Whats New?
OII Index
OII Feedback
Search Database

OII Guide to Application Program Interfaces

In ISO/IEC TR 10000-3, Framework and Taxonomy of International Standardized Profiles -- Principles and Taxonomy for OSE Profiles, the following interfaces are defined:

  • Application Program Interface: an interface of a system at which services are provided to application software (the term application is used here to characterize the function using the service)
  • Human/Computer Interface: an interface of a system at which physical interactions take place between a human being and the system
  • Information Services Interface: an interface of a system at which interactions take place with external persistent storage (e.g. removable disc storage)
  • Communications Services Interface: an interface of a system at which interactions take place with entities external to the system, such as external data transport facilities and functions in other systems.

In the ISO/IEC JTC1 GII model described in the OII Report onISO/IEC GII Standards Policy Development Meeting, Galway, September 25th-27th 1996 the last three classes of interface are assigned the generic term External Environment Interfaces (EEIs) to Service Implementation Tools. 

APIs are specified to meet objectives of source code portability or binary portability. In the former case, the source code reflects the specification of the API, but after compilation portability is usually lost and the resulting binary is specific to the particular platform for which it is compiled. In the latter case, the binary itself is portable between a number of platforms. Binary portability is the basis of the considerable variety of shrink-wrapped PC applications. However, in so far as binary portable applications are often restricted to a particular processor, binary APIs do not in general meet the openness requirement of application portability between platforms with different multi-processor architectures. Hence, standards bodies tend to focus on source code portability.

The confusions about APIs arise primarily because the interactions at an API (or a set of function calls within an API) may map onto the interactions at an interface of one of the other types, e.g. an API specifically designed for communications (like XTI, referenced under theProtocol Independent Interfaces entry), might map closely onto the interactions at the Communication Services Interface. Such APIs form an important subset of the complete set of APIs. On the other hand, not all APIs relate directly to an external interface in this way, e.g. APIs to operating system services, APIs which are independent of how the information they transfer is subsequently treated (how it could be stored, or transmitted, or printed). This kind of independence is necessary if people are to be able to write applications that do not need to know where the information used is located.

JTC1 has identified some requirements that should be met by standard API specifications. According to the rules specified in an attachment to the Guidelines for JTC1 API Standardization (JTC1/N2890) a standard API specification should:

  • define the service associated with it or reference a document in which it is defined
  • identify the standards that specify the notations in which it is expressed (according to JTC1, the function calls should ideally be expressed in a language-independent way, which then needs to be supplemented by one or more "language bindings")
  • standard API specifications should be consistent with, and should avoid duplication of, requirements specified by the associated service and programming language standards
  • where it is expected that implementations will support bindings to a service for multiple programming languages, there should be a specification of interoperability between the bindings. This specification should cover exchange of data values between different languages
  • where it is expected that implementations will support bindings to multiple services for a single programming language, any requirements on compatibility between these bindings should be specified, including requirements on coordination of name spaces.

There are many thousands of APIs that have been developed either for use by specific programs or within specific environments. Such APIs have, in general, been considered to be outside of the scope of theApplication Program Interface Standards section of the OII Standards and Specifications List, which has been restricted to listing APIs and EEIs, or sets of such interfaces, that are specifically designed to be used by multiple applications across multiple operating systems.

Section Contents
OII Home Page
OII Index
OII Help

This information set on OII standards is maintained by Martin Bryan of The SGML Centre and Man-Sze Li of IC Focus on behalf of European Commission DGXIII/E.

File last updated: January 1998

Home - Gate - Back - Top - Apiguide - Relevant