W3C I18N Techniques:
Developing specifications

Specifications, software and content MUST NOT require or depend on a one-to-one correspondence between characters and the sounds of a language.

Specifications, software and content MUST NOT require or depend on a one-to-one mapping between characters and units of displayed text.

Protocols, data formats and APIs MUST store, interchange or process text data in logical order.

Independent of whether some implementation uses logical selection or visual selection, characters selected MUST be kept in logical order in storage.

Specifications of protocols and APIs that involve selection of ranges SHOULD provide for discontiguous logical selections, at least to the extent necessary to support implementation of visual selection on screen on top of those protocols and APIs.

Specifications and software MUST NOT require nor depend on a single keystroke resulting in a single character, nor that a single character be input with a single keystroke (even with modifiers), nor that keyboards are the same all over the world.

Specifications, software and content MUST NOT require or depend on a one-to-one relationship between characters and units of physical storage.

When specifications use the term 'character' the specifications MUST define which meaning they intend.

Specifications SHOULD use specific terms, when available, instead of the general term 'character'.

Textual data objects defined by protocol or format specifications MUST be in a single character encoding.

All specifications that involve processing of text MUST specify the processing of text according to the Reference Processing Model, namely.

• Specifications MUST define text in terms of Unicode characters, not bytes or glyphs.
• For their textual data objects specifications MAY allow use of any character encoding which can be transcoded to a Unicode encoding form.
• Specifications MAY choose to disallow or deprecate some character encodings and to make others mandatory. Independent of the actual character encoding, the specified behavior MUST be the same as if the processing happened as follows:
  • The character encoding of any textual data object received by the application implementing the specification MUST be determined and the data object MUST be interpreted as a sequence of Unicode characters - this MUST be equivalent to transcoding the data object to some Unicode encoding form, adjusting any character encoding label if necessary, and receiving it in that Unicode encoding form.
  • All processing MUST take place on this sequence of Unicode characters.
  • If text is output by the application, the sequence of Unicode characters MUST be encoded using a character encoding chosen among those allowed by the specification.
• If a specification is such that multiple textual data objects are involved (such as an XML document referring to external parsed entities), it MAY choose to allow these data objects to be in different character encodings. In all cases, the Reference Processing Model MUST be applied to all textual data objects.

Specifications SHOULD NOT arbitrarily exclude code points from the full range of Unicode code points from U+0000 to U+10FFFF inclusive.

Specifications MUST NOT allow code points above U+10FFFF.

Specifications SHOULD NOT allow the use of codepoints reserved by Unicode for internal use.

Specifications MUST NOT allow the use of surrogate code points.

Specifications SHOULD exclude compatibility characters in the syntactic elements (markup, delimiters, identifiers) of the formats they define.

Specifications MUST NOT require the use of private use area characters with particular assignments.

Specifications MUST NOT require the use of mechanisms for defining agreements of private use code points.

Specifications and implementations SHOULD NOT disallow the use of private use code points by private agreement.

Specifications MAY define markup to allow the transmission of symbols not in Unicode or to identify specific variants of Unicode characters.

Specifications SHOULD allow the inclusion of or reference to pictures and graphics where appropriate, to eliminate the need to (mis)use character-oriented mechanisms for pictures or graphics.

Specifications MUST either specify a unique character encoding, or provide character encoding identification mechanisms such that the encoding of text can be reliably identified.

When designing a new protocol, format or API, specifications SHOULD require a unique character encoding..

When basing a protocol, format, or API on a protocol, format, or API that already has rules for character encoding, specifications SHOULD use rather than change these rules.

When a unique character encoding is required, the character encoding MUST be UTF-8, UTF-16 or UTF-32.

Specifications SHOULD avoid using the terms 'character set' and 'charset' to refer to a character encoding, except when the latter is used to refer to the MIME charset parameter or its IANA-registered values. The term 'character encoding', or in specific cases the terms 'character encoding form' or 'character encoding scheme', are RECOMMENDED.

If the unique encoding approach is not taken, specifications SHOULD require the use of the IANA charset registry names, and in particular the names identified in the registry as 'MIME preferred names', to designate character encodings in protocols, data formats and APIs.

Character encodings that are not in the IANA registry SHOULD NOT be used, except by private agreement.

If an unregistered character encoding is used, the convention of using 'x-' at the beginning of the name MUST be followed.

If the unique encoding approach is not chosen, specifications MUST designate at least one of the UTF-8 and UTF-16 encoding forms of Unicode as admissible character encodings and SHOULD choose at least one of UTF-8 or UTF-16 as required encoding forms (encoding forms that MUST be supported by implementations of the specification).

Specifications that require a default encoding MUST define either UTF-8 or UTF-16 as the default, or both if they define suitable means of distinguishing them.

Specifications MUST NOT propose the use of heuristics to determine the encoding of data.

Specifications MUST define conflict-resolution mechanisms (e.g. priorities) for cases where there is multiple or conflicting information about character encoding.

Specifications SHOULD NOT invent a new escaping mechanism if an appropriate one already exists.

The number of different ways to escape a character SHOULD be minimized (ideally to one).

Escape syntax SHOULD require either explicit end delimiters or a fixed number of characters in each character escape. Escape syntaxes where the end is determined by any character outside the set of characters admissible in the character escape itself SHOULD be avoided.

Whenever specifications define character escapes that allow the representation of characters using a number, the number MUST represent the Unicode code point of the character and SHOULD be in hexadecimal notation.

Escaped characters SHOULD be acceptable wherever their unescaped forms are; this does not preclude that syntax-significant characters, when escaped, lose their significance in the syntax. In particular, if a character is acceptable in identifiers and comments, then its escaped form should also be acceptable.

Specifications SHOULD NOT invent a new escaping mechanism if an appropriate one already exists.

Specifications SHOULD NOT invent a new escaping mechanism if an appropriate one already exists.

Protocols, data formats and APIs MUST store, interchange or process text data in logical order.

Specifications of protocols and APIs that involve selection of ranges SHOULD provide for discontiguous logical selections, at least to the extent necessary to support implementation of visual selection on screen on top of those protocols and APIs.

Software that sorts or searches text for users SHOULD do so on the basis of appropriate collation units and ordering rules for the relevant language and/or application.

Where searching or sorting is done dynamically, particularly in a multilingual environment, the 'relevant language' SHOULD be determined to be that of the current user, and may thus differ from user to user.

Software that allows users to sort or search text SHOULD allow the user to select alternative rules for collation units and ordering.

Specifications and implementations of sorting and searching algorithms SHOULD accommodate text that contains any character in Unicode.

Specifications SHOULD NOT define a string as a 'byte string'.

The 'character string' definition SHOULD be used by most specifications.

The character string is RECOMMENDED as a basis for string indexing.

A code unit string MAY be used as a basis for string indexing if this results in a significant improvement in the efficiency of internal operations when compared to the use of character string.

Grapheme clusters MAY be used as a basis for string indexing in applications where user interaction is the primary concern.

Specifications that define indexing in terms of grapheme clusters MUST either: a) define grapheme clusters in terms of default grapheme clusters as defined in Unicode Standard Annex #29, Text Boundaries [UTR #29], or b) define specifically how tailoring is applied to the indexing operation.

The use of byte strings for indexing is NOT RECOMMENDED.

Specifications that need a way to identify substrings or point within a string SHOULD provide ways other than string indexing to perform this operation.

Specifications SHOULD understand and process single characters as substrings, and treat indices as boundary positions between counting units, regardless of the choice of counting units.

Specifications of APIs SHOULD NOT specify single characters or single 'units of encoding' as argument or return types.

When the positions between the units are counted for string indexing, starting with an index of 0 for the position at the start of the string is the RECOMMENDED solution, with the last index then being equal to the number of counting units in the string.

Since specifications in general need both a definition for their characters and the semantics associated with these characters, specifications SHOULD include a reference to the Unicode Standard, whether or not they include a reference to ISO/IEC 10646.

A generic reference to the Unicode Standard MUST be made if it is desired that characters allocated after a specification is published are usable with that specification. A specific reference to the Unicode Standard MAY be included to ensure that functionality depending on a particular version is available and will not change over time.

All generic references to the Unicode Standard MUST refer to the latest version of the Unicode Standard available at the date of publication of the containing specification.

All generic references to ISO/IEC 10646 MUST refer to the latest version of ISO/IEC 10646 available at the date of publication of the containing specification.

When defining protocol or format elements (e.g. HTTP headers, XML attributes, etc.) which are to be interpreted as URI references (or specific subsets of URI references, such as absolute URI references, URIs, etc.) use Internationalized Resource Identifiers (IRIs) (or an appropriate subset thereof).

Define when the conversion from IRI references to URI references (or subsets thereof) takes place, in accordance with Internationalized Resource Identifiers (IRIs)

When defining new syntax for URIs, such as a new URI scheme or a new kind of fragment identifier, specify that characters outside the US-ASCII repertoire are encoded using UTF-8 and %HH-escaping.

When defining new syntax for URIs also define the normalization requirements for the syntax you introduce.

If possible, make sure that data always contains an explicit zone offset.

Do not apply operations based on date or time types (such as indexing) to collections of data in which some data items may have zone offset information and other data items may not have zone offset information.

If you have data that includes implicit and fixed explicit zone offsets, before applying any date- or time-sensitive operations adjust the zone offset of the implicit data to UTC with the functions for zone offset adjustment.

If you have data that contains both implicit and fixed explicit time zones and you do not want to adjust the data subset which already has a zone offset, make sure that you recognize this data subset, for example via the component extraction functions.