L2/02-393R

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:

(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"

• to make it clear that conformance to the Unicode Standard doesn't require conformance to X
• but that if you say you conform to X, then you do.
• and if you say you conform partially to X, here are the options

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

Status

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.

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

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.

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.