Re: Conformance Boilerplate
From: Mark Davis
Date: 2002-10-30

The R version updates the text in the suggested Status section. I have not updated any other sections to reflect discussions in the meeting.

The following is suggested text for action 92-A41:


Mark Davis,
Editorial Committee

Clarify the status statement boiler plate of Unicode Standard Annexes regarding conformance to the standard.

(We didn't have time in the ed committee to discuss this at any length, so the following is not from the ed committee.)

This document consists of two parts. The first part are remarks about conformance that have been raised in the process of doing this document. The second part, after the horizontal line below, is the proposed boilerplate for TRs. The idea is that instead of having a perhaps lengthy section in the Status section, each and every TR would have a Conformance section that would explain all the conformance implications. One such case might be that there are no conformance implications!

Remarks on Conformance

I think it is clear that we need to straighten out what we mean by conformance to the Unicode Standard vs conformance to a particular related specification. For example, here is a snippet from Steve Tolkin (from the W3C query group). Among other feedback on TR29, he says:

"I think an implementation should be able to make one of these statements:
1. complies exactly with the example approach in TR 29
2. makes all these word splits, and possibly more
3. makes no other word splits, but may not make all of these
4. anything else"

I hear these kinds of questions from different people all the time; the current situation is not exactly clear. Those sorts of limited claims might be, in general, the kinds of things that we need limited conformance clauses for:

The problem I see is that we have to distinguish between two cases.

  1. Joe wants to claim conformance to the Unicode Standard, and nothing more.
  2. Tom wants to claim conformance to the Unicode Standard, but also wants to
    claim conformance to some other specification, e.g.

Now, none of these is required by conformance to the Unicode Standard, and we don't want to add them to what is required for conformance to the Unicode Standard. Each of these is thus optional. But we do need to provide a way for people who want to claim conformance to some particular specification (or part of it, in some cases) to be able to do so -- without implying that people have to do so for Unicode Standard conformance. That typically takes the form of a clause like:

If a process claims to support X, it must follow the specifications in Y.

I believe that we should have conformance clauses like that for essentially all of the above, so that it is clear that these things are distinct from conformance to the Unicode Standard, and to clarify that if someone does make a normative reference to one of them, what that actually means.

Proposed Boilerplate for TRs

Alternative phrases in the text below are indicated with [ ... / ... ]. These would be chosen depending on the particular TR. The references, such as [Conformance], are links to the appropriate place in the TR. The sample Conformance section shows how this might look like for a given TR, such as LineBreak. Note that almost all of the language in the Status section and in the sample conformance section is taken out of some existing TR.

Note: the sample boilerplate for UAX Status used to say "Note that conformance to a version of the Unicode Standard includes conformance to its Unicode Standard Annexes." I removed it because it is very unclear what that means for something like UAX #11: East Asian Width, that has no conformance clause, just recommendations for 'best practice'.


This document has been reviewed by Unicode members and other interested parties, and has been approved by the Unicode Technical Committee as a [Unicode Standard Annex / Unicode Technical Standard / Unicode Technical Report]. This is a stable document and may be used as reference material or cited as a normative reference by other specifications.

Alternate Paragraph for not-yet approved documents
This document is a [proposed draft / draft / proposed update of a previously approved] [Unicode Standard Annex / Unicode Technical Standard / Unicode Technical Report]. Publication does not imply endorsement by the Unicode Consortium. This is a draft document which may be updated, replaced, or superseded by other documents at any time. This is not a stable document; it is inappropriate to cite this document as other than a work in progress.

A Unicode Standard Annex (UAX) forms an integral part of the Unicode Standard, but is published as a separate document. The Unicode Standard may require conformance to normative content in a Unicode Standard Annex, if so specified in the Conformance chapter of that version of the Unicode Standard. The version number of a UAX document corresponds to the version number of the Unicode Standard at the last point that the UAX document was updated.

Alternate Paragraphs for other types of TRs
A Unicode Technical Standard (UTS) is an independent specification. Conformance to the Unicode Standard does not imply conformance to any UTS. Each UTS specifies a base version of the Unicode Standard. Conformance to the UTS requires conformance to that version or higher.
A Unicode Technical Report (UTR) contains informative material. Conformance to the Unicode Standard does not imply conformance to any UTR.

The latest version of the Unicode Standard is found on [Unicode]. A list of current Unicode Technical Reports is found on [Reports]. For more information about versions of the Unicode Standard, see [Versions]. Related information that is useful in understanding this document is found in [References]. Please submit corrigenda and other comments with the online reporting form [Feedback].

Sample Conformance Clause

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 specification, as long as they do not purport to conform to this specification.

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.