L2/03-284

Re: Conformance Clause Boilerplate
From: Mark Davis
Date: 2003-08-23

Sample Conformance Clause

The following is a sample conformance clause. It uses examples from Line Break, but would be adapted to specific cases.

2.1 Conformance

The relationship between conformance to the Unicode Standard, and conformance to an individual Unicode technical report (UAX, UTS, or UTR) is described in more detail in the Unicode Standard in Section 3.2 Conformance. Conformance to the Unicode Standard [does not require / requires* ] conformance to the specification in this document.

[*Ed Note: whichever alternate that is appropriate would be chosen. The examples of cases of requires include: BIDI, Normalization. In most other cases, conformance to the Unicode Standard does not imply conformance to anything in any TR. Currently, linebreak is an odd case -- semi-normative.]

There are many different ways to break lines of text, and the Unicode Standard does not restrict the ways in which implementations can do this. However, any Unicode-conformant implementation that purports to implement this specification must do so as described in the following clause. Implementations are free to deviate from this, as long as they do not purport to conform to this specification.

[Ed Note: the above paragraph is dropped in the case of a requires above.]

C1 An implementation that claims conformance to the default Unicode Line Break Algorithm shall produce the same results as specified in Section 3.2.
C2 This specification defines default behavior, that which is to be used in the absence of tailoring for particular languages and environments.
  • Where a particular environment (such as a Slovak locale) requires tailoring, such modifications to this specification can be done without affecting conformance.
Unicode specifications are generally described as an algorithm or process, producing a result from a given input. However, these are simply logical specifications; particular implementations can change or optimize the internal processing as long as they provide the same results from the same input.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. However, for readability, these words do not appear in all uppercase letters in this specification.

At times, this specification recommends best practice. These recommendations are not normative and conformance with this specification does not depend on their realization. These recommendations contain the expression "We recommend ...", "This specification recommends ...", or some similar wording.