Application Instrumentation and Control (AIC) API, Version 1.0
Copyright © 1999 The Open Group
It shall be a primary objective in future changes to this specification
to maintain the capability of applications instrumented in accord with
previous versions of this specification to operate with newer versions
of the specification.
To accomplish this, future versions of the
specification shall maintain upward compatibility where possible.
Upward compatibility is defined as maintaining the existing API
signatures and function while allowing new APIs and functions.
If upward compatibility cannot be maintained in a future version,
compliant implementations must maintain the existing APIs that those
implementations have already provided in addition to the new and
It is not the role of this specification today to define
the technique for this, however, noting that there are a number of
techniques including library versions that can be used. To protect at
least this technique, the libraries associated with AIC will be named
so that multiple versions can be used.
Future versions can add new
functionality but must obey the above rules.
In the case that a
customer chooses to use different versions of client and application
libraries, the implementation must ensure that the following rules are
The two versions of AIC implementation must be able
to communicate with each other successfully, at least to the point
where they recognize that they are different.
No component of
AIC can be allowed to cause any other version of AIC to crash because
of a data transport level incompatibility. The defined behavior in this
case is to simply raise an error as a result of the appropriate API
call and notify that error to the calling AIC component. If necessary,
any internal transport related buffers should be flushed to remove the
possibility of confusion.
The AIC installation must support
the lowest common denominator of AIC functionality present as defined
by the lowest AIC revision level.
National Language and Character Set Support (I18n)
With regard to
the main concern with AIC is that the
appropriately depending on the local code page in use.
will be defined to the API using a suitable local code page, whether
this be ISO 88591, or Microsoft 1252. So strings passing in to or out
of the AIC API will be expected to be in the local code chosen for the
implementation on a specific platform. If the implementation is
intended to work on just a single set of platforms in one locality,
nothing further needs to be done - but this can be viewed as an
For transport of information between two
platforms in possibly different localities, the 16 bit form of ISO
10646 (referred to as Unicode here) will be used. On receipt of a
Unicode string, the recipient will transliterate where possible to the
local code of the recipient machine. In the case of some characters
this may not be possible. In other cases, the local code page may also
The intention of this process is to ensure that local
recipient machines need just a transliteration table from Unicode to
the local code page. Also, if the local machine uses Unicode and has a
Unicode font, then the received string can be rendered in it's original
form on the local machine, and at least gives the possibility that the
information can be manually translated.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.