About the Unicode Consortium Stability Policy
Unlike many other standards, the
Unicode Standard is continually
expanding: new characters are added to meet a variety of uses, ranging from
technical symbols to letters for archaic languages. Character properties
are also expanded or revised to meet implementation requirements. However,
as the Unicode Standard becomes more widely deployed, changes to the
standard must be constrained by the requirements of backward
compatibility. To that end, the Unicode Consortium
Character Encoding Stability Policy limits the ways in which the standards developed by the Unicode
Consortium can change.
A primary requirement of stability is that the identity of the
character remains unchanged in all future versions of the Unicode Standard.
In other words, the same sequence of character codes continues to represent
the same text. Consequently, character codes must never be changed, and the
properties and behavior of a character must not change to the extent that
it affects the identity of the character. In addition, code sequences,
once normalized, must remain normalized.
Additional guarantees restricting possible changes may be added to enable
implementers to make safe assumptions that allow more efficient and
compact implementations. For example, by limiting the possible distinct
values of the General Category, implementations may safely choose a packed
format for representing them.
Character names are immutable, so that they can be used as constant
external references to Unicode characters, in order to synchronize
identifiers for characters among standards, in particular ISO standards.
In an ideal world, the information about existing Unicode Characters would
be complete and correct at inception, so that maintenance of the standard
would be purely additive. However, due to the large number of characters,
each associated with many character properties, this ideal cannot be
achieved. Despite best efforts, clerical errors are introduced in the
publication process, but there are also cases where the initial information
about a character may later prove incorrect or incomplete. In both cases,
corrections may be required. If these can be made without implying a change
to a character's identity, it is usually more beneficial to allow the change
than to freeze the mistake, and the stability policy reflects that.
Even if a proposed correction is not prohibited by the stability policy, it
must undergo an explicit approval process in the
Unicode Technical Committee, including an analysis of its costs and benefits.
In cases where the stability policy prevents a change, the UTC may take one
of several actions:
Occasionally, two separately encoded characters may prove to be
unintentional duplicates of each other. In such cases, stability prevents
removal of the duplicate character as this would impact existing data using
it. Instead, the character may be deprecated, which retains its definition
and properties, but strongly discourages its usage.
- add additional characters with the desired properties and behavior
- add additional properties
- provide documentation of the un-modifiable mistake
- add a character annotation or descriptive text in the standard.