Version Compatibility

Objectives

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 changed APIs. 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 followed:

1. 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.

2. 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.

3. 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)

AIC_Strings 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 implementation limitation.

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 be Unicode.

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.