RFC 8610: 簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現するための表記法（日本語訳）

This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.

この文書では、CBOR（Concise Binary Object Representation）データ構造（RFC 7049）を表現するための表記法の提案を行っています。その主な目的は、CBORまたはJSONを使用するプロトコルメッセージおよびデータ形式の構造を簡単かつ明確に表現する方法を提供することです。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これはインターネット標準化トラックの文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の成果物です。IETFコミュニティのコンセンサスを代表しています。公開レビューを受け、インターネットエンジニアリング指導グループ（IESG）による出版承認を得ています。インターネット標準に関する詳細情報は、RFC 7841のセクション2に利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8610.

このドキュメントの現在の状況、任意のエラータ、そしてそれに対するフィードバックの提供方法については、https://www.rfc-editor.org/info/rfc8610 で取得することができます。

Copyright Notice

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETFドキュメントに関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）にしたがう必要があります。これらの文書をよく確認し、この文書に関するあなたの権利と制限を説明しています。この文書から抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

1. Introduction

1. はじめに

In this document, a notational convention to express Concise Binary Object Representation (CBOR) data structures [RFC7049] is defined.

このドキュメントでは、Concise Binary Object Representation (CBOR)データ構造を表現するための表記法が定義されています。

The main goal for the convention is to provide a unified notation that can be used when defining protocols that use CBOR. We term the convention "Concise Data Definition Language", or CDDL.

コンベンションの主な目標は、CBORを使用するプロトコルの定義時に使用できる統一された表記法を提供することです。私たちはこの規約を「Concise Data Definition Language（CDDL）」と呼んでいます。

The CBOR notational convention has the following goals:

CBORの表記規約には、以下の目標があります：

(G1) Provide an unambiguous description of the overall structure of a CBOR data item.

(G1) CBORデータアイテムの全体構造の明確な説明を提供します。

(G2) Be flexible in expressing the multiple ways in which data can be represented in the CBOR data format.

(G2) CBORデータ形式でデータが表現される複数の方法を柔軟に表現すること。

(G3) Be able to express common CBOR datatypes and structures.

(G3) 一般的なCBORデータ型と構造を表現する能力を持つ。

(G4) Provide a single format that is both readable and editable for humans and processable by a machine.

(G4) 人間が読み書き可能であり、機械も処理可能な単一の形式を提供します。

(G5) Enable automatic checking of CBOR data items for data format compliance.

(G5) CBORデータ項目のデータ形式の適合性を自動的にチェックするようにします。

(G6) Enable extraction of specific elements from CBOR data for further processing.

(G6) CBORデータから特定の要素を抽出してさらなる処理を可能にする。

Not an original goal per se, but a convenient side effect of the JSON generic data model being a subset of the CBOR generic data model, is the fact that CDDL can also be used for describing JSON data structures (see Appendix E).

JSON汎用データモデルがCBOR汎用データモデルのサブセットであるという便利な副次的効果から生じるものではありませんが、CDDLはJSONデータ構造を記述するためにも使用できます（詳細は付録Eを参照してください）。

This document has the following structure:

このドキュメントは以下の構造を持っています：

The syntax of CDDL is defined in Section 3. Examples of CDDL and a related CBOR data item ("instance"), some of which use the JSON form, are described in Appendix H. Section 4 discusses usage of CDDL. Examples are provided throughout the text to better illustrate concept definitions. A formal definition of CDDL using ABNF grammar [RFC5234] is provided in Appendix B. Finally, a _prelude_ of standard CDDL definitions that is automatically prepended to, and thus available in, every CDDL specification is listed in Appendix D.

CDDLの構文は、セクション3で定義されています。CDDLの例や関連するCBORデータ項目（「インスタンス」と呼ばれるもの）のいくつかは、JSON形式を使用して説明されており、それについては付録Hで説明されています。セクション4では、CDDLの使用方法について説明しています。コンセプトの定義をより具体的に説明するために、テキスト全体にわたって例が提供されています。ABNF文法[RFC5234]を使用したCDDLの形式的な定義は、付録Bで提供されています。最後に、すべてのCDDL仕様で自動的に先行するため、またそのために利用可能な、標準CDDL定義のプレリュードが付録Dにリストされています。

1.1. Requirements Notation

1.1. 要件表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、「要求されています（REQUIRED）」、「することになります（SHALL）」、「することはありません（SHALL NOT）」、「すべきです（SHOULD）」、「すべきではありません（SHOULD NOT）」、「推奨されます（RECOMMENDED）」、「推奨されません（NOT RECOMMENDED）」、「してもよいです（MAY）」、「選択できます（OPTIONAL）」は、 BCP 14 [RFC2119] [RFC8174]に記載されているとおりに解釈されるものとします。ただし、ここに示すようにすべて大文字で表示される場合に限ります。

1.2. Terminology

1.2. 用語

New terms are introduced in _cursive_, which is rendered in plain text as the new term surrounded by underscores. CDDL text in the running text is in "typewriter", which is rendered in plain text as the CDDL text in double quotes (double quotes are also used in the usual English sense; the reader is expected to disambiguate this by context).

新しい用語は _斜体_ で導入され、通常のテキストでは新しい用語をアンダースコアで囲んで表示します。逐次実行テキスト内のCDDLテキストは ''タイプライター'' であり、通常のテキストではCDDLテキストを二重引用符で囲んで表示します（二重引用符は通常の英語の意味でも使用されますが、読者は文脈によってこれを曖昧にすることが期待されています）。

In this specification, the term "byte" is used in its now-customary sense as a synonym for "octet".

この仕様書では、「バイト」という用語は、その今日の通例的な意味である「オクテット」という同義語として使用されています。

2. The Style of Data Structure Specification

CDDL focuses on styles of specification that are in use in the community employing the data model as pioneered by JSON and now refined in CBOR.

CDDLは、JSONで先駆けられ、CBORで現在改良されているデータモデルを使用するコミュニティで使用されている仕様のスタイルに焦点を当てています。

There are a number of more or less atomic elements of a CBOR data model, such as numbers, simple values (false, true, nil), text strings, and byte strings; CDDL does not focus on specifying their structure. CDDL of course also allows adding a CBOR tag to a data item.

CBORデータモデルには、数値、単純値（false、true、nil）、テキスト文字列、バイト文字列など、いくつかのよりまたは少ない原子要素があります。CDDLは、これらの構造を指定することには焦点を当てていません。もちろん、CDDLはデータアイテムにCBORタグを追加することも許可しています。

Beyond those atomic elements, further components of a data structure definition language are the datatypes used for composition: arrays and maps in CBOR (called "arrays" and "objects" in JSON). While these are only two representation formats, they are used to specify four loosely distinguishable styles of composition:

これらの原子要素に加えて、データ構造定義言語のさらなる要素として、組み立てに使用されるデータ型があります。CBORでは、配列とマップ（JSONでは「配列」と「オブジェクト」と呼ばれる）が使用されます。これらは、表現形式は2つだけですが、4つの異なるスタイルの組み立てを指定するために使用されます。

A _vector_: an array of elements that are mostly of the same semantics. The set of signatures associated with a signed data item is a typical application of a vector.

ベクター：ほとんど同じ意味を持つ要素の配列。署名付きデータアイテムに関連する署名のセットは、ベクターの典型的な応用例です。

A _record_: an array the elements of which have different, positionally defined semantics, as detailed in the data structure definition. A 2D point, specified as an array of an x coordinate (which comes first) and a y coordinate (coming second), is an example of a record, as is the pair of exponent (first) and mantissa (second) in a CBOR decimal fraction.

レコード: データ構造定義に詳細に記載されているように、要素が異なる位置で定義された意味を持つ配列。x座標（最初に来る）とy座標（2番目に来る）の配列として指定された2Dポイントは、レコードの例です。また、CBOR10進数の指数（最初）と仮数（次）のペアもレコードです。

A _table_: a map from a domain of map keys to a domain of map values, that are mostly of the same semantics. A set of language tags, each mapped to a text string translated to that specific language, is an example of a table. The key domain is usually not limited to a specific set by the specification but is open for the application, e.g., in a table mapping IP addresses to Media Access Control (MAC) addresses, the specification does not attempt to foresee all possible IP addresses. In a language such as JavaScript, a "Map" (as opposed to a plain "Object") would often be employed to achieve the generality of the key domain.

テーブル: ほぼ同じ意味を持つマップキーのドメインからマップ値のドメインへのマップ。特定の言語に翻訳されたテキスト文字列にマップされた言語タグのセットは、テーブルの例です。キードメインは通常、仕様によって特定のセットに制限されることはありませんが、アプリケーションにオープンです。例えば、IPアドレスをメディアアクセス制御（MAC）アドレスにマッピングするテーブルでは、仕様ではすべての可能なIPアドレスを予測しようとしません。JavaScriptのような言語では、キードメインの一般性を達成するために、通常「オブジェクト」ではなく「マップ」が使用されることがあります。

A _struct_: a map from a domain of map keys as defined by the specification to a domain of map values the semantics of each of which is bound to a specific map key. This is what many people have in mind when they think about JSON objects; CBOR adds the ability to use map keys that are not just text strings. Structs can be used to solve problems similar to those records are used for; the use of explicit map keys facilitates optionality and extensibility.

_struct_: 仕様で定義されたマップキーのドメインから、特定のマップキーにバインドされた各マップ値のドメインへのマップです。これは、多くの人がJSONオブジェクトについて考えるときに想定しているものです。CBORは、単なるテキスト文字列でないマップキーの使用を可能にします。structは、レコードの使用と類似した問題を解決するために使用することができます。明示的なマップキーの使用は、オプション性と拡張性を容易にします。

Two important concepts provide the foundation for CDDL:

CDDLの基礎となる2つの重要な概念があります。

1. Instead of defining all four types of composition in CDDL separately, or even defining one kind for arrays (vectors and records) and one kind for maps (tables and structs), there is only one kind of composition in CDDL: the _group_ (Section 2.1).

1. CDDLでは、個別にすべての４つの組み合わせタイプを定義するのではなく、または配列の種類（ベクトルとレコード）とマップの種類（テーブルと構造体）を定義するのでもなく、CDDLには組み合わせの一種類「_group_（セクション2.1）」のみが存在します。

2. The other important concept is that of a _type_. The entire CDDL specification defines a type (the one defined by its first _rule_), which formally is the set of CBOR data items that are acceptable as "instances" for this specification. CDDL predefines a number of basic types such as "uint" (unsigned integer) or "tstr" (text string), often making use of a simple formal notation for CBOR data items. Each value that can be expressed as a CBOR data item is also a type in its own right, e.g., "1". A type can be built as a _choice_ of other types, e.g., an "int" is either a "uint" or a "nint" (negative integer). Finally, a type can be built as an array or a map from a group.

2. もう一つの重要な概念は「タイプ」です。CDDLの仕様全体は、この仕様の「インスタンス」として受け入れ可能なCBORデータアイテムのセット（最初の「ルール」によって定義されるもの）を形式的に定義します。CDDLは、「uint」（符号なし整数）や「tstr」（テキスト文字列）などのいくつかの基本的なタイプを事前に定義しており、しばしばCBORデータアイテムのための単純な形式的記法を使用します。CBORデータアイテムとして表現できる各値はそれ自体でもタイプであり、「1」などです。タイプは他のタイプの「選択」として構築することもできます。例えば、「int」は「uint」と「nint」（負の整数）のどちらかであることがあります。最後に、タイプはグループからの配列やマップとして構築することもできます。

The rest of this section introduces a number of basic concepts of CDDL, and Section 3 defines additional syntax. Appendix C gives a concise summary of the semantics of CDDL.

このセクションの残りでは、CDDLのいくつかの基本的な概念について説明し、セクション3では追加の文法を定義しています。付録Cでは、CDDLの意味論の簡潔なまとめが提供されています。

2.1. Groups and Composition in CDDL

CDDL groups are lists of group _entries_, each of which can be a name/value pair or a more complex group expression (which then in turn stands for a sequence of name/value pairs). A CDDL group is a production in a grammar that matches certain sequences of name/value pairs but not others. The grammar is based on the concepts of Parsing Expression Grammars (PEGs) (see Appendix A).

CDDLグループは、グループエントリのリストであり、それぞれが名前/値のペアまたはより複雑なグループ式（その場合は名前/値のペアのシーケンスを表す）であることができます。 CDDLグループは、特定の名前/値のペアのシーケンスに一致するが、他のシーケンスには一致しない文法内のプロダクションです。この文法は、Parsing Expression Grammars（PEGs）の概念に基づいています（詳細は付録Aを参照）。

In an array context, only the value of the name/value pair is represented; the name is annotation only (and can be left off from the group specification if not needed). In a map context, the names become the map keys ("member keys").

配列コンテキストでは、名前/値のペアの値のみが表されます。名前は注釈のみです（必要な場合はグループ仕様から省略することもできます）。マップコンテキストでは、名前がマップキー（"メンバーキー"）になります。

In an array context, the actual sequence of elements in the group is important, as that sequence is the information that allows associating actual array elements with entries in the group. In a map context, the sequence of entries in a group is not relevant (but there is still a need to write down group entries in a sequence).

配列のコンテキストでは、グループ内の要素の実際のシーケンスが重要です。なぜなら、そのシーケンスが実際の配列要素をグループのエントリと関連付けるための情報であるからです。マップのコンテキストでは、グループ内のエントリのシーケンスは関係ありません（しかし、グループのエントリをシーケンスで記述する必要が依然としてあります）。

An array matches a specification given as a group when the group matches a sequence of name/value pairs the value parts of which exactly match the elements of the array in order.

配列は、グループとして与えられた仕様に一致する場合、そのグループは、値部分が配列の要素と完全に一致する名前/値のペアのシーケンスと一致します。

A map matches a specification given as a group when the group matches a sequence of name/value pairs such that all of these name/value pairs are present in the map and the map has no name/value pair that is not covered by the group.

マップは、グループとして指定された仕様と一致する場合、グループがマップ内に存在するすべての名前/値のペアと一致するシーケンスであるときに一致します。また、マップにはグループでカバーされていない名前/値のペアが存在しないことが必要です。

A simple example of using a group directly in a map definition is:

グループをマップ定義で直接使用する簡単な例は次のとおりです：

                          person = {
                            age: int,
                            name: tstr,
                            employer: tstr,
                          }

                          person = {
                            age: int,
                            name: tstr,
                            employer: tstr,
                          }

                          person = {
                            age: int,
                            name: tstr,
                            employer: tstr,
                          }

Figure 1: Using a Group Directly in a Map

The three entries of the group are written between the curly braces that create the map: here, "age", "name", and "employer" are the names that turn into the map key text strings, and "int" and "tstr" (text string) are the types of the map values under these keys.

グループの3つのエントリは、マップを生成する波括弧の間に書かれます。ここでは、「age」、「name」、「employer」は、マップのキーテキスト文字列になる名前です。また、「int」と「tstr」（テキストストリング）は、これらのキーの下にあるマップの値の型です。

A group by itself (without creating a map around it) can be placed in (round) parentheses and given a name by using it in a rule:

グループ自体（その周りにマップを作らずに）は、（丸括弧の中に）置かれ、ルールで使用することで名前を付けることができます。

                          pii = (
                            age: int,
                            name: tstr,
                            employer: tstr,
                          )

pii = ( age: int, name: tstr, employer: tstr, )

                          pii = (
                            age: int,
                            name: tstr,
                            employer: tstr,
                          )

Figure 2: A Basic Group

This separate, named group definition allows us to rephrase Figure 1 as:

この個別で名前付きのグループ定義により、図1を以下のように言い換えることができます。

                             person = {
                               pii
                             }

                             person = {
                               pii
                             }

Figure 3: Using a Group by Name

Figure 3: 名前でグループ化する

Note that the (curly) braces signify the creation of a map; the groups themselves are neutral as to whether they will be used in a map or an array.

（波かっこ）はマップの作成を示します。グループ自体は、マップまたは配列で使用されるかどうかに関して中立です。

As shown in Figure 1, the parentheses for groups are optional when there is some other set of brackets present. Note that they can still be used, leading to this not-so-realistic, but perfectly valid, example:

図1に示されているように、グループの括弧は、他のセットのかっこが存在する場合はオプションです。ただし、それらは引き続き使用することができるため、次の非現実的ですが完全に有効な例につながります。

                          person = {(
                            age: int,
                            name: tstr,
                            employer: tstr,
                          )}

                          person = {(
                            age: int,
                            name: tstr,
                            employer: tstr,
                          )}

                          person = {(
                            年齢: int,
                            名前: tstr,
                            雇用主: tstr,
                          )}

Figure 4: Using a Parenthesized Group in a Map

Figure 4: 括弧グループを使用したマップ

Groups can be used to factor out common parts of structs, e.g., instead of writing specifications in copy/paste style, such as in Figure 5, one can factor out the common subgroup, choose a name for it, and write only the specific parts into the individual maps (Figure 6).

グループは、構造体の共通部分を分離するために使用できます。例えば、図5のようなコピー＆ペーストスタイルで仕様を記述する代わりに、共通のサブグループを分離し、それに名前を付けて個々のマップには特定の部分だけを記述することができます（図6参照）。

                       person = {
                         age: int,
                         name: tstr,
                         employer: tstr,
                       }

                       person = {
                         age: ,
                         name: ,
                         employer: ,
                       }

                       dog = {
                         age: int,
                         name: tstr,
                         leash-length: float,
                       }

                        dog = {
                          age: int,
                          name: tstr,
                          leash-length: float,
                        }

                        dog = {
                          年齢: int,
                          名前: tstr,
                          リーシュの長さ: float,
                        }

Figure 5: Maps with Copy/Paste

Figure 5: コピー/ペーストによる地図

                       person = {
                         identity,
                         employer: tstr,
                       }

                       person = {
                         identity,
                         employer: tstr,
                       }

                       person = {
                         identity,
                         employer: tstr,
                       }

                       dog = {
                         identity,
                         leash-length: float,
                       }

                       犬 = {
                         identity,
                         首輪の長さ: float,
                       }

                       identity = (
                         age: int,
                         name: tstr,
                       )

                       identity = (
                         age: int,
                         name: tstr,
                       )

Figure 6: Using a Group for Factorization

Figure 6: 要因分解のためのグループの使用方法

Note that the lists inside the braces in the above definitions constitute (anonymous) groups, while "identity" is a named group, which can then be included as part of other groups (anonymous as in the example, or themselves named).

上記の定義内の中括弧内のリストは（匿名の）グループを構成しますが、「identity」は名前付きのグループであり、その後他のグループの一部として含めることができます（前述の例のように匿名であるか、それ自体が名前付きであるか）。

2.1.1. Usage

Groups are the instrument used in composing data structures with CDDL. It is a matter of style in defining those structures whether to define groups (anonymously) right in their contexts or whether to define them in a separate rule and to reference them with their respective name (possibly more than once).

グループはCDDLを使用してデータ構造を構築するための仕組みです。これらの構造を定義する際に、そのコンテキスト内でグループを（匿名で）直接定義するか、それらを別のルールで定義し、関連する名前で参照するか（複数回行う場合もあるかもしれません）はスタイルの問題です。

With this, one is allowed to define all small parts of their data structures and compose bigger protocol data units with those or to have only one big protocol data unit that has all definitions ad hoc where needed.

これにより、データ構造のすべての小さな部分を定義し、それらを組み合わせて大きなプロトコルデータユニットを作成したり、必要な場所で定義を完全に行った1つの大きなプロトコルデータユニットだけを持つことが許可されます。

2.1.2. Syntax

The composition syntax is intended to be concise and easy to read:

構成文法は簡潔で読みやすいことを意図されています。

The start and end of a group can be marked by "(" and ")".

グループの始まりと終わりは"("と")"でマークされることができます。

Definitions of entries inside of a group are noted as follows: _keytype => valuetype,_ (read "keytype maps to valuetype"). The comma is actually optional (not just in the final entry), but it is considered good style to set it. The double arrow can be replaced by a colon in the common case of directly using a text string or integer literal as a key; see Section 3.5.1. This is also the common way of naming elements of an array just for documentation; see Section 3.4.

グループ内のエントリの定義は、次のように記述されます：_keytype => valuetype,_ （この場合、「keytypeはvaluetypeにマップされる」と読みます）。コンマは実際にはオプションです（最後のエントリの場合だけでなく）、しかし設定することが好ましいスタイルとされています。直接テキスト文字列や整数リテラルをキーとして使用する場合、ダブルアローをコロンで置き換えることもできます。詳細は3.5.1節を参照してください。これは、配列の要素をドキュメント化するための一般的な方法でもあります。3.4節を参照してください。

A basic entry consists of a _keytype_ and a _valuetype_, both of which are types (Section 2.2); this entry matches any name/value pair the name of which is in the keytype and the value of which is in the valuetype.

基本エントリは_keytype_と_valuetype_の両方のタイプで構成されています（セクション2.2）。このエントリは、名前がkeytypeに含まれ、値がvaluetypeに含まれる名前/値のペアに一致します。

A group defined as a sequence of group entries matches any sequence of name/value pairs that is composed by concatenation in order of what the entries match.

MUST: しなければなりません（MUST） MUST NOT: してはなりません（MUST NOT） REQUIRED: 要求されています（REQUIRED） SHALL: することになります（SHALL） SHALL NOT: することはありません（SHALL NOT） SHOULD: すべきです（SHOULD） SHOULD NOT: すべきではありません（SHOULD NOT） RECOMMENDED: 推奨されます（RECOMMENDED） NOT RECOMMENDED: 推奨されません（NOT RECOMMENDED） MAY: してもよいです（MAY） OPTIONAL: 選択できます（OPTIONAL） The given English text translated to Japanese: グループとは、グループエントリのシーケンスとして定義され、エントリが一致する順序に従って連結された名前/値のシーケンスに一致します。

A group definition can also contain choices between groups; see Section 2.2.2.

グループ定義には、グループ間の選択肢も含めることもできます。セクション2.2.2を参照してください。

2.2. Types

2.2.1. Values

Values such as numbers and strings can be used in place of a type. (For instance, this is a very common thing to do for a key type, common enough that CDDL provides additional convenience syntax for this.)

値、例えば数値や文字列などは、型の代わりに使用することができます。（たとえば、キーの型に関しては、これが非常に一般的なことであり、CDDLはこれに関して追加の便利な構文を提供しています。）

The value notation is based on the C language, but does not offer all the syntactic variations (see Appendix B for details). The value notation for numbers inherits from C the distinction between integer values (no fractional part or exponent given -- NR1 [ISO6093]; "NR" stands for "numerical representation") and floating-point values (where a fractional part, an exponent, or both are present -- NR2 or NR3), so the type "1" does not include any floating-point numbers while the types "1e3" and "1.5" are both floating-point numbers and do not include any integer numbers.

値の表記法はC言語に基づいていますが、すべての構文的なバリエーションを提供していません（詳細については付録Bを参照してください）。値の表記方法には、整数値（小数部や指数がない- NR1 [ISO6093]。"NR"は"numerical representation"の略です）と浮動小数点値（小数部、指数、またはその両方が存在する- NR2またはNR3）の区別があります。したがって、タイプ"1"には浮動小数点数は含まれませんが、タイプ"1e3"と"1.5"は浮動小数点数であり、整数数を含みません。

2.2.2. Choices

Many places that allow a type also allow a choice between types, delimited by a "/" (slash). The entire choice construct can be put into parentheses if this is required to make the construction unambiguous (please see Appendix B for details of the CDDL grammar).

多くの場所では、タイプを許可すると同時に、タイプ間の選択が可能であり、"/"（スラッシュ）で区切られています。選択構造全体は、構造を明確にするために必要な場合は括弧で囲むことができます（CDDL文法の詳細については付録Bを参照してください）。

Choices of values can be used to express enumerations:

値の選択肢を使用して列挙を表現することができます。

         attire = "bow tie" / "necktie" / "Internet attire"
         protocol = 6 / 17

         attire = "ボウタイ" / "ネクタイ" / "インターネットの服装"
         protocol = 6 / 17

Analogous to types, CDDL also allows choices between groups, delimited by a "//" (double slash). Note that the "//" operator binds much more weakly than the other CDDL operators, so each line within "delivery" in the following example is its own alternative in the group choice:

タイプに対応するように、CDDLはグループ間の選択も許可しており、グループは"//"（二重スラッシュ）で区切られます。なお、"//"演算子は他のCDDLの演算子よりも弱くバインドされるため、以下の例で「delivery」内の各行は、グループ選択の個々の代替となります。

                address = { delivery }

アドレス = { 配送 }

                delivery = (
                street: tstr, ? number: uint, city //
                po-box: uint, city //
                per-pickup: true )

                delivery = (
                street: tstr, ? number: uint, city //
                po-box: uint, city //
                per-pickup: true )

                city = (
                name: tstr, zip-code: uint
                )

                city = (
                name: , zip-code:
                )

                city = (
                name: , zip-code:
                )

                city = (
                name: 、zipコード:
                )

A group choice matches the union of the sets of name/value pair sequences that the alternatives in the choice can.

グループ選択は、選択の中の選択肢ができる名前/値ペアのシーケンスの集合の和集合に一致する。

For both type choices and group choices, additional alternatives can be added to a rule later in separate rules by using "/=" and "//=", respectively, instead of "=":

両方のタイプの選択肢とグループの選択肢について、追加の選択肢は、"="の代わりに"/="（タイプの選択肢）および"//="（グループの選択肢）を使用して、後で別のルールに追加することができます。

              attire /= "swimwear"

              delivery //= (
              lat: float, long: float, drone-type: tstr
              )

              delivery //= (
              lat: float, long: float, drone-type: tstr
              )

              配達 //= (
              lat: float, long: float, drone-type: tstr
              )

It is not an error if a name is first used with a "/=" or "//=" (there is no need to "create it" with "=").

名前が最初に"/="または"//="と共に使用された場合、それを"="で「作成する」必要はありません。

2.2.2.1. Ranges

Instead of naming all the values that make up a choice, CDDL allows building a _range_ out of two values that are in an ordering relationship: a lower bound (first value) and an upper bound (second value). A range can be inclusive of both bounds given (denoted by joining two values by ".."), or it can include the lower bound and exclude the upper bound (denoted by instead using "..."). If the lower bound exceeds the upper bound, the resulting type is the empty set (this behavior can be desirable when generics (Section 3.10) are being used).

選択肢を構成するすべての値を列挙する代わりに、CDDLでは順序関係にある2つの値からなる「範囲（range）」を構築することができます。範囲は、両方の境界を含む場合（2つの値を「..」で結合することで表示されます）、または下限を含み上限を除外する場合（代わりに「...」を使用することで表示されます）があります。下限が上限を超える場合、結果的な型は空の集合になります（この動作は、ジェネリック（セクション3.10）を使用している場合に望ましい場合があります）。

      device-address = byte
      max-byte = 255
      byte = 0..max-byte ; inclusive range
      first-non-byte = 256
      byte1 = 0...first-non-byte ; byte1 is equivalent to byte

      のdevice-address = byte
      のmax-byte = 255
      のbyte = 0..max-byte ; inclusiveな範囲
      ではないfirst-non-byte = 256
      のbyte1 = 0...first-non-byte ; byte1はbyteと同等

CDDL currently only allows ranges between integers (matching integer values) or between floating-point values (matching floating-point values). If both are needed in a type, a type choice between the two kinds of ranges can be (clumsily) used:

CDDLは現在、整数間の範囲（整数値に一致する）または浮動小数点値間の範囲（浮動小数点値に一致する）のみを許可しています。もしタイプ内で両方が必要な場合、二種類の範囲の間でタイプの選択を（不器用にも）使用することができます。

             int-range = 0..10 ; only integers match
             float-range = 0.0..10.0 ; only floats match
             BAD-range1 = 0..10.0 ; NOT DEFINED
             BAD-range2 = 0.0..10 ; NOT DEFINED
             numeric-range = int-range / float-range

             int-range = 0..10 ; ただし整数にマッチ
             float-range = 0.0..10.0 ; ただし浮動小数点数にマッチ
             BAD-range1 = 0..10.0 ; 未定義
             BAD-range2 = 0.0..10 ; 未定義
             numeric-range = int-range / float-range

(See also the control operators .lt/.ge and .le/.gt in Section 3.8.6.) Note that the dot is a valid name continuation character in CDDL, so

   min..max

   最小..最大

is not a range expression but a single name. When using a name as the left-hand side of a range operator, use spacing as in

範囲式ではなく、単一の名前です。範囲演算子の左辺として名前を使用する場合は、以下のようにスペースを使用してください。

   min .. max

   最小 .. 最大

to separate off the range operator.

範囲演算子を分割します。

2.2.2.2. Turning a Group into a Choice

Some choices are built out of large numbers of values, often integers, each of which is best given a semantic name in the specification. Instead of naming each of these integers and then accumulating them into a choice, CDDL allows building a choice from a group by prefixing it with an "&" character:

           terminal-color = &basecolors
           basecolors = (
             black: 0,  red: 1,  green: 2,  yellow: 3,
             blue: 4,  magenta: 5,  cyan: 6,  white: 7,
           )
           extended-color = &(
             basecolors,
             orange: 8,  pink: 9,  purple: 10,  brown: 11,
           )

           terminal-color = &basecolors
           basecolors = (
             black: 0,  red: 1,  green: 2,  yellow: 3,
             blue: 4,  magenta: 5,  cyan: 6,  white: 7,
           )
           extended-color = &(
             basecolors,
             orange: 8,  pink: 9,  purple: 10,  brown: 11,
           )

           terminal-color = &basecolors
           basecolors = (
             black: 0,  red: 1,  green: 2,  yellow: 3,
             blue: 4,  magenta: 5,  cyan: 6,  white: 7,
           )
           extended-color = &(
             basecolors,
             orange: 8,  pink: 9,  purple: 10,  brown: 11,
           )

As with the use of groups in arrays (Section 3.4), the member names have only documentary value (in particular, they might be used by a tool when displaying integers that are taken from that choice).

配列内でのグループの使用についても（セクション3.4）、メンバー名はただの文書的な値です（特に、その選択肢から取られた整数を表示するツールで使用される可能性があります）。

2.2.3. Representation Types

CDDL allows the specification of a data item type by referring to the CBOR representation (specifically, to major types and additional information; see Section 2 of [RFC7049]). How this is used should be evident from the prelude (Appendix D): a hash mark ("#") optionally followed by a number from 0 to 7 identifying the major type, which then can be followed by a dot and a number specifying the additional information. This construction specifies the set of values that can be serialized in CBOR (i.e., "any"), by the given major type if one is given, or by the given major type with the additional information if both are given. Where a major type of 6 (Tag) is used, the type of the tagged item can be specified by appending it in parentheses.

CDDLでは、データ項目のタイプをCBOR表現（具体的には主要なタイプと追加情報を参照すること）によって指定することができます（詳細は[RFC7049]のSection 2を参照）。これがどのように使用されるかについては、序文（付録D）から明らかになるはずです：ハッシュマーク（"#"）の後に、主なタイプを識別する0から7の番号（オプション）が続き、その後にドットと追加情報を指定する番号が続きます。この構造は、与えられた主なタイプがあれば、または与えられた主なタイプと追加情報があれば、CBORに直列化できる値のセットを指定します（つまり、「任意の値」）。主なタイプが6（タグ）の場合、タグ付けされたアイテムのタイプは、括弧内に追加で指定できます。

Note that although this notation is based on the CBOR serialization, it is about a set of values at the data model level, e.g., "#7.25" specifies the set of values that can be represented as half-precision floats; it does not mandate that these values also do have to be serialized as half-precision floats: CDDL does not provide any language means to restrict the choice of serialization variants. This also enables the use of CDDL with JSON, which uses a fundamentally different way of serializing (some of) the same values.

CBORシリアライズに基づくこの表記法は、データモデルレベルの値の集合について言及しています。例えば、"#7.25"は半精度浮動小数点数として表現できる値の集合を指定していますが、これらの値が半精度浮動小数点数としてシリアライズされる必要があるわけではありません。CDDLは、シリアライズのバリアントの選択を制約するための言語手段を提供していません。これにより、CDDLはJSONとも組み合わせて使用することができます。JSONは同じ値を（一部）異なる方法でシリアライズする基本的に異なる方法を使用しています。

It may be necessary to make use of representation types outside the prelude, e.g., a specification could start by making use of an existing tag in a more specific way or could define a new tag not defined in the prelude:

事前文書以外の表現タイプを利用する必要がある場合があります。例えば、仕様書は、既存のタグをより具体的な方法で使用したり、事前文書で定義されていない新しいタグを定義したりすることがあります。

   my_breakfast = #6.55799(breakfast)   ; cbor-any is too general!
   breakfast = cereal / porridge
   cereal = #6.998(tstr)
   porridge = #6.999([liquid, solid])
   liquid = milk / water
   milk = 0
   water = 1
   solid = tstr

   my_breakfast = #6.55799(breakfast)   ; cbor-any is too general!
   breakfast = cereal / porridge
   cereal = #6.998(tstr)
   porridge = #6.999([liquid, solid])
   liquid = milk / water
   milk = 0
   water = 1
   solid = tstr

2.2.4. Root Type

There is no special syntax to identify the root of a CDDL data structure definition: that role is simply taken by the first rule defined in the file.

特定の構文を使用してCDDLデータ構造の定義のルートを識別する特別な方法はありません。「ルート」という役割は単純にファイルで最初に定義されたルールが担当します。

This is motivated by the usual top-down approach for defining data structures, decomposing a big data structure unit into smaller parts; however, except for the root type, there is no need to strictly follow this sequence.

(Note that there is no way to use a group as a root -- it must be a type.)

（グループをルートとして使用する方法はないことに注意してください - タイプである必要があります。）

3. Syntax

In this section, the overall syntax of CDDL is shown, alongside some examples just illustrating syntax. (The definition does not attempt to be overly formal; refer to Appendix B for details.)

このセクションでは、CDDLの全体的な構文が示され、構文を説明するいくつかの例も示されます。（この定義は過度に正式を目指すものではありません。詳細については、付録Bを参照してください。）

3.1. General Conventions

The basic syntax is inspired by ABNF [RFC5234], with the following:

基本の構文はABNFに触発されており、以下のものを持っています：[RFC5234]という規則による。

Rules, whether they define groups or types, are defined with a name, followed by an equals sign "=" and the actual definition according to the respective syntactic rules of that definition.

ルールは、グループまたはタイプを定義するかどうかに関係なく、名前で定義され、イコール記号「=」とその定義に対する実際の定義が続きます。定義は、それに対応する構文規則に従って行われます。

A name can consist of any of the characters from the set {"A" to "Z", "a" to "z", "0" to "9", "_", "-", "@", ".", "$"}, starting with an alphabetic character (including "@", "_", "$") and ending in such a character or a digit.

名前は、アルファベット文字（"@", "_", "$"を含む）で始まり、アルファベット文字または数字で終わることができます。使用可能な文字は、セット{"A"から"Z"、"a"から"z"、"0"から"9"、"_", "-", "@", ".", "$"}です。

   *  Names are case sensitive.

   *  Names are case sensitive.

   *  It is preferred style to start a name with a lowercase letter.

   *  名前は小文字で始めることが推奨されます。

   *  The hyphen is preferred over the underscore (except in a
      "bareword" (Section 3.5.1), where the semantics may actually
      require an underscore).

  - アンダースコアよりハイフンが好まれます（ただし、「基本語」（セクション3.5.1）では、意味によっては実際にアンダースコアが必要になる場合もあります）。

   *  The period may be useful for larger specifications, to express
      some module structure (as in "tcp.throughput" vs.
      "udp.throughput").

*  期間は、より大規模な仕様において、モジュールの構造（例：「tcp.throughput」と「udp.throughput」）を表現するために使用できます。

   *  A number of names are predefined in the CDDL prelude, as listed
      in Appendix D.

   *  数多くの名前がCDDLプレリュードで予め定義されており、
      Appendix Dにリストされています。

   *  Rule names (types or groups) do not appear in the actual CBOR
      encoding, but names used as "barewords" in member keys do.

   *  ルールの名称（タイプまたはグループ）は、実際のCBORエンコーディングには表示されませんが、メンバーキーとして使用される「裸の単語」には表示されます。

Comments are started by a ";" (semicolon) character and finish at the end of a line (LF or CRLF).

コメントは";"（セミコロン）文字で始まり、行の最後（LFまたはCRLF）で終了します。

Except within strings, whitespace (spaces, newlines, and comments) is used to separate syntactic elements for readability (and to separate identifiers, range operators, or numbers that follow each other); it is otherwise completely optional.

文字列以外では、可読性のため（および互いに続く識別子、範囲演算子、または数値を区別するため）、空白（スペース、改行、コメント）は構文要素を区切るために使用されます。その他の場合、空白は完全にオプションです。

Hexadecimal numbers are preceded by "0x" (without quotes) and are case insensitive. Similarly, binary numbers are preceded by "0b".

16進数の数字は、クォーテーションなしで "0x" で始まり、大文字小文字を区別しません。同様に、2進数の数字は "0b" で始まります。

Text strings are enclosed by double quotation '"' characters. They follow the conventions for strings as defined in Section 7 of [RFC8259]. (ABNF users may want to note that there is no support in CDDL for the concept of case insensitivity in text strings; if necessary, regular expressions can be used (Section 3.8.3).)

テキスト文字列は、二重引用符「"」で囲まれています。これらは[RFC8259]のセクション7で定義されている文字列の規則に従います。（ABNFのユーザーは、テキスト文字列の大文字小文字の概念に対するCDDLのサポートがないことに注意するかもしれません。必要な場合は、正規表現を使用できます（セクション3.8.3）。）

Byte strings are enclosed by single quotation "'" characters and may be prefixed by "h" or "b64". If unprefixed, the string is interpreted as with a text string, except that single quotes must be escaped and that the resulting UTF-8 bytes are marked as a byte string (major type 2). If prefixed as "h" or "b64", the string is interpreted as a sequence of pairs of hex digits (base16; see Section 8 of [RFC4648]) or a base64(url) string (Section 4 or Section 5 of [RFC4648]), respectively (as with the diagnostic notation in Section 6 of [RFC7049]; cf. Appendix G.2); any whitespace present within the string (including comments) is ignored in the prefixed case.

バイト文字列は単一引用符 "'" で囲まれ、"h" または "b64" で接頭辞が付けられる場合があります。接頭辞がない場合、文字列はテキスト文字列として解釈されますが、シングルクォートはエスケープする必要があり、結果として得られるUTF-8バイトはバイト文字列（メジャータイプ2）としてマークされます。"h" または "b64" として接頭辞が付けられる場合、文字列はスクリプト16進数のペアのシーケンス（基数16; [RFC4648] のセクション8を参照）またはbase64(url)文字列（[RFC4648] のセクション4またはセクション5）として解釈されます（[RFC7049] のセクション6の診断表記と同様；付録G.2を参照）。接頭辞の場合、文字列内の空白（コメントを含む）は無視されます。

CDDL uses UTF-8 [RFC3629] for its encoding. Processing of CDDL does not involve Unicode normalization processes.

CDDLは、エンコーディングにUTF-8[RFC3629]を使用します。CDDLの処理には、Unicodeの正規化プロセスは関与しません。

Example:

MUST applies to the sender's action that the specification requires to be performed in order to correctly implement the protocol. The term MUST NOT applies to the sender's action that the specification prohibits in order to correctly implement the protocol. The term REQUIRED means that the specification uses the term MUST and enforces its usage. Similarly, the terms SHALL and SHALL NOT are used in the same way.

                 ; This is a comment
                 person = { g }

                 ; This is a comment
                 person = { g }

                 g = (
                   "name": tstr,
                   age: int,  ; "age" is a bareword
                 )

                 g = (
                   "name": tstr,
                   age: int,  ; "age" is a bareword
                 )

                 g = (
                   "name": tstr,
                   age: int,  ; "age" is a bareword
                 )

3.2. Occurrence

An optional _occurrence_ indicator can be given in front of a group entry. It is either (1) one of the characters "?" (optional), "*" (zero or more), or "+" (one or more) or (2) of the form n*m, where n and m are optional unsigned integers and n is the lower limit (default 0) and m is the upper limit (default no limit) of occurrences.

グループエントリの前にオプションの発生インジケータを指定することができます。それは、(1) オプションの場合は "?" (オプションあり)、"*" (0回以上)、または "+" (1回以上) のいずれかであるか、(2) n*m の形式であり、n と m はオプションの符号なし整数であり、n が下限 (デフォルト 0) であり、m が上限 (デフォルト制限なし) であります。

If no occurrence indicator is specified, the group entry is to occur exactly once (as if 1*1 were specified). A group entry with an occurrence indicator matches sequences of name/value pairs that are composed by concatenating a number of sequences that the basic group entry matches, where the number needs to be allowed by the occurrence indicator.

もし発生インジケータが指定されていない場合、グループエントリは正確に1回発生する必要があります（1*1 が指定されたかのように）。発生インジケータに許可された数によって、基本グループエントリが一致する一連の名前/値ペアのシーケンスを結合して構成されるグループエントリが一致します。

Note that CDDL, outside any directives/annotations that could possibly be defined, does not make any prescription as to whether arrays or maps use definite-length or indefinite-length encoding. That is, there is no correlation between leaving the size of an array "open" in the spec and the fact that it is then interchanged with definite or indefinite length.

CDDLは、定義される可能性のあるいかなる指示/注釈の外部でも、配列またはマップが明示的な長さの符号化または非明示的な長さの符号化を使用するかどうかについて何ら規定しません。つまり、仕様で配列のサイズを「開いた」状態にしたことと、それが明示的な長さまたは非明示的な長さで交換されるという事実との間には、相関関係がありません。

Please also note that CDDL can describe flexibility that the data model of the target representation does not have. This is rather obvious for JSON but is also relevant for CBOR:

以下の情報も注意してください。CDDLは、対象表現のデータモデルには存在しない柔軟性を記述することができます。これはJSONにとっては明らかですが、CBORにも関連しています。

                        apartment = {
                          kitchen: size,
                          * bedroom: size,
                        }
                        size = float ; in m2

                        apartment = {
                          kitchen: size,
                          * bedroom: size,
                        }
                        size = float ; in m2

The previous specification does not mean that CBOR is changed to allow using the key "bedroom" more than once. In other words, due to the restrictions imposed by the data model, the third line pretty much turns into:

以前の仕様では、「bedroom」というキーを複数回使用することを許可するためにCBORが変更されるわけではありません。言い換えると、データモデルによって課される制約のため、3行目はほとんど以下のようになります:

                          ? bedroom: size,

                          ? ベッドルーム：広さ、

(Occurrence indicators beyond one are still useful in maps for groups that allow a variety of keys.)

（複数の発生指標は、さまざまなキーを許容するグループのマップにおいて依然として有用です。）

3.3. Predefined Names for Types

CDDL predefines a number of names. This subsection summarizes these names, but please see Appendix D for the exact definitions.

CDDLはいくつかの名前を予め定義しています。この節ではこれらの名前をまとめていますが、詳細な定義については付録Dを参照してください。

The following keywords for primitive datatypes are defined:

以下のプリミティブデータ型に対するキーワードが定義されています：

"bool" Boolean value (major type 7, additional information 20 or 21).

「bool」はブール値です（メジャータイプ7、追加情報20または21）。

"uint" An unsigned integer (major type 0).

「uint」とは、符号なし整数（メジャータイプ0）を表すものです。

"nint" A negative integer (major type 1).

「nint」とは、負の整数を表すためのタグ（主要タイプ1）です。

"int" An unsigned integer or a negative integer.

「int」は符号なし整数または負の整数です。

"float16" A number representable as a half-precision float [IEEE754] (major type 7, additional information 25).

「float16」とは、半精度浮動小数点数 [IEEE754]（主要型7、追加情報25）で表すことができる数字です。

"float32" A number representable as a single-precision float [IEEE754] (major type 7, additional information 26).

"float64" A number representable as a double-precision float [IEEE754] (major type 7, additional information 27).

「float64」は、IEEE754に準拠した倍精度浮動小数点数で表される数値です（主要タイプ7、追加情報27）。

"float" One of float16, float32, or float64.

「float」は、float16、float32、またはfloat64のいずれかです。

"bstr" or "bytes" A byte string (major type 2).

「bstr」または「バイト」は、バイト文字列です（メジャータイプ2）。

"tstr" or "text" Text string (major type 3).

「tstr」または「text」は、テキスト文字列（メジャータイプ3）です。

(Note that there are no predefined names for arrays or maps; these are defined with the syntax given below.)

（配列やマップのための予め定義された名前はないことに注意してください。これらは以下の構文で定義されます。）

In addition, a number of types are defined in the prelude that are associated with CBOR tags, such as "tdate", "bigint", "regexp", etc.

さらに、"tdate"、"bigint"、"regexp"などのCBORタグに関連付けられたいくつかの型がプレリュードで定義されています。

3.4. Arrays

Array definitions surround a group with square brackets.

配列の定義は、グループを角かっこで囲みます。

For each entry, an occurrence indicator as specified in Section 3.2 is permitted.

それぞれのエントリについて、セクション3.2で指定されている出現指示子を許可します。

For example:

例えば:

                  unlimited-people = [* person]
                  one-or-two-people = [1*2 person]
                  at-least-two-people = [2* person]
                  person = (
                      name: tstr,
                      age: uint,
                  )

                  unlimited-people = [* person]
                  one-or-two-people = [1*2 person]
                  at-least-two-people = [2* person]
                  person = (
                      name: tstr,
                      age: uint,
                  )

                  unlimited-people = [* person]
                  one-or-two-people = [1*2 person]
                  at-least-two-people = [2* person]
                  person = (
                      name: tstr,
                      age: uint,
                  )

The group "person" is defined in such a way that repeating it in the array each time generates alternating names and ages, so these are four valid values for a data item of type "unlimited-people":

「person」というグループは、配列内で繰り返し使用することで交互に名前と年齢が生成されるように定義されています。したがって、「unlimited-people」というデータ項目のタイプには、以下の4つの有効な値があります。

   ["roundlet", 1047, "psychurgy", 2204, "extrarhythmical", 2231]
   []
   ["aluminize", 212, "climograph", 4124]
   ["penintime", 1513, "endocarditis", 4084, "impermeator", 1669,
    "coextension", 865]

   ["roundlet", 1047, "psychurgy", 2204, "extrarhythmical", 2231]
   []
   ["aluminize", 212, "climograph", 4124]
   ["penintime", 1513, "endocarditis", 4084, "impermeator", 1669,
    "coextension", 865]

3.5. Maps

The syntax for specifying maps merits special attention, as well as a number of optimizations and conveniences, as it is likely to be the focal point of many specifications employing CDDL. While the syntax does not strictly distinguish struct and table usage of maps, it caters specifically to each of them.

マップを指定するための構文は特別な注意が必要であり、CDDLを使用する多くの仕様の焦点となる可能性があるため、最適化と利便性の数も重要です。構文は厳密にはマップの構造体とテーブルの使用を区別しませんが、それぞれに特化しています。

But first, let's reiterate a feature of CBOR that it has inherited from JSON: the key/value pairs in CBOR maps have no fixed ordering. (One could imagine situations where fixing the ordering may be of use. For example, a decoder could look for values related with integer keys 1, 3, and 7. If the order were fixed and the decoder encounters the key 4 without having encountered key 3, it could conclude that key 3 is not available without doing more complicated bookkeeping. Unfortunately, neither JSON nor CBOR supports this, so no attempt was made to support this in CDDL either.)

しかし、まず、JSONから引き継がれたCBORの特徴を再確認しましょう。CBORマップ内のキー/値ペアは固定の順序を持ちません（オーダーメイキングされません）。（注：順序を固定することが有用な状況を想像することができます。例えば、デコーダは整数キー1、3、および7に関連する値を探し出すことができます。もし順序が固定されており、デコーダがキー3に遭遇する前にキー4がエンカウントされる場合、より複雑なブックキーピングを行うことなくキー3が利用できないことが判断できます。残念ながら、JSONもCBORもこれをサポートしていないため、CDDLでもこれをサポートする試みは行われませんでした。）

3.5.1. Structs

The "struct" usage of maps is similar to the way JSON objects are used in many JSON applications.

「struct」のマップの使用方法は、多くのJSONアプリケーションでJSONオブジェクトが使用される方法に類似しています。

A map is defined in the same way as that for defining an array (see Section 3.4), except for using curly braces "{}" instead of square brackets "[]".

3.4

An occurrence indicator as specified in Section 3.2 is permitted for each group entry.

The following is an example of a record with a structure embedded:

以下は、構造が埋め込まれたレコードの例です。

    Geography = [
      city           : tstr,
      gpsCoordinates : GpsCoordinates,
    ]

    Geography = [
      city           : tstr,
      gpsCoordinates : GpsCoordinates,
    ]

    GpsCoordinates = {
      longitude      : uint,            ; degrees, scaled by 10^7
      latitude       : uint,            ; degrees, scaled by 10^7
    }

    GpsCoordinates = {
      longitude      : uint,            ; degrees, scaled by 10^7
      latitude       : uint,            ; degrees, scaled by 10^7
    }

    GpsCoordinates = {
      longitude      : uint,            ; degrees, scaled by 10^7
      latitude       : uint,            ; degrees, scaled by 10^7
    }

When encoding, the Geography record is encoded using a CBOR array with two members (the keys for the group entries are ignored), whereas the GpsCoordinates structure is encoded as a CBOR map with two key/value pairs.

エンコード時に、ジオグラフィーレコードは、2つのメンバー（グループエントリのキーは無視されます）を持つCBOR配列としてエンコードされます。一方、GpsCoordinates構造体は、2つのキー/値ペアを持つCBORマップとしてエンコードされます。

Types used in a structure can be defined in separate rules or just in place (potentially placed inside parentheses, such as for choices). For example:

                        located-samples = {
                          sample-point: int,
                          samples: [+ float],
                        }

                        located-samples = {
                          sample-point: int,
                          samples: [+ float],
                        }

where "located-samples" is the datatype to be used when referring to the struct, and "sample-point" and "samples" are the keys to be used. This is actually a complete example: an identifier that is followed by a colon can be directly used as the text string for a member key (we speak of a "bareword" member key), as can a double-quoted string or a number. (When other types -- in particular, types that contain more than one value -- are used as the types of keys, they are followed by a double arrow; see below.)

「located-samples」というデータ型は、struct を参照する際に使用されるべきであり、「sample-point」と「samples」というキーを使用する必要があります。これは実際に完全な例です：コロンに続く識別子は、メンバーキーのテキスト文字列として直接使用することができます（「bareword」メンバーキーと呼びます）、ダブルクォーテーションで囲まれた文字列や数値も同様です。（他のタイプ、特に複数の値を含むタイプがキーのタイプとして使用される場合、ダブルアローに続きます；詳細は以下を参照してください。）

If a text string key does not match the syntax for an identifier (or if the specifier just happens to prefer using double quotes), the text string syntax can also be used in the member key position, followed by a colon. The above example could therefore have been written with quoted strings in the member key positions.

テキスト文字列キーが識別子の構文と一致しない場合（または仕様者が二重引用符を使用することを好む場合）、テキスト文字列構文はメンバーキーの位置にも使用でき、その後にコロンを続けます。したがって、上記の例は、メンバーキーの位置に引用符で囲まれた文字列を使用しても書くことができました。

More generally, types specified in ways other than those listed for the cases described above can be used in a key-type position by following them with a double arrow -- in particular, the double arrow is necessary if a type is named by an identifier (which, when followed by a colon, would be interpreted as a "bareword" and turned into a text string). A literal text string also gives rise to a type (which contains a single value only -- the given string), so another form for this example is:

一般的に、上記のケースで述べられているもの以外の方法で指定された型は、それらに続けて二重矢印を使用することで、キーの型の位置で使用することができます。特に、型が識別子によって名前付けられている場合（コロンに続いて使用されると、「裸のワード」と解釈されてテキスト文字列に変換されることがある）は、二重矢印が必要です。リテラルテキスト文字列もまた、型を生成します（与えられた文字列のみを含む型です）。したがって、この例の別の形式は次のようになります：

                      located-samples = {
                        "sample-point" => int,
                        "samples" => [+ float],
                      }

located-samples = { "sample-point" => int, "samples" => [+ float], }

                      located-samples = {
                        "sample-point" => int,
                        "samples" => [+ float],
                      }

See Section 3.5.4 below for how the colon (":") shortcut described here also adds some implied semantics.

ここで説明されているコロン（":"）のショートカットによっても一部の暗黙的な意味が追加される方法については、以下のセクション3.5.4を参照してください。

A better way to demonstrate the use of the double arrow may be:

ダブルアローの使用方法をよりよく示す方法は、次のようなものかもしれません：

          located-samples = {
            sample-point: int,
            samples: [+ float],
            * equipment-type => equipment-tolerances,
          }
          equipment-type = [name: tstr, manufacturer: tstr]
          equipment-tolerances = [+ [float, float]]

          located-samples = {
            sample-point: int,
            samples: [+ float],
            * equipment-type => equipment-tolerances,
          }
          equipment-type = [name: tstr, manufacturer: tstr]
          equipment-tolerances = [+ [float, float]]

          located-samples = {
            sample-point: int,
            samples: [+ float],
            * equipment-type => equipment-tolerances,
          }
          equipment-type = [name: tstr, manufacturer: tstr]
          equipment-tolerances = [+ [float, float]]

The example below defines a struct with optional entries: display name (as a text string), the name components first name and family name (as text strings), and age information (as an unsigned integer).

以下の例では、オプションのエントリを持つ構造体が定義されています。表示名（テキスト文字列）、名前の構成要素である名（テキスト文字列）、および年齢情報（符号なし整数）です。

                       PersonalData = {
                         ? displayName: tstr,
                         NameComponents,
                         ? age: uint,
                       }

                       PersonalData = {
                         ? displayName: tstr,
                         NameComponents,
                         ? age: uint,
                       }

                       PersonalData = {
                         ? displayName: tstr,
                         NameComponents,
                         ? age: uint,
                       }

                       NameComponents = (
                         ? firstName: tstr,
                         ? familyName: tstr,
                       )

                       NameComponents = (
                         ? firstName: tstr,
                         ? familyName: tstr,
                       )

                       NameComponents = (
                         ? firstName: tstr,
                         ? familyName: tstr,
                       )

Note that the group definition for NameComponents does not generate another map; instead, all four keys are directly in the struct built by PersonalData.

NameComponentsのグループ定義では、別のマップを生成しません。代わりに、すべての4つのキーはPersonalDataによって作成された構造体に直接格納されます。

In this example, all key/value pairs are optional from the perspective of CDDL. With no occurrence indicator, an entry is mandatory.

この例では、CDDLの観点から見て、すべてのキー/値のペアはオプションです。発生指示子がない場合、エントリーは必須です。

If the addition of more entries not specified by the current specification is desired, one can add this possibility explicitly:

現在の仕様で指定されていないさらなるエントリの追加が必要な場合、この可能性を明示的に追加することができます。

                       PersonalData = {
                         ? displayName: tstr,
                         NameComponents,
                         ? age: uint,
                         * tstr => any
                       }

                      PersonalData = {
                        ? displayName: tstr,
                        NameComponents,
                        ? age: uint,
                        * tstr => any
                      }

                      PersonalData = {
                        ? displayName: tstr,
                        NameComponents,
                        ? age: uint,
                        * tstr => any
                      }

                       NameComponents = (
                         ? firstName: tstr,
                         ? familyName: tstr,
                       )

                       NameComponents = (
                         ? firstName: tstr,
                         ? familyName: tstr,
                       )

       NameComponents = (
          ? firstName: tstr,
          ? familyName: tstr,
       )

Figure 7: Personal Data: Example for Extensibility

Figure 7: 個人データ：拡張性の例

The CDDL tool described in Appendix F generated the following as one acceptable instance for this specification:

付録Fで説明されたCDDLツールは、この仕様に対して受け入れ可能な1つのインスタンスを生成しました。

      {"familyName": "agust", "antiforeignism": "pretzel",
       "springbuck": "illuminatingly", "exuviae": "ephemeris",
       "kilometrage": "frogfish"}

      {"familyName": "agust", "antiforeignism": "pretzel",
       "springbuck": "illuminatingly", "exuviae": "ephemeris",
       "kilometrage": "frogfish"}

(See Section 3.9 for one way to explicitly identify an extension point.)

（エクステンションポイントを明示的に識別する方法の一つについては、セクション3.9を参照してください。）

3.5.2. Tables

A table can be specified by defining a map with entries where the key type allows more than just a single value; for example:

テーブルは、キーのタイプが単一の値だけでなく複数の値を許容する場合、エントリーを持つマップを定義することで指定することができます。例えば：

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

                      square-roots = {* x => y}
                      x = int
                      y = float

Here, the key in each key/value pair has datatype x (defined as int), and the value has datatype y (defined as float).

ここでは、各キー/値のペアのキーはデータ型x（整数として定義）であり、値はデータ型y（浮動小数点数として定義）です。

If the specification does not need to restrict one of x or y (i.e., the application is free to choose per entry), it can be replaced by the predefined name "any".

仕様書がxまたはyのいずれかを制限する必要がない場合（つまり、アプリケーションはエントリごとに自由に選択できる）、事前定義済みの名前「any」で置き換えることができます。

As another example, the following could be used as a conversion table converting from an integer or float to a string:

別の例として、整数または浮動小数点数から文字列に変換するための変換テーブルとして、次のものが使用される可能性があります。

                   tostring = {* mynumber => tstr}
                   mynumber = int / float

                   tostring = {* mynumber => tstr}
                   mynumber = int / float

                   tostring = {* mynumber => tstr}
                   mynumber = int / float

3.5.3. Non-deterministic Order

While the way arrays are matched is fully determined by the PEG formalism (see Appendix A), matching is more complicated for maps, as maps do not have an inherent order. For each candidate name/value pair that the PEG algorithm would try, a matching member is picked out of the entire map. For certain group expressions, more than one member in the map may match. Most often, this is inconsequential, as the group expression tends to consume all matches:

PEG形式（付録Aを参照）によって配列がどのようにマッチされるかは完全に決定されますが、マップのマッチングはより複雑です。マップには固有の順序がないためです。 PEGアルゴリズムが試す候補の名前/値ペアごとに、マップ全体からマッチするメンバーが選択されます。グループ式では、マップ内の複数のメンバーがマッチする場合があります。ほとんどの場合、これは重要ではありませんが、グループ式は通常、すべてのマッチを消費します。

                         labeled-values = {
                           ? fritz: number,
                           * label => value
                         }
                         label = text
                         value = number

                         labeled-values = {
                           ? fritz: number,
                           * label => value
                         }
                         label = text
                         value = number

                         labeled-values = {
                           ? fritz: number,
                           * label => value
                         }
                         label = テキスト
                         value = 数字

Here, if any member with the key "fritz" is present, this will be picked by the first entry of the group; all remaining text/number members will be picked by the second entry (and if anything remains unpicked, the map does not match).

ここでは、キーが「fritz」のメンバーが存在する場合、これはグループの最初のエントリによって選択されます。残りのテキスト/数値メンバーは2番目のエントリによって選択されます（そして何かが選択されないままであれば、マップは一致しません）。

However, it is possible to construct group expressions where what is actually picked is indeterminate, but does matter:

                         do-not-do-this = {
                           int => int,
                           int => 6,
                         }

                         do-not-do-this = {
                           int => int,
                           int => 6,
                         }

                         以下は行ってはならない = {
                           int => int,
                           int => 6,
                         }

When this expression is matched against "{3: 5, 4: 6}", the first group entry might pick off the "3: 5", leaving "4: 6" for matching the second one. Or it might pick off "4: 6", leaving nothing for the second entry. This pathological non-determinism is caused by specifying "more general" before "more specific" and by having a general rule that only consumes a subset of the map key/value pairs that it is able to match -- both tend not to occur in real-world specifications of maps. At the time of writing, CDDL tools cannot detect such cases automatically, and for the present version of the CDDL specification, the specification writer is simply urged to not write pathologically non-deterministic specifications.

この式が"{3: 5, 4: 6}"と一致するとき、最初のグループエントリは「3: 5」を選択し、「4: 6」は2番目のエントリと一致するために残されるかもしれません。または、最初のエントリは「4: 6」を選択し、2番目のエントリには何も残りません。このような病理的な非決定性は、「より一般的」な部分が「より具体的」な部分よりも前に指定されていること、または一般規則が、それが一致できるマップのキー/値のサブセットのみを消費するという一般的なルールによって引き起こされます。「より一般的」な部分が「より具体的」な部分よりも前に指定されることや、マップのキー/値のサブセットのみを一致させるように求められるこの一般的なルールは、実際の仕様ではあまり発生しない傾向があります。本文作成時点では、CDDLツールはこのようなケースを自動的に検出することができません。したがって、現在のCDDL仕様では、仕様の筆者に対して病理的な非決定的な仕様を記述しないように要請されています。

(The astute reader will be reminded of what was called "ambiguous content models" in the Standard Generalized Markup Language (SGML) and "non-deterministic content models" in XML. That problem is related to the one described here, but the problem here is specifically caused by the lack of order in maps, something that the XML schema languages do not have to contend with. Note that RELAX NG's "interleave" pattern handles lack of order explicitly on the specification side, while the instances in XML always have determinate order.)

3.5.4. Cuts in Maps

The extensibility idiom discussed above for structs has one problem:

上記の構造体に関する拡張性のイディオムには1つの問題があります：

                     extensible-map-example = {
                       ? "optional-key" => int,
                       * tstr => any
                     }

                     extensible-map-example = {
                       ? 「選択できます（OPTIONAL）-キー」 => int,
                       * tstr => any
                     }

In this example, there is one optional key "optional-key", which, when present, maps to an integer. There is also a wildcard for any future additions.

この例では、オプションのキー「optional-key」が1つあります。存在する場合、整数にマップされます。また、将来の追加のためのワイルドカードも存在します。

Unfortunately, the data item

OPTIONAL

                   { "optional-key": "nonsense" }

                   { "optional-key": "nonsense" }

                   { "optional-key": "nonsense" }

does match this specification: while the first entry of the group does not match, the second one (the wildcard) does. This may very well be desirable (e.g., if a future extension is to be allowed to extend the type of "optional-key"), but in many cases it isn't.

この仕様と一致します：グループの最初のエントリが一致しない間、2番目のエントリ（ワイルドカード）が一致します。これは望ましい場合もあります（例：将来の拡張で「オプションキー」のタイプを拡張できるようにする場合など）、しかし多くの場合そうではありません。

In anticipation of a more general potential feature called "cuts", CDDL allows inserting a cut "^" into the definition of the map entry:

"カット"というより一般的な潜在的な機能を見越して、CDDLはマップエントリの定義に「^」を挿入することを許可しています。

                    extensible-map-example = {
                      ? "optional-key" ^ => int,
                      * tstr => any
                    }

                    extensible-map-example = {
                      ? "-key" ^ => int,
                      * tstr => any
                    }

A cut in this position means that once the member key matches the name part of an entry that carries a cut, other potential matches for the key of the member that occur in later entries in the group of the map are no longer allowed. In other words, when a group entry would pick a key/value pair based on just a matching key, it "locks in" the pick -- this rule applies, independently of whether the value matches as well, so when it does not, the entire map fails to match. In summary, the example above no longer matches the specification as modified with the cut.

この位置でのカットは、メンバーキーがカットを持つエントリーの名前部分と一致すると、マップのグループ内の後のエントリーでのメンバーのキーの他の潜在的な一致が許可されなくなることを意味します。つまり、グループエントリーがマッチングキーに基づいてキー/値ペアを選択する場合、その選択は「固定」されます。このルールは、値の一致有無に関係なく適用され、一致しない場合は、マップ全体が一致しなくなります。要約すると、前述の例は、カットで変更された仕様と一致しなくなります。

Since the desire for this kind of exclusive matching is so frequent, the ":" shortcut is actually defined to include the cut semantics. So, the preceding example (including the cut) can be written more simply as:

このような排他的なマッチングの要求が非常に頻繁であるため、「:」のショートカットは実際にはカットのセマンティクスを含むように定義されています。したがって、前述の例（カットを含む）は次のようにより簡潔に記述することができます。

                     extensible-map-example = {
                       ? "optional-key": int,
                       * tstr => any
                     }

                     extensible-map-example = {
                       ? "optional-key": int,
                       * tstr => any
                     }

                     extensible-map-example = {
                       ? "optional-key": int,
                       * tstr => any
                     }

or even shorter, using a bareword for the key:

または、キーに対して裸の単語を使用してさらに短くすることもできます。

                     extensible-map-example = {
                       ? optional-key: int,
                       * tstr => any
                     }

                     extensible-map-example = {
                       ? optional-key: int,
                       * tstr => any
                     }

                     extensible-map-example = {
                       ? optional-key: int,
                       * tstr => any
                     }

3.6. Tags

A type can make use of a CBOR tag (major type 6) by using the representation type notation, giving #6.nnn(type) where nnn is an unsigned integer giving the tag number and "type" is the type of the data item being tagged.

For example, the following line from the CDDL prelude (Appendix D) defines "biguint" as a type name for an unsigned bignum N:

たとえば、CDDLの序文（付録D）からの次の行は、符号なしの大きな数Nの型名として「biguint」を定義しています。

                        biguint = #6.2(bstr)

                        biguint = #6.2(bstr)

                        biguint = #6.2(bstr)

The tags defined by [RFC7049] are included in the prelude. Additional tags registered since [RFC7049] was written need to be added to a CDDL specification as needed; e.g., a binary Universally Unique Identifier (UUID) tag could be referenced as "buuid" in a specification after defining

                         buuid = #6.37(bstr)

                         buuid = #6.37(bstr)

                         buuid = #6.37(bstr)

In the following example, usage of tag 32 for URIs is optional:

                     my_uri = #6.32(tstr) / tstr

                     my_uri = #6.32(tstr) / tstr

                     my_uri = #6.32(tstr) / tstr

3.7. Unwrapping

The group that is used to define a map or an array can often be reused in the definition of another map or array. Similarly, a type defined as a tag carries an internal data item that one would like to refer to. In these cases, it is expedient to simply use the name of the map, array, or tag type as a handle for the group or type defined inside it.

マップまたは配列を定義するために使用されるグループは、多くの場合、別のマップまたは配列の定義に再利用されます。同様に、タグとして定義された型は、参照したい内部データアイテムを持っています。これらの場合、単にマップ、配列、またはタグ型の名前を、それ自体の定義されたグループまたは型のハンドルとして使用することが便利です。

The "unwrap" operator (written by preceding a name by a tilde character "~") can be used to strip the type defined for a name by one layer, exposing the underlying group (for maps and arrays) or type (for tags).

For example, an application might want to define a basic header and an advanced header. Without unwrapping, this might be done as follows:

          basic-header-group = (
            field1: int,
            field2: text,
          )

          basic-header-group = (
            field1: int,
            field2: text,
          )

          基本ヘッダーグループ = (
            field1: int,
            field2: text,
          )

          basic-header = [ basic-header-group ]

          basic-header = [ basic-header-group ]

          basic-header = [ basic-header-group ]

          advanced-header = [
            basic-header-group,
            field3: bytes,
            field4: number, ; as in the tagged type "time"
          ]

          advanced-header = [
            basic-header-group,
            field3: bytes,
            field4: number, ; as in the tagged type "time"
          ]

          advanced-header = [
            basic-header-group,
            field3: bytes,
            field4: number; タグ付けされた型「time」と同じく
          ]

Unwrapping simplifies this to:

アンラップすることで、これは簡略化されます。

                         basic-header = [
                           field1: int,
                           field2: text,
                         ]

                         basic-header = [
                           field1: int,
                           field2: text,
                         ]

                         基本ヘッダー = [
                           フィールド1: int,
                           フィールド2: text,
                         ]

                         advanced-header = [
                           ~basic-header,
                           field3: bytes,
                           field4: ~time,
                         ]

                         advanced-header = [
                           ~basic-header,
                           field3: bytes,
                           field4: ~time,
                         ]

(Note that leaving out the first unwrap operator in the latter example would lead to nesting the basic-header in its own array inside the advanced-header, while, with the unwrapped basic-header, the definition of the group inside basic-header is essentially repeated inside advanced-header, leading to a single array. This can be used for various applications often solved by inheritance in programming languages. The effect of unwrapping can also be described as "threading in" the group or type inside the referenced type, which suggested the thread-like "~" character.)

（後者の例では最初のunwrap演算子を省略すると、basic-headerがadvanced-header内の独自の配列にネストされることになりますが、unwrapped basic-headerを使用すると、basic-header内のグループの定義がadvanced-header内でも基本的に繰り返され、単一の配列が生成されます。これは、プログラミング言語での継承によって解決されることが多いさまざまなアプリケーションに使用されることがあります。unwrapの効果は、参照されたタイプ内のグループやタイプの"スレッドイン"としても表現できます。これは、スレッドのような"~"文字を示唆しています。）

3.8. Controls

A _control_ allows relating a _target_ type with a _controller_ type via a _control operator_.

制御は、制御演算子を介してターゲット型とコントローラー型を関連付けることを可能にします。

The syntax for a control type is "target .control-operator controller", where control operators are special identifiers prefixed by a dot. (Note that _target_ or _controller_ might need to be parenthesized.)

A number of control operators are defined at this point. Further control operators may be defined by new versions of this specification or by registering them according to the procedures in Section 6.1.

この時点で、いくつかの制御演算子が定義されています。さらなる制御演算子は、本仕様の新しいバージョンによって定義されるか、セクション6.1の手順に従って登録される場合があります。

3.8.1. Control Operator .size

A ".size" control controls the size of the target in bytes by the control type. The control is defined for text and byte strings, where it directly controls the number of bytes in the string. It is also defined for unsigned integers (see below). Figure 8 shows example usage for byte strings.

                full-address = [[+ label], ip4, ip6]
                ip4 = bstr .size 4
                ip6 = bstr .size 16
                label = bstr .size (1..63)

                full-address = [[+ label], ip4, ip6]
                ip4 = bstr .size 4
                ip6 = bstr .size 16
                label = bstr .size (1..63)

                full-address = [[+ label], ip4, ip6]
                ip4 = bstr .size 4
                ip6 = bstr .size 16
                label = bstr .size (1..63)

Figure 8: Control for Size in Bytes

Figure 8: バイトサイズの制御

When applied to an unsigned integer, the ".size" control restricts the range of that integer by giving a maximum number of bytes that should be needed in a computer representation of that unsigned integer. In other words, "uint .size N" is equivalent to "0...BYTES_N", where BYTES_N == 256**N.

非符号整数に適用される場合、".size"制御は、その整数の範囲を制限します。これは、その非符号整数のコンピュータ表現に必要な最大バイト数を指定することによって行われます。言い換えれば、"uint .size N" は "0...BYTES_N" と等価であり、ここで BYTES_N は 256**N です。

  audio_sample = uint .size 3 ; 24-bit, equivalent to 0...16777216

  audio_sample = uint .size 3 ; 24-bit, equivalent to 0...16777216

  audio_sample = uint .size 3 ; 24 ビットであり、0...16777216 に相当します。

Figure 9: Control for Integer Size in Bytes

Figure 9: 整数のバイトサイズに対する制御

Note that, as with value restrictions in CDDL, this control is not a representation constraint; a number that fits into fewer bytes can still be represented in that form, and an inefficient implementation could use a longer form (unless that is restricted by some format constraints outside of CDDL, such as the rules in Section 3.9 of [RFC7049]).

注意してください。CDDLの値制約と同様に、この制御は表現制約ではありません。より少ないバイトに収まる数値でもその形式で表現することができ、効率の悪い実装でもより長い形式を使用することができます（ただし、それがCDDL以外の形式制約によって制約されていない場合、例えば、[RFC7049]のSection 3.9のルールなど）。

3.8.2. Control Operator .bits

A ".bits" control on a byte string indicates that, in the target, only the bits numbered by a number in the control type are allowed to be set. (Bits are counted the usual way, bit number "n" being set in "str" meaning that "(str[n >> 3] & (1 << (n & 7))) != 0".) Similarly, a ".bits" control on an unsigned integer "i" indicates that for all unsigned integers "n" where "(i & (1 << n)) != 0", "n" must be in the control type.

                   tcpflagbytes = bstr .bits flags
                   flags = &(
                     fin: 8,
                     syn: 9,
                     rst: 10,
                     psh: 11,
                     ack: 12,
                     urg: 13,
                     ece: 14,
                     cwr: 15,
                     ns: 0,
                   ) / (4..7) ; data offset bits

                   tcpflagbytes = bstr .bits flags
                   flags = &(
                     fin: 8,
                     syn: 9,
                     rst: 10,
                     psh: 11,
                     ack: 12,
                     urg: 13,
                     ece: 14,
                     cwr: 15,
                     ns: 0,
                   ) / (4..7) ; data offset bits

                   tcpflagbytes = bstr .bits flags
                   flags = &(
                     fin: 8,
                     syn: 9,
                     rst: 10,
                     psh: 11,
                     ack: 12,
                     urg: 13,
                     ece: 14,
                     cwr: 15,
                     ns: 0,
                   ) / (4..7) ; データオフセットビット

                   rwxbits = uint .bits rwx
                   rwx = &(r: 2, w: 1, x: 0)

                   rwxbits = uint .bits rwx
                   rwx = &(r: 2, w: 1, x: 0)

                   rwxbits = uint .bits rwx
                   rwx = &(r: 2, w: 1, x: 0)

                   rwxbits = uint .bits rwx
                   rwx = &(r: 2, w: 1, x: 0)

Figure 10: Control for What Bits Can Be Set

Figure 10: ビットの設定に対する制御

The CDDL tool described in Appendix F generates the following ten example instances for "tcpflagbytes":

Appendix Fで述べられているCDDLツールは、「tcpflagbytes」のために以下の10個の例を生成します。

   h'906d' h'01fc' h'8145' h'01b7' h'013d' h'409f' h'018e' h'c05f'
   h'01fa' h'01fe'

   h'906d' h'01fc' h'8145' h'01b7' h'013d' h'409f' h'018e' h'c05f'
   h'01fa' h'01fe'

   h'906d' h'01fc' h'8145' h'01b7' h'013d' h'409f' h'018e' h'c05f'
   h'01fa' h'01fe'

These examples do not illustrate that the above CDDL specification does not explicitly specify a size of two bytes: a valid all-clear instance of flag bytes could be "h''" or "h'00'" or even "h'000000'" as well.

これらの例は、上記の CDDL 仕様に明示的に 2 バイトのサイズが指定されていないことを示していません。フラグバイトの有効な完全な例としては、"h''" や "h'00'"、そして "h'000000'" などがあります。

3.8.3. Control Operator .regexp

A ".regexp" control indicates that the text string given as a target needs to match the XML Schema Definition (XSD) regular expression given as a value in the control type. XSD regular expressions are defined in Appendix F of [W3C.REC-xmlschema-2-20041028].

「.regexp」コントロールは、ターゲットとして与えられたテキスト文字列が、コントロールタイプの値として与えられたXML Schema Definition（XSD）正規表現と一致する必要があることを示します。XSD正規表現は、[W3C.REC-xmlschema-2-20041028]の付録Fで定義されています。

  nai = tstr .regexp "[A-Za-z0-9]+@[A-Za-z0-9]+(\\.[A-Za-z0-9]+)+"

  nai = tstr .regexp "[A-Za-z0-9]+@[A-Za-z0-9]+(\\.[A-Za-z0-9]+)+"

  nai = tstr .regexp "[A-Za-z0-9]+@[A-Za-z0-9]+(\\.[A-Za-z0-9]+)+"

Figure 11: Control with an XSD regexp

Figure 11: XSD正規表現で制御する

An example matching this regular expression:

この正規表現に一致する例です：

                    "N1@CH57HF.4Znqe0.dYJRN.igjf"

                    "N1@CH57HF.4Znqe0.dYJRN.igjf"

3.8.3.1. Usage Considerations

Note that XSD regular expressions do not support the usual \x or \u escapes for hexadecimal expression of bytes or Unicode code points. However, in CDDL the XSD regular expressions are contained in text strings, the literal notation for which provides \u escapes; this should suffice for most applications that use regular expressions for text strings. (Note that this also means that there is one level of string escaping before the XSD escaping rules are applied.)

注意してください。XSD正規表現は、通常の\xや\uエスケープをサポートしていません。ただし、CDDLではXSD正規表現がテキスト文字列に含まれており、リテラル表記では\uエスケープが提供されています。これにより、テキスト文字列に正規表現を使用するほとんどのアプリケーションには十分です。（なお、これはXSDのエスケープ規則が適用される前に、1つのレベルの文字列エスケープがあることを意味します。）

XSD regular expressions support character class subtraction, a feature often not found in regular expression libraries; specification writers may want to use this feature sparingly. Similar considerations apply to Unicode character classes; where these are used, the specification that employs CDDL SHOULD identify which Unicode versions are addressed.

XSDの正規表現は文字クラスの差し引きをサポートしており、これは一般的な正規表現ライブラリではよく見られない機能です。仕様文書の作成者は、この機能を節約的に使用することを望むかもしれません。Unicode文字クラスにも同様の考慮が適用されます。これらが使用される場合、CDDLを使用する仕様書は対象となるUnicodeバージョンを特定する必要があります。

Other surprises for infrequent users of XSD regular expressions may include the following:

他の頻繁でないXSD正規表現の使用者にとっての予想外の事柄には、以下のものが含まれる場合があります。

No direct support for case insensitivity. While case insensitivity has gone mostly out of fashion in protocol design, it is sometimes needed and then needs to be expressed manually as in "[Cc][Aa][Ss][Ee]".

大文字と小文字を区別しない（case insensitivity）に対する直接のサポートはありません。プロトコルの設計では、大文字と小文字を区別しないことはほとんど流行していませんが、時には必要となり、その場合は手動で「[Cc][Aa][Ss][Ee]」のように明示する必要があります。

The support for popular character classes such as \w and \d is based on Unicode character properties; this is often not what is desired in an ASCII-based protocol and thus might lead to surprises. (\s and \S do have their more conventional meanings, and "." matches any character but the line-ending characters \r or \n.)

人気のある文字クラス（\wや\dなど）のサポートは、Unicodeの文字プロパティに基づいています。これはしばしばASCIIベースのプロトコルでは望ましい動作ではないため、予期しない結果になる可能性があります（\sと\Sは従来の意味を持っており、"."は改行文字\rまたは\n以外の任意の文字にマッチします）。

3.8.3.2. Discussion

There are many flavors of regular expression in use in the programming community. For instance, Perl-Compatible Regular Expressions (PCREs) are widely used and probably are more useful than XSD regular expressions. However, there is no normative reference for PCREs that could be used in the present document. Instead, we opt for XSD regular expressions for now. There is precedent for that choice in the IETF, e.g., in YANG [RFC7950].

プログラミングコミュニティでは、さまざまな種類の正規表現が使用されています。たとえば、Perl-Compatible Regular Expressions（PCRE）は広く使用されており、XSDの正規表現よりも便利かもしれません。ただし、現在のドキュメントで使用できるPCREの規範的な参照はありません。その代わり、現時点ではXSDの正規表現を選択します。IETFにはその選択の前例があります。たとえば、YANG [RFC7950]で使用されています。

Note that CDDL uses controls as its main extension point. This creates the opportunity to add further regular expression formats in addition to the one referenced here, if desired. As an example, a proposal for a ".pcre" control is defined in [CDDL-Freezer].

CDDLでは、制御を主な拡張ポイントとして使用していることに注意してください。これにより、望む場合には、ここで参照されているものに加えて、さらなる正規表現形式を追加する機会が生まれます。例えば、".pcre"制御の提案は、[CDDL-Freezer]で定義されています。

3.8.4. Control Operators .cbor and .cborseq

A ".cbor" control on a byte string indicates that the byte string carries a CBOR-encoded data item. Decoded, the data item matches the type given as the right-hand-side argument (type1 in the following example).

エレメントが右辺引数（以下の例ではtype1）と一致するデータアイテムであることを示すバイト文字列である".cbor"が、CBORエンコードされたデータアイテムを含んでいます。

   "bytes .cbor type1"

   "バイト .cbor 型1"

Similarly, a ".cborseq" control on a byte string indicates that the byte string carries a sequence of CBOR-encoded data items. When the data items are taken as an array, the array matches the type given as the right-hand-side argument (type2 in the following example).

同様に、バイト文字列上の「.cborseq」制御は、バイト文字列がCBORエンコードされたデータアイテムのシーケンスを含んでいることを示します。データアイテムが配列として取られる場合、配列は右辺の引数（以下の例ではtype2）と一致します。

   "bytes .cborseq type2"

   "bytes .cborseq type2"

   "bytes .cborseq type2"（バイト数 .cborseq タイプ2）

(The conversion of the encoded sequence to an array can be effected, for instance, by wrapping the byte string between the two bytes 0x9f and 0xff and decoding the wrapped byte string as a CBOR-encoded data item.)

（エンコードされたシーケンスを配列に変換するために、たとえばバイト文字列をバイト0x9fと0xffで挟み込んで、挟み込まれたバイト文字列をCBORエンコードされたデータ項目としてデコードすることで、実施できます。）

3.8.5. Control Operators .within and .and

A ".and" control on a type indicates that the data item matches both the left-hand-side type and the type given as the right-hand side. (Formally, the resulting type is the intersection of the two types given.)

「.and」コントロールは、タイプに対して左辺のタイプと右辺として指定されたタイプの両方と一致することを示します。（形式的には、結果のタイプは、指定された2つのタイプの共通部分です。）

   "type1 .and type2"

   "type1 .and type2"

   "type1 .および type2"

A variant of the ".and" control is the ".within" control, which expresses an additional intent: the left-hand-side type is meant to be a subset of the right-hand-side type.

   "type1 .within type2"

   "type1 .within type2"

   "type1 .type2内にある"

While both forms have the identical formal semantics (intersection), the intention of the ".within" form is that the right-hand side gives guidance to the types allowed on the left-hand side, which typically is a socket (Section 3.9):

両方の形式は形式的な意味（交差）が同じですが、".within" 形式の意図は、右側が左側に許可されるタイプに関するガイダンスを提供することです。左側は通常、ソケットであることが想定されています（セクション3.9）。

     message = $message .within message-structure
     message-structure = [message_type, *message_option]
     message_type = 0..255
     message_option = any

     message = $message .within message-structure
     message-structure = [message_type, *message_option]
     message_type = 0..255
     message_option = any

     message = $message .within message-structure
     message-structure = [message_type, *message_option]
     message_type = 0..255
     message_option = 任意

     $message /= [3, dough: text, topping: [* text]]
     $message /= [4, noodles: text, sauce: text, parmesan: bool]

     $message /= [3, dough: text, topping: [* text]]
     $message /= [4, noodles: text, sauce: text, parmesan: bool]

     $message /= [3、dough: text、topping: [* text]]
     $message /= [4、noodles: text、sauce: text、parmesan: bool]

For ".within", a tool might flag an error if type1 allows data items that are not allowed by type2. In contrast, for ".and", there is no expectation that type1 is already a subset of type2.

「.within」の場合、type1がtype2で許可されていないデータ項目を許可している場合、ツールはエラーを検出する可能性があります。一方、「.and」の場合、type1が既にtype2のサブセットであることを期待する必要はありません。

3.8.6. Control Operators .lt, .le, .gt, .ge, .eq, .ne, and .default

The controls .lt, .le, .gt, .ge, .eq, and .ne specify a constraint on the left-hand-side type to be a value less than, less than or equal to, greater than, greater than or equal to, equal to, or not equal to a value given as a right-hand-side type (containing just that single value). In the present specification, the first four controls (.lt, .le, .gt, and .ge) are defined only for numeric types, as these have a natural ordering relationship.

左辺の型が右辺の型（単一の値のみを含む）より小さい、小さいか等しい、大きい、大きいか等しい、等しい、等しくない値であるという制約を示すコントロール ".lt, .le, .gt, .ge, .eq, .ne" 。現在の仕様では、最初の4つのコントロール（.lt, .le, .gt, .ge）は数値型にのみ定義されており、これらは自然な順序関係を持っています。

                  speed = number .ge 0  ; unit: m/s

                  speed = number .ge 0  ; 単位： m/s

.ne and .eq are defined for both numeric values and values of other types. If one of the values is not of a numeric type, equality is determined as follows: text strings are equal (satisfy .eq / do not satisfy .ne) if they are bytewise identical; the same applies for byte strings. Arrays are equal if they have the same number of elements, all of which are equal pairwise in order between the arrays. Maps are equal if they have the same number of key/value pairs, and there is pairwise equality between the key/value pairs between the two maps. Tagged values are equal if they both have the same tag and the values are equal. Values of simple types match if they are the same values. Numeric types that occur within arrays, maps, or tagged values are equal if their numeric value is equal and they are both integers or both floating-point values. All other cases are not equal (e.g., comparing a text string with a byte string).

.neと.eqは、数値または他のタイプの値の両方に対して定義されています。値のいずれかが数値型ではない場合、等価性は次のように決定されます：テキスト文字列はバイト単位で同一である場合に等しい（.eqを満たす/ .neを満たさない）；バイト文字列についても同様です。配列は、要素の数が同じであり、配列間で順番にペアごとに等しい場合に等しいです。マップは、キーと値のペアの数が同じであり、2つのマップ間のキーと値のペアの間に等しさがある場合に等しいです。タグ付き値は、タグが同じで値が等しい場合に等しいです。単純なタイプの値は、同じ値であれば一致します。配列、マップ、またはタグ付き値内にある数値型は、数値の値が等しく、両方が整数または浮動小数点値である場合に等しいです。その他の場合は等しくありません（例：テキスト文字列とバイト文字列の比較）。

A variant of the ".ne" control is the ".default" control, which expresses an additional intent: the value specified by the right-hand-side type is intended as a default value for the left-hand-side type given, and the implied .ne control is there to prevent this value from being sent over the wire. This control is only meaningful when the control type is used in an optional context; otherwise, there would be no way to make use of the default value.

「.ne」制御のバリエーションは、".default" 制御であり、追加の意図を表します。右側のタイプで指定された値は、左側のタイプに対してデフォルト値として意図されており、暗黙の .ne 制御はこの値が送信されないようにするために存在しています。この制御は、制御タイプがオプションのコンテキストで使用される場合にのみ意味を持ちます。そうでない場合は、デフォルト値を利用する方法が存在しないためです。

            timer = {
              time: uint,
              ? displayed-step: (number .gt 0) .default 1
            }

            timer = {
              time: uint,
              ? displayed-step: (number .gt 0) .default 1
            }

3.9. Socket/Plug

For both type choices and group choices, a mechanism is defined that facilitates starting out with empty choices and assembling them later, potentially in separate files that are concatenated to build the full specification.

両方のタイプの選択肢とグループの選択肢において、空の選択肢から始めて、後でそれらを組み立てるメカニズムが定義されています。これにより、完全な仕様を構築するために連結される可能性のある別々のファイルで選択肢を組み立てることが容易になります。

Per convention, CDDL extension points are marked with a leading dollar sign (types) or two leading dollar signs (groups). Tools honor that convention by not raising an error if such a type or group is not defined at all; the symbol is then taken to be an empty type choice (group choice), i.e., no choice is available.

従来の慣行により、CDDL拡張ポイントは先行するドル記号（types）または二つの先行するドル記号（groups）で示されます。ツールは、そのような型またはグループがまったく定義されていない場合、エラーを発生させずにこの慣行を尊重します。その場合、記号は空の型の選択肢（グループの選択肢）とみなされ、つまり選択肢は利用できません。

         tcp-header = {seq: uint, ack: uint, * $$tcp-option}

         tcp-header = {seq: uint, ack: uint, * $$tcp-option}

         tcp-header = {seq: uint, ack: uint, * $$tcp-option}

         ; later, in a different file

         ; 後で、別のファイルで

         $$tcp-option //= (
         sack: [+(left: uint, right: uint)]
         )

         $$tcp-option //= (
         sack: [+(left: uint, right: uint)]
         )

         $$tcp-option //= (
         sack: [+(left: uint, right: uint)]
         )

         ; and, maybe in another file

         ; および、別のファイルにあるかもしれません

         $$tcp-option //= (
         sack-permitted: true
         )

         $$tcp-option //= (
         sack-permitted: true
         )

         $$tcp-option //= (
         sack-permitted: true
         )

Names that start with a single "$" are "type sockets", starting out as an empty type, and intended to be extended via "/=". Names that start with a double "$$" are "group sockets", starting out as an empty group choice, and intended to be extended via "//=". In either case, it is not an error if there is no definition for a socket at all; this then means there is no way to satisfy the rule (i.e., the choice is empty).

「$」で始まる名前は「タイプソケット」と呼ばれ、空のタイプとして始まり、「/ =」を介して拡張されることを意図しています。「$$」で始まる名前は「グループソケット」と呼ばれ、空のグループ選択として始まり、「// =」を介して拡張されることを意図しています。いずれの場合も、ソケットの定義が存在しない場合はエラーではありません。その場合、ルールを満たす方法がないことを意味します（つまり、選択肢は空です）。

As a convention, all definitions (plugs) for socket names must be augmentations, i.e., they must be using "/=" and "//=", respectively.

以下のように訳されます。慣例として、ソケット名のすべての定義（プラグ）は、「/ =」および「//=」を使用してオーグメンテーションする必要があります。

To pick up the example illustrated in Figure 7, the socket/plug mechanism could be used as shown in Figure 12:

図7に示されている例を取り上げると、ソケット/プラグ機構は図12に示すように使用することができます。

                  PersonalData = {
                    ? displayName: tstr,
                    NameComponents,
                    ? age: uint,
                    * $$personaldata-extensions
                  }

                  PersonalData = {
                    ? displayName: tstr,
                    名前の構成要素,
                    ? age: uint,
                    * $$personaldata-extensions
                  }

                  NameComponents = (
                    ? firstName: tstr,
                    ? familyName: tstr,
                  )

                  NameComponents = (
                    ? firstName: tstr,
                    ? familyName: tstr,
                  )

                  NameComponents = (
                    ? firstName: tstr,
                    ? familyName: tstr,
                  )

                  ; The above already works as is.
                  ; But then, we can add later:

                  ; 上記はそのまま機能します。
                  ; しかしその後に、次のように追加することができます:

                  $$personaldata-extensions //= (
                    favorite-salsa: tstr,
                  )

                  $$personaldata-extensions //= (
                    favorite-salsa: tstr,
                  )

                  $$personaldata-extensions //= (
                    favorite-salsa: tstr,
                  )

                  ; and again, somewhere else:

; そして再度、別の場所で：

                  $$personaldata-extensions //= (
                    shoesize: uint,
                  )

                  $$personaldata-extensions //= (
                    shoesize: uint,
                  )

                  $$personaldata-extensions //= (
                    shoesize: uint,
                  )

Figure 12: Personal Data Example: Using Socket/Plug Extensibility

3.10. Generics

Using angle brackets, the left-hand side of a rule can add formal parameters after the name being defined, as in:

アングルブラケットを使用して、ルールの左側に、定義される名前の後にフォーマルパラメータを追加することができます。例:

   messages = message<"reboot", "now"> / message<"sleep", 1..100>
   message<t, v> = {type: t, value: v}

   messages = message<"reboot", "now"> / message<"sleep", 1..100>
   message<t, v> = {type: t, value: v}

   messages = message<"reboot", "now"> / message<"sleep", 1..100>
   message<t, v> = {type: t, value: v}

When using a generic rule, the formal parameters are bound to the actual arguments supplied (also using angle brackets), within the scope of the generic rule (as if there were a rule of the form parameter = argument).

一般的な規則を使用する場合、仮パラメータは、実引数（角括弧も使用）に束縛されます。束縛は、一般的な規則のスコープ内で行われます（あたかも「parameter = argument」という形式の規則が存在するかのように）。

Generic rules can be used for establishing names for both types and groups.

一般的なルールは、タイプとグループの両方の名前を確立するために使用することができます。

(At this time, there are some limitations to the nesting of generics in the CDDL tool described in Appendix F.)

（現時点では、付録Fに記載されているCDDLツールのジェネリックスのネストにいくつかの制限があります。）

3.11. Operator Precedence

As with any language that has multiple syntactic features such as prefix and infix operators, CDDL has operators that bind more tightly than others. This is becoming more complicated than, say, in ABNF, as CDDL has both types and groups, with operators that are specific to these concepts. Type operators (such as "/" for type choice) operate on types, while group operators (such as "//" for group choice) operate on groups. Types can simply be used in groups, but groups need to be bracketed (as arrays or maps) to become types. So, type operators naturally bind closer than group operators.

複数の構文的特徴（接頭辞および中置演算子など）を持つ任意の言語と同様に、CDDLには他の演算子よりも強く束縛する演算子が存在します。これは、例えばABNFと比較して、CDDLには型とグループの両方があり、それぞれに固有の演算子が存在するため、より複雑になります。型演算子（例えば型の選択に使用される「/」）は型に作用し、グループ演算子（例えばグループの選択に使用される「//」）はグループに作用します。型は単純にグループで使用することができますが、グループは型として使用するために（配列やマップなどとして）括弧で囲む必要があります。そのため、型演算子は自然にグループ演算子よりも緊密に結び付きます。

For instance, in

例えば、以下のような場合、

   t = [group1]
   group1 = (a / b // c / d)
   a = 1 b = 2 c = 3 d = 4

   t = [group1]
   group1 = (a / b // c / d)
   a = 1 b = 2 c = 3 d = 4

   t = [group1]
   group1 = (a / b // c / d)
   a = 1 b = 2 c = 3 d = 4

group1 is a group choice between the type choice of a and b and the type choice of c and d. This becomes more relevant once member keys and/or occurrences are added in:

group1は、aとbのタイプ選択とcとdのタイプ選択の間のグループ選択です。これは、メンバーキーと/または出現回数が追加された場合により関連性が増します。

   t = {group2}
   group2 = (? ab: a / b // cd: c / d)
   a = 1 b = 2 c = 3 d = 4

    = {}
    = (? ab:  /  // cd:  / )
    =   =   =   =

is a group choice between the optional member "ab" of type a or b and the member "cd" of type c or d. Note that the optionality is attached to the first choice ("ab"), not to the second choice.

ビット・フィールドgroovChoiceには、タイプaまたはbのオプショナルメンバー「ab」と、タイプcまたはdのメンバー「cd」の間で選択することができます。オプションは2番目の選択肢ではなく、最初の選択肢「ab」に付けられていることに注意してください。

Similarly, in

同様に、

   t = [group3]
   group3 = (+ a / b / c)
   a = 1 b = 2 c = 3

   t = [group3]
   group3 = (+ a / b / c)
   a = 1 b = 2 c = 3

   t = [group3]
   group3 = (+ a / b / c)
   a = 1 b = 2 c = 3

group3 is a repetition of a type choice between a, b, and c; if just a is to be repeatable, a group choice is needed to focus the occurrence:

MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、およびOPTIONALというキーワードをそれぞれ「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、「要求されています（REQUIRED）」、「することになります（SHALL）」、「することはありません（SHALL NOT）」、「すべきです（SHOULD）」、「すべきではありません（SHOULD NOT）」、「推奨されます（RECOMMENDED）」、「推奨されません（NOT RECOMMENDED）」、「してもよいです（MAY）」、「選択できます（OPTIONAL）」と翻訳してください。以下の英文を日本語に翻訳します：グループ3は、a、b、cの間のタイプの選択の繰り返しであり、単にaを繰り返し可能にする場合、出現に焦点を合わせるためにグループの選択が必要です。

   t = [group4]
   group4 = (+ a // b / c)
   a = 1 b = 2 c = 3

   t = [group4]
   group4 = (+ a // b / c)
   a = 1 b = 2 c = 3

   t = [group4]
   group4 = (+ a // b / c)
   a = 1 b = 2 c = 3

group4 is a group choice between a repeatable a and a single b or c.

group4は、繰り返し可能なaと単一のbまたはcの間で選択するグループです。

A comment has been that the semantics of group3 could be counterintuitive. In general, as with many other languages with operator precedence rules, the specification writer is encouraged not to rely on them, but to insert parentheses liberally to guide readers that are not familiar with CDDL precedence rules:

group3 の意味論は直感に反する可能性があるというコメントがありました。一般的に、演算子の優先順位ルールを持つ他の多くの言語と同様に、仕様書の作成者はそれに依存せず、CDDLの優先順位ルールに慣れていない読者をガイドするために括弧を自由に挿入することが推奨されています。

   t = [group4a]
   group4a = ((+ a) // (b / c))
   a = 1 b = 2 c = 3

   t = [group4a]
   group4a = ((+ a) // (b / c))
   a = 1 b = 2 c = 3

   t = [group4a]
   group4a = ((+ a) // (b / c))
   a = 1 b = 2 c = 3

The operator precedences, in sequence of loose to tight binding, are defined in Appendix B and summarized in Table 1. (Arities given are 1 for unary prefix operators and 2 for binary infix operators.)

演算子の優先順位は、緩い結合から厳密な結合へと順番に定義されており、付録Bで詳細に説明されています。また、この優先順位は表1にまとめられています。（与えられたアリティは、単項接頭辞演算子に対しては1であり、二項中置演算子に対しては2です。）

Operator	Arity	Operates on	Precedence
=	2	name = type, name = group	1
/=	2	name /= type	1
//=	2	name //= group	1
//	2	group // group	2
,	2	group, group	3
*	1	* group	4
n*m	1	n*m group	4
+	1	+ group	4
?	1	? group	4
=>	2	type => type	5
:	2	name: type	5
/	2	type / type	6
..	2	type..type	7
...	2	type...type	7
.ctrl	2	type .ctrl type	7
&	1	&group	8
~	1	~type	8

演算子	n個の引数をもつ	作用するもの	優先順位
=	2	name = type, name = group	1
/=	2	name /= type	1
//=	2	name //= group	1
//	2	group // group	2
,	2	group, group	3
*	1	* group	4
n*m	1	n*m group	4
+	1	+ group	4
?	1	? group	4
=>	2	type => type	5
:	2	name: type	5
/	2	type / type	6
..	2	type..type	7
...	2	type...type	7
.ctrl	2	type .ctrl type	7
&	1	&group	8
~	1	~type	8

              Table 1: Summary of Operator Precedences

              Table 1: 演算子の優先順位の要約

4. Making Use of CDDL

In this section, we discuss several potential ways to employ CDDL.

このセクションでは、CDDLを利用するためのいくつかの潜在的な方法について説明します。

4.1. As a Guide for a Human User

CDDL can be used to efficiently define the layout of CBOR data, such that a human implementer can easily see how data is supposed to be encoded.

CDDLはCBORデータのレイアウトを効率的に定義するために使用することができます。これにより、人間の実装者はデータがどのようにエンコードされるべきかを簡単に理解することができます。

Since CDDL maps parts of the CBOR data to human-readable names, tools could be built that use CDDL to provide a human-friendly representation of the CBOR data and allow them to edit such data while remaining compliant with its CDDL definition.

CDDLはCBORデータの一部を人間が読みやすい名前にマッピングするため、CDDLを使用してCBORデータの人間にやさしい表現を提供し、CDDLの定義に準拠しながらそのようなデータを編集するためのツールが作成される可能性があります。

4.2. For Automated Checking of CBOR Data Structures

CDDL has been specified such that a machine can handle the CDDL definition and related CBOR data (and, thus, also JSON data). For example, a machine could use CDDL to check whether or not CBOR data is compliant with its definition.

CDDLは、機械がCDDLの定義と関連するCBORデータ（そしてJSONデータも同様）を処理できるように指定されています。例えば、機械はCDDLを使用して、CBORデータがその定義と一致しているかどうかをチェックすることができます。

The need for thoroughness of such compliance checking depends on the application. For example, an application may decide not to check the data structure at all and use the CDDL definition solely as a means to indicate the structure of the data to the programmer.

そのようなコンプライアンスチェックの徹底性の必要性は、アプリケーションによって異なります。例えば、アプリケーションはデータ構造を全くチェックせず、CDDLの定義を単にデータの構造をプログラマーに示す手段として使用することを選択する場合もあります。

On the other hand, the application may also implement a checking mechanism that goes as far as checking that all mandatory map members are available.

逆に、アプリケーションは、すべての必須のマップメンバーが利用可能であるかどうかまでチェックするチェックメカニズムを実装することもあります。

The matter of how far the data description must be enforced by an application is left to the designers and implementers of that application, keeping in mind related security considerations.

データの説明がアプリケーションによってどの程度強制されるかは、そのアプリケーションの設計者や実装者に委ねられており、関連するセキュリティ上の考慮事項を念頭に置いています。

In no case is it intended that a CDDL tool would be "writing code" for an implementation.

どの場合でも、CDDLツールが実装のために「コードを作成」することを意図しているわけではありません。

4.3. For Data Analysis Tools

In the long run, it can be expected that more and more data will be stored using the CBOR data format.

将来的には、CBORデータ形式を使用してより多くのデータが保存されることが予想されます。

Where there is data, there is data analysis and the need to process such data automatically. CDDL can be used for such automated data processing, allowing tools to verify data, clean it, and extract particular parts of interest from it.

データがある場所には、データ分析があり、そのようなデータを自動的に処理する必要があります。CDDLは、このような自動化されたデータ処理に使用することができ、ツールがデータを検証し、クリーンにし、興味のある特定の部分を抽出することができます。

Since CBOR is designed with constrained devices in mind, a likely use of it would be small sensors. An interesting use would thus be automated analysis of sensor data.

CBORは制約のあるデバイスを想定して設計されているため、それの可能な利用は小さなセンサーです。興味深い利用例として、センサーデータの自動分析が挙げられます。

5. Security Considerations

This document presents a content rules language for expressing CBOR data structures. As such, it does not bring any security issues on itself, although specifications of protocols that use CBOR naturally need security analyses when defined. General guidelines for writing security considerations are defined in [RFC3552] (BCP 72). Specifications using CDDL to define CBOR structures in protocols need to follow those guidelines. Additional topics that could be considered in a security considerations section for a specification that uses CDDL to define CBOR structures include the following:

このドキュメントは、CBORデータ構造を表現するためのコンテンツルール言語を提案しています。そのため、CBORを使用するプロトコルの仕様には、その定義時にセキュリティ分析が必要ですが、そのセキュリティ上の問題はこのドキュメント自体にはありません。セキュリティ考慮事項の書き方に関する一般的なガイドラインは、[RFC3552]（BCP 72）で定義されています。CDDLを使用してプロトコルでCBOR構造を定義する仕様は、これらのガイドラインに従う必要があります。CDDLを使用してCBOR構造を定義する仕様のセキュリティ考慮事項セクションで考慮すべき追加のトピックは、以下の通りです。

Where could the language maybe cause confusion in a way that will enable security issues?

言語がセキュリティ上の問題を引き起こす可能性がある箇所は、どのようなところですか？

Where a CDDL matcher is part of the implementation of a system, the security of the system ought not depend on the correctness of the CDDL specification or CDDL implementation without any further defenses in place.

システムの実装の一部としてCDDLマッチャーが含まれている場合、システムのセキュリティは、CDDL仕様やCDDL実装の正確性に依存せず、さらなる防御策を採る必要があります。

Where the CDDL specification includes extension points, the impact of extensions on the security of the system needs to be carefully considered.

CDDL仕様に拡張ポイントが含まれている場合、システムのセキュリティへの拡張の影響を慎重に考慮する必要があります。

Writers of CDDL specifications are strongly encouraged to value clarity and transparency of the specification over its elegance. Keep it as simple as possible while still expressing the needed data model.

CDDL仕様の執筆者は、仕様の優雅さよりも明確さと透明性を重視するよう強く推奨されます。必要なデータモデルを表現しつつ、できるだけシンプルに保つことです。

A related observation about formal description techniques in general that is strongly recommended to be kept in mind by writers of CDDL specifications: just because CDDL makes it easier to handle complexity in a specification, that does not make that complexity somehow less bad (except maybe on the level of the humans having to grasp the complex structure while reading the spec).

6. IANA Considerations

6.1. CDDL Control Operators Registry

IANA has created a registry for control operators (Section 3.8). The "CDDL Control Operators" registry has been created within the "Concise Data Definition Language (CDDL)" registry.

IANAは、制御オペレータ（セクション3.8）のためのレジストリを作成しました。 "CDDL制御オペレータ"のレジストリは、"簡潔なデータ定義言語（CDDL）"のレジストリ内に作成されました。

Each entry in the subregistry must include the name of the control operator (by convention given with the leading dot) and a reference to its documentation. Names must be composed of the leading dot followed by a text string conforming to the production "id" in Appendix B.

サブレジストリ内の各エントリは、制御演算子の名前（先頭のドットで指定される通例）とそのドキュメントへの参照を含める必要があります。名前は、付録Bの「id」で定義されるテキスト文字列に従った先頭のドットで構成されている必要があります。

Initial entries in this registry are as follows:

このレジストリの最初のエントリは以下の通りです：

Name	Documentation
.size	RFC 8610
.bits	RFC 8610
.regexp	RFC 8610
.cbor	RFC 8610
.cborseq	RFC 8610
.within	RFC 8610
.and	RFC 8610
.lt	RFC 8610
.le	RFC 8610
.gt	RFC 8610
.ge	RFC 8610
.eq	RFC 8610
.ne	RFC 8610
.default	RFC 8610

名前	ドキュメント
.size	RFC 8610
.bits	RFC 8610
.regexp	RFC 8610
.cbor	RFC 8610
.cborseq	RFC 8610
.within	RFC 8610
.and	RFC 8610
.lt	RFC 8610
.le	RFC 8610
.gt	RFC 8610
.ge	RFC 8610
.eq	RFC 8610
.ne	RFC 8610
.default	RFC 8610

All other control operator names are Unassigned.

他のすべての制御演算子名は未割り当てです。

The IANA policy for additions to this registry is "Specification Required" as defined in [RFC8126] (which involves an Expert Review) for names that do not include an internal dot and "IETF Review" for names that do include an internal dot. The expert reviewer is specifically instructed that other Standards Development Organizations (SDOs) may want to define control operators that are specific to their fields (e.g., based on a binary syntax already in use at the SDO); the review process should strive to facilitate such an undertaking.

このレジストリへの追加のためのIANA方針は、内部ドットを含まない名前に対しては「Specification Required」と定義された[RFC8126]（専門家によるレビューを含む）とし、「内部ドットを含む名前に対しては「IETF Review」とします。レビューアに対しては、他の標準化団体（SDO）が特定の領域に固有の制御演算子を定義する可能性があること（たとえば、SDOで既に使用されているバイナリ構文に基づいて）を明示的に指示します。レビュー手続きは、そのような取り組みを促進するよう努めるべきです。

References

Normative References

[ISO6093]: "Information processing -- Representation of numerical values in character strings for information interchange", 1985,
[RFC2119]: "Key words for use in RFCs to Indicate Requirement Levels", BCP None, RFC None, DOI None, March 1997, <https://www.rfc-editor.org/info/rfc2119>
[RFC3552]: "Guidelines for Writing RFC Text on Security Considerations", BCP None, RFC None, DOI None, July 2003, <https://www.rfc-editor.org/info/rfc3552>
[RFC3629]: "UTF-8, a transformation format of ISO 10646", STD None, RFC None, DOI None, November 2003, <https://www.rfc-editor.org/info/rfc3629>
[RFC4648]: "The Base16, Base32, and Base64 Data Encodings", RFC None, DOI None, October 2006, <https://www.rfc-editor.org/info/rfc4648>
[RFC5234]: "Augmented BNF for Syntax Specifications: ABNF", STD None, RFC None, DOI None, January 2008, <https://www.rfc-editor.org/info/rfc5234>
[RFC7049]: "Concise Binary Object Representation (CBOR)", RFC None, DOI None, October 2013, <https://www.rfc-editor.org/info/rfc7049>
[RFC7493]: "The I-JSON Message Format", RFC None, DOI None, March 2015, <https://www.rfc-editor.org/info/rfc7493>
[RFC8126]: "Guidelines for Writing an IANA Considerations Section in RFCs", BCP None, RFC None, DOI None, June 2017, <https://www.rfc-editor.org/info/rfc8126>
[RFC8174]: "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP None, RFC None, DOI None, May 2017, <https://www.rfc-editor.org/info/rfc8174>
[RFC8259]: "The JavaScript Object Notation (JSON) Data Interchange Format", STD None, RFC None, DOI None, December 2017, <https://www.rfc-editor.org/info/rfc8259>
[W3C.REC-xmlschema-2-20041028]: "XML Schema Part 2: Datatypes Second Edition", October 2004, <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>

Informative References

[CDDL-Freezer]: "A feature freezer for the Concise Data Definition Language (CDDL)", August 2018,
[GRASP]: "A Generic Autonomic Signaling Protocol (GRASP)", July 2017,
[IEEE754]: "IEEE Standard for Floating-Point Arithmetic", IEEE None,
[JCR]: "A Language for Rules Describing JSON Content", September 2017,
[PEG]: "Parsing expression grammars: a recognition- based syntactic foundation", DOI None, January 2004,
[RELAXNG]: "Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar- based validation -- RELAX NG", ISO/IEC None, December 2008,
[RFC7071]: "A Media Type for Reputation Interchange", RFC None, DOI None, November 2013, <https://www.rfc-editor.org/info/rfc7071>
[RFC7950]: "The YANG 1.1 Data Modeling Language", RFC None, DOI None, August 2016, <https://www.rfc-editor.org/info/rfc7950>
[RFC8007]: "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers", RFC None, DOI None, December 2016, <https://www.rfc-editor.org/info/rfc8007>
[RFC8152]: "CBOR Object Signing and Encryption (COSE)", RFC None, DOI None, July 2017, <https://www.rfc-editor.org/info/rfc8152>
[RFC8428]: "Sensor Measurement Lists (SenML)", RFC None, DOI None, August 2018, <https://www.rfc-editor.org/info/rfc8428>
[YAML]: "YAML Ain't Markup Language (YAML[TM]) Version 1.2", October 2009, <https://yaml.org/spec/1.2/spec.html>

References

Normative References

[ISO6093]: "Information processing -- Representation of numerical values in character strings for information interchange", 1985,
[RFC2119]: "Key words for use in RFCs to Indicate Requirement Levels", BCP None, RFC None, DOI None, March 1997, <https://www.rfc-editor.org/info/rfc2119>
[RFC3552]: "Guidelines for Writing RFC Text on Security Considerations", BCP None, RFC None, DOI None, July 2003, <https://www.rfc-editor.org/info/rfc3552>
[RFC3629]: "UTF-8, a transformation format of ISO 10646", STD None, RFC None, DOI None, November 2003, <https://www.rfc-editor.org/info/rfc3629>
[RFC4648]: "The Base16, Base32, and Base64 Data Encodings", RFC None, DOI None, October 2006, <https://www.rfc-editor.org/info/rfc4648>
[RFC5234]: "Augmented BNF for Syntax Specifications: ABNF", STD None, RFC None, DOI None, January 2008, <https://www.rfc-editor.org/info/rfc5234>
[RFC7049]: "Concise Binary Object Representation (CBOR)", RFC None, DOI None, October 2013, <https://www.rfc-editor.org/info/rfc7049>
[RFC7493]: "The I-JSON Message Format", RFC None, DOI None, March 2015, <https://www.rfc-editor.org/info/rfc7493>
[RFC8126]: "Guidelines for Writing an IANA Considerations Section in RFCs", BCP None, RFC None, DOI None, June 2017, <https://www.rfc-editor.org/info/rfc8126>
[RFC8174]: "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP None, RFC None, DOI None, May 2017, <https://www.rfc-editor.org/info/rfc8174>
[RFC8259]: "The JavaScript Object Notation (JSON) Data Interchange Format", STD None, RFC None, DOI None, December 2017, <https://www.rfc-editor.org/info/rfc8259>
[W3C.REC-xmlschema-2-20041028]: "XML Schema Part 2: Datatypes Second Edition", October 2004, <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>

Informative References

[CDDL-Freezer]: "A feature freezer for the Concise Data Definition Language (CDDL)", August 2018,
[GRASP]: "A Generic Autonomic Signaling Protocol (GRASP)", July 2017,
[IEEE754]: "IEEE Standard for Floating-Point Arithmetic", IEEE None,
[JCR]: "A Language for Rules Describing JSON Content", September 2017,
[PEG]: "Parsing expression grammars: a recognition- based syntactic foundation", DOI None, January 2004,
[RELAXNG]: "Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar- based validation -- RELAX NG", ISO/IEC None, December 2008,
[RFC7071]: "A Media Type for Reputation Interchange", RFC None, DOI None, November 2013, <https://www.rfc-editor.org/info/rfc7071>
[RFC7950]: "The YANG 1.1 Data Modeling Language", RFC None, DOI None, August 2016, <https://www.rfc-editor.org/info/rfc7950>
[RFC8007]: "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers", RFC None, DOI None, December 2016, <https://www.rfc-editor.org/info/rfc8007>
[RFC8152]: "CBOR Object Signing and Encryption (COSE)", RFC None, DOI None, July 2017, <https://www.rfc-editor.org/info/rfc8152>
[RFC8428]: "Sensor Measurement Lists (SenML)", RFC None, DOI None, August 2018, <https://www.rfc-editor.org/info/rfc8428>
[YAML]: "YAML Ain't Markup Language (YAML[TM]) Version 1.2", October 2009, <https://yaml.org/spec/1.2/spec.html>

Appendix A. Parsing Expression Grammars (PEGs)

This appendix is normative.

この付録は規範的です。

Since the 1950s, many grammar notations are based on Backus-Naur Form (BNF), a notation for context-free grammars (CFGs) within Chomsky's generative system of grammars. The Augmented Backus-Naur Form (ABNF) [RFC5234], widely used in IETF specifications and also inspiring the syntax of CDDL, is an example of this.

Generative grammars can express ambiguity well, but this very property may make them hard to use in recognition systems, spawning a number of subdialects that pose constraints on generative grammars to be used with parser generators; this scenario may be hard for the specification writer to manage.

生成文法は曖昧さをうまく表現することができますが、この特性が認識システムでの使用を困難にすることがあります。その結果、生成文法の制約をパーサージェネレータとの使用に課すいくつかの副方言が生まれることがあります。このシナリオは、仕様の作成者にとって管理が困難な場合があります。

PEGs [PEG] provide an alternative formal foundation for describing grammars that emphasizes recognition over generation and resolves what would have been ambiguity in generative systems by introducing the concept of "prioritized choice".

PEG（[PEG]）は、生成よりも認識を重視し、「優先度付き選択」という概念を導入することで、生成システムでは曖昧になっていたものを解決するための文法の形式的な基盤を提供します。

The notation for PEGs is quite close to BNF, with the usual "Extended BNF" features, such as repetition, added. However, where BNF uses the unordered (symmetrical) choice operator "|" (incidentally notated as "/" in ABNF), PEG provides a prioritized choice operator "/". The two alternatives listed are to be tested in left-to-right order, locking in the first successful match and disregarding any further potential matches within the choice (but not disabling alternatives in choices containing this choice, as a cut (Section 3.5.4) would).

PEGの表記法はBNFに非常に近く、通常の「Extended BNF」の特徴である繰り返しのような要素が追加されています。ただし、BNFが無順序（対称）の選択演算子「|」（偶然にもABNFでは「/」と表記）を使用するのに対して、PEGは優先度の付いた選択演算子「/」を提供します。リストアップされた2つの代替案は、左から右の順にテストされ、最初に成功したマッチが確定し、選択肢内の他の潜在的なマッチは無視されます（ただし、この選択肢を含む選択肢内の代替案は無効にされません）。

For example, the ABNF expressions

たとえば、ABNF式

   A = "a" "b" / "a"    (1)

   A = "a" "b" / "a"    (1)

   A = "a" "b" / "a"    (1)

and

そして

   A = "a" / "a" "b"    (2)

   A = "a" / "a" "b"    (2)

   A = "a" / "a" "b"    (2)

are equivalent in ABNF's original generative framework but are very different in PEG: in (2), the second alternative will never match, as any input string starting with an "a" will already succeed in the first alternative, locking in the match.

ABNFの元の生成フレームワークでは等価ですが、PEGでは非常に異なります。（2）では、2番目の選択肢は一致しないことがありません。なぜなら、「a」で始まる任意の入力文字列はすでに最初の選択肢で成功するため、マッチが確定しているからです。

Similarly, the occurrence indicators ("?", "*", "+") are "greedy" in PEG, i.e., they consume as much input as they match (and, as a consequence, "a* a" in PEG notation or "*a a" in CDDL syntax never can match anything, as all input matching "a" is already consumed by the initial "a*", leaving nothing to match the second "a").

同様に、出現インジケーター（「?」、「*」、「+」）はPEGでは「貪欲」であり、一致するだけの入力を消費します（その結果、「a* a」（PEG形式）または「*a a」（CDDL構文）は何も一致しない可能性がありません。なぜなら、最初の「a*」によってすべての「a」を一致させるために必要な入力が既に消費されているため、二番目の「a」に何も一致するものが残っていないからです）。

Incidentally, the grammar of CDDL itself, as written in ABNF in Appendix B, can be interpreted both (1) in the generative framework on which RFC 5234 is based and (2) as a PEG. This was made possible by ordering the choices in the grammar such that a successful match made on the left-hand side of a "/" operator is always the intended match, instead of relying on the power of symmetrical choices (for example, note the sequence of alternatives in the rule for "uint", where the lone zero is behind the longer match alternatives that start with a zero).

ついでに、付録Bに記載されているABNFで書かれたCDDL自体の文法は、（1）RFC 5234がもとになっている生成フレームワークで、または（2）PEGとして解釈することができます。これは、文法の選択肢を順序立てて並べることにより、左側の"/"演算子によって成功したマッチは常に意図したマッチであるため、対称的な選択肢のパワーに頼るのではなく実現されました（たとえば、"uint"のルールの選択肢の順序に注目してください。ゼロで始まるよりも長いマッチの選択肢の後ろにゼロだけがあります）。

The syntax used for expressing the PEG component of CDDL is based on ABNF, interpreted in the obvious way with PEG semantics. The ABNF convention of notating occurrence indicators before the controlled primary, and of allowing numeric values for minimum and maximum occurrence around a "*" sign, is copied. While PEG is only about characters, CDDL has a richer set of elements, such as types and groups. Specifically, the following constructs map:

CDDLのPEGコンポーネントを表現するために使用される構文は、PEGのセマンティクスをもって明らかな方法で解釈されるABNFに基づいています。制御された主要な要素の前に発生指示子を示すABNFの規約、および"*"の記号を周囲の最小および最大発生回数に数値値を許可する規約がコピーされています。PEGは文字に関するものであり、CDDLは型やグループといったより豊富な要素のセットを持っています。具体的には、以下の構成要素がマッピングされます。

CDDL	PEG	Remark
"="	"<-"	/= and //= are abbreviations
"//"	"/"	prioritized choice
"/"	"/"	prioritized choice, limited to types only
"?" P	P "?"	zero or one
"*" P	P "*"	zero or more
"+" P	P "+"	one or more
A B	A B	sequence
A, B	A B	sequence, comma is decoration only

CDDL	PEG	備考
"="することになります	"<-"	"/="および"/=/"は省略形です
"//"	"/"	優先順位付きの選択
"/"	"/"	優先順位付きの選択、型のみに制限される
"?" P	P "?"	0個または1個
"*" P	P "*"	0個以上
"+" P	P "+"	1個以上
A B	A B	順序
A, B	A B	順序、カンマは装飾のみ

The literal notation and the use of square brackets, curly braces, tildes, ampersands, and hash marks are specific to CDDL and unrelated to the conventional PEG notation. The DOT (".") from PEG is replaced by the unadorned "#" or its alias "any". Also, CDDL does not provide the syntactic predicate operators NOT ("!") or AND ("&") from PEG, reducing expressiveness as well as complexity.

For more details about PEG's theoretical foundation and interesting properties of the operators such as associativity and distributivity, the reader is referred to [PEG].

PEGの理論的な基礎や、結びつき方や配布性などの演算子の興味深い特性についての詳細については、[PEG]を参照してください。

Appendix B. ABNF Grammar

This appendix is normative.

この付録は規範的です。

The following is a formal definition of the CDDL syntax in ABNF [RFC5234]. Note that, as is defined in ABNF, the quote-delimited strings below are case insensitive (while string values and names are case sensitive in CDDL).

以下は、CDDL構文のABNFによる形式的な定義です。ABNFに定義されている通り、以下の引用符で囲まれた文字列は大文字小文字を区別しません（CDDLでは文字列の値と名前は大文字小文字を区別します）。「[RFC5234]」。

  cddl = S 1*(rule S)
  rule = typename [genericparm] S assignt S type
       / groupname [genericparm] S assigng S grpent

  cddl = S 1*(rule S)
  rule = typename [genericparm] S assignt S type
       / groupname [genericparm] S assigng S grpent

  cddl = S 1*(rule S)
  rule = typename [genericparm] S assignt S type
       / groupname [genericparm] S assigng S grpent

  typename = id
  groupname = id

  typename = id
  groupname = id

  typename = id
  groupname = id

  assignt = "=" / "/="
  assigng = "=" / "//="

  assignt = "=" / "/="
  assigng = "=" / "//="

  assignt = "=" / "/="
  assigng = "=" / "//="

  genericparm = "<" S id S *("," S id S ) ">"
  genericarg = "<" S type1 S *("," S type1 S ) ">"

【記事】

  genericparm = "<" S id S *("," S id S ) ">"
  genericarg = "<" S type1 S *("," S type1 S ) ">"

  genericparm = "<" S id S *("," S id S ) ">"
  genericarg = "<" S type1 S *("," S type1 S ) ">"

  type = type1 *(S "/" S type1)

  type = type1 *(S "/" S type1)

  type = type1 *(S "/" S type1)

  type1 = type2 [S (rangeop / ctlop) S type2]
  ; space may be needed before the operator if type2 ends in a name

  type1 = type2 [S (rangeop / ctlop) S type2]
  ; もし type2 が名前で終わるならば、演算子の前にスペースを入れる必要がある場合もあります

  type2 = value
        / typename [genericarg]
        / "(" S type S ")"
        / "{" S group S "}"
        / "[" S group S "]"
        / "~" S typename [genericarg]
        / "&" S "(" S group S ")"
        / "&" S groupname [genericarg]
        / "#" "6" ["." uint] "(" S type S ")"
        / "#" DIGIT ["." uint]                ; major/ai
        / "#"                                 ; any

  type2 = value
        / typename [genericarg]
        / "(" S type S ")"
        / "{" S group S "}"
        / "[" S group S "]"
        / "~" S typename [genericarg]
        / "&" S "(" S group S ")"
        / "&" S groupname [genericarg]
        / "#" "6" ["." uint] "(" S type S ")"
        / "#" DIGIT ["." uint]                ; major/ai
        / "#"                                 ; any

type2 = value
/ typename [genericarg]
/ "（" S type S "）"
/ "｛" S group S "｝"
/ "［" S group S "］"
/ "〜" S typename [genericarg]
/ "&" S "（" S group S "）"
/ "&" S groupname [genericarg]
/ "#" "6" ["." uint] "（" S type S "）"
/ "#" DIGIT ["." uint]                ; major/ai
/ "#"                                 ; any

  rangeop = "..." / ".."

  rangeop = "..." / ".."

  rangeop = "..." / ".."

  ctlop = "." id

  ctlop = "." id

  ctlop = "." id

  group = grpchoice *(S "//" S grpchoice)

  グループ = grpchoice *(S "//" S grpchoice)

  grpchoice = *(grpent optcom)
  grpent = [occur S] [memberkey S] type
         / [occur S] groupname [genericarg]  ; preempted by above
         / [occur S] "(" S group S ")"

  grpchoice = *(grpent optcom)
  grpent = [occur S] [memberkey S] type
         / [occur S] groupname [genericarg]  ; preempted by above
         / [occur S] "(" S group S ")"

  grpchoice = *(grpent optcom)
  grpent = [occur S] [memberkey S] type
         / [occur S] groupname [genericarg]  ; 上記により優先
         / [occur S] "(" S group S ")"

  memberkey = type1 S ["^" S] "=>"
            / bareword S ":"
            / value S ":"

  memberkey = type1 S ["^" S] "=>"
            / bareword S ":"
            / value S ":"

  memberkey = type1 S ["^" S] "=>"
            / bareword S ":"
            / value S ":"

  bareword = id

  bareword = id

  裸の単語 = 識別子

  optcom = S ["," S]

  optcom = S ["," S]

  optcom = S ["," S]

  occur = [uint] "*" [uint]
        / "+"
        / "?"

  occur = [uint] "*" [uint]
        / "+"
        / "?"

  occur = [uint] "*" [uint]
        / "+"
        / "?"

  uint = DIGIT1 *DIGIT
       / "0x" 1*HEXDIG
       / "0b" 1*BINDIG
       / "0"

  uint = DIGIT1 *DIGIT
       / "0x" 1*HEXDIG
       / "0b" 1*BINDIG
       / "0"

  uint = DIGIT1 *DIGIT
       / "0x" 1*HEXDIG
       / "0b" 1*BINDIG
       / "0"

  value = number
        / text
        / bytes

  value = 数値
        / テキスト
        / バイト

  int = ["-"] uint

  int = ["-"] uint

  int = ["-"] uint

  ; This is a float if it has fraction or exponent; int otherwise
  number = hexfloat / (int ["." fraction] ["e" exponent ])
  hexfloat = ["-"] "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent
  fraction = 1*DIGIT
  exponent = ["+"/"-"] 1*DIGIT

  ; 小数部や指数部を持つ場合は浮動小数点数です；それ以外の場合は整数です
  number = hexfloat / (int [ "." fraction ] [ "e" exponent ])
  hexfloat = ["-"] "0x" 1*HEXDIG [ "." 1*HEXDIG ] "p" exponent
  fraction = 1*DIGIT
  exponent = [ "+" / "-" ] 1*DIGIT

  text = %x22 *SCHAR %x22
  SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
  SESC = "\" (%x20-7E / %x80-10FFFD)

  text = %x22 *SCHAR %x22
  SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
  SESC = "\" (%x20-7E / %x80-10FFFD)

  text = %x22 *SCHAR %x22
  SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
  SESC = "\" (%x20-7E / %x80-10FFFD)

  bytes = [bsqual] %x27 *BCHAR %x27
  BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
  bsqual = "h" / "b64"
  id = EALPHA *(*("-" / ".") (EALPHA / DIGIT))
  ALPHA = %x41-5A / %x61-7A
  EALPHA = ALPHA / "@" / "_" / "$"
  DIGIT = %x30-39
  DIGIT1 = %x31-39
  HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
  BINDIG = %x30-31

  bytes = [bsqual] %x27 *BCHAR %x27
  BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
  bsqual = "h" / "b64"
  id = EALPHA *(*("-" / ".") (EALPHA / DIGIT))
  ALPHA = %x41-5A / %x61-7A
  EALPHA = ALPHA / "@" / "_" / "$"
  DIGIT = %x30-39
  DIGIT1 = %x31-39
  HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
  BINDIG = %x30-31

  bytes = [bsqual] %x27 *BCHAR %x27
  BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
  bsqual = "h" / "b64"
  id = EALPHA *(*("-" / ".") (EALPHA / DIGIT))
  ALPHA = %x41-5A / %x61-7A
  EALPHA = ALPHA / "@" / "_" / "$"
  DIGIT = %x30-39
  DIGIT1 = %x31-39
  HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
  BINDIG = %x30-31

  S = *WS
  WS = SP / NL
  SP = %x20
  NL = COMMENT / CRLF
  COMMENT = ";" *PCHAR CRLF
  PCHAR = %x20-7E / %x80-10FFFD
  CRLF = %x0A / %x0D.0A

  S = *WS
  WS = SP / NL
  SP = %x20
  NL = COMMENT / CRLF
  COMMENT = ";" *PCHAR CRLF
  PCHAR = %x20-7E / %x80-10FFFD
  CRLF = %x0A / %x0D.0A

  S = *WS
  WS = SP / NL
  SP = %x20
  NL = COMMENT / CRLF
  COMMENT = ";" *PCHAR CRLF
  PCHAR = %x20-7E / %x80-10FFFD
  CRLF = %x0A / %x0D.0A

Figure 13: CDDL ABNF

Note that this ABNF does not attempt to reflect the detailed rules of what can be in a prefixed byte string.

注意：このABNFは、接頭辞付きバイト文字列に含まれる詳細なルールを反映しようとはしていません。

Appendix C. Matching Rules

This appendix is normative.

この付録は規範的です。

In this appendix, we go through the ABNF syntax rules defined in Appendix B and briefly describe the matching semantics of each syntactic feature. In this context, an instance (data item) "matches" a CDDL specification if it is allowed by the CDDL specification; this is then broken down into parts of specifications (type and group expressions) and parts of instances (data items).

この付録では、付録Bで定義されたABNF構文規則を確認し、各構文的機能の一致する意味論を簡単に説明します。この文脈では、CDDL仕様によって許可される場合、インスタンス（データアイテム）はCDDL仕様に「一致」します。これは、仕様の一部（型およびグループ式）とインスタンスの一部（データアイテム）に分割されます。

cddl = S 1*(rule S)

はS1*(rule S)である必要があります（MUST）

A CDDL specification is a sequence of one or more rules. Each rule gives a name to a right-hand-side expression, either a CDDL type or a CDDL group. Rule names can be used in the rule itself and/or other rules (and tools can output warnings if that is not the case). The order of the rules is significant only in two cases: CDDL仕様は1つ以上のルールのシーケンスです。各ルールは、CDDLの型またはCDDLグループのどちらかを右辺式に名前を付けます。ルール名は、そのルール自体および/または他のルールで使用できます（ツールは、そうでない場合に警告を出力できます）。ルールの順序は、2つの場合にのみ重要です：

1. The first rule defines the semantics of the entire specification; hence, there is no need to give that root rule a special name or special syntax in the language (as, for example, with "start" in RELAX NG); its name can therefore be chosen to be descriptive. (As with all other rule names, the name of the initial rule may be used in itself or in other rules.)

最初のルールは仕様の意味を定義します。したがって、そのルートルールに特別な名前や特別な構文を与える必要はありません（例えば、RELAX NGの「start」のように）。その名前は、説明的なものに選択することができます。（初期ルールの名前は他のルール内またはそれ自体で使用することも可能ですが、他のルール名と同様です。）

2. Where a rule contributes to a type or group choice (using "/=" or "//="), that choice is populated in the order the rules are given; see below.

2. ルールが型またはグループの選択肢に貢献する場合（「/ =」または「// =」を使用する場合）、その選択肢はルールが与えられた順序で選択されます。以下を参照してください。

rule = typename [genericparm] S assignt S type / groupname [genericparm] S assigng S grpent

ルール = タイプ名[ジェネリックパラメータ] S assignt S タイプ/ グループ名[ジェネリックパラメータ] S assigng S grpent

typename = id groupname = id

typename = 識別子 groupname = 識別子

A rule defines a name for a type expression (production "type") or for a group expression (production "grpent"), with the intention that the semantics does not change when the name is replaced by its (parenthesized if needed) definition. Note that whether the name defined by a rule stands for a type or a group isn't always determined by syntax alone: e.g., "a = b" can make "a" a type if "b" is a type, or a group if "b" is a group. More subtly, in "a = (b)", "a" may be used as a type if "b" is a type, or as a group both when "b" is a group and when "b" is a type (a good convention to make the latter case stand out to the human reader is to write "a = (b,)"). (Note that the same dual meaning of parentheses applies within an expression but often can be resolved by the context of the parenthesized expression. On the more general point, it may not be clear immediately either whether "b" stands for a group or a type -- this semantic processing may need to span several levels of rule definitions before a determination can be made.)

ルールは、タイプ式（「type」プロダクション）またはグループ式（「grpent」プロダクション）に対して名前を定義します。この名前が、（必要に応じて括弧で囲まれた）定義に置き換えられた際に、意味が変わらないように意図されています。なお、ルールによって定義される名前がタイプを表すのか、グループを表すのかは、常に構文だけで判断されるわけではありません。たとえば、「a = b」は、「b」がタイプであれば「a」をタイプにすることができますし、もし「b」がグループであれば「a」をグループにすることもできます。さらに、"a = (b)"の場合では、もし「b」がタイプであれば「a」はタイプとして使用されるかもしれませんし、もし「b」がグループであっても、また「b」がタイプであっても「a」はグループとして使用されるかもしれません（後者の場合を人間の読者に明確にするための良い規約としては、"a = (b,)"と書くことです）。なお（式内でのかっこの二重の意味についても同様ですが、しばしばかっこの文脈から解決できることがあります）、一般的なポイントとしては、即座に「b」がグループを表すのか、タイプを表すのかは明確ではない場合があります。このような意味処理は、判断が下されるまでにいくつかのレベルのルール定義をまたいで行われることがあります。

assignt = "=" / "/=" assigng = "=" / "//="

assignt = "=" / "/=" assigng = "=" / "//=" assignt = "=" / "/=" assigng = "=" / "//="

A plain equals sign defines the rule name as the equivalent of the expression to the right; it is an error if the name was already defined with a different expression. A "/=" or "//=" extends a named type or a group by additional choices; a number of these could be replaced by collecting all the right-hand sides and creating a single rule with a type choice or a group choice built from the right-hand sides in the order of the rules given. (It is not an error to extend a rule name that has not yet been defined; this makes the right-hand side the first entry in the choice being created.)

単純な等号記号は、右側の式と同等のルール名を定義します。既に異なる式で名前が定義されている場合、エラーになります。"/="または"//="は、追加の選択肢によって名前付きタイプまたはグループを拡張します。これらのいくつかは、すべての右辺を収集し、与えられた規則の順序で右辺から作成されたタイプの選択またはグループの選択から単一のルールが作成されることによって置き換えることができます。（まだ定義されていないルール名を拡張することはエラーではありません。これにより、右辺が作成中の選択の最初のエントリになります。）

genericparm = "<" S id S *("," S id S ) ">" genericarg = "<" S type1 S *("," S type1 S ) ">"

Rule names can have generic parameters, which cause temporary assignments within the right-hand sides to the parameter names from the arguments given when citing the rule name.

ルール名にはジェネリックパラメータを持つことができます。これにより、ルール名を引用する際に指定された引数から、右辺に一時的な割り当てが行われます。

type = type1 *(S "/" S type1) A type can be given as a choice between one or more types. The choice matches a data item if the data item matches any one of the types given in the choice. The choice uses PEG semantics as discussed in Appendix A: the first choice that matches wins. (As a result, the order of rules that contribute to a single rule name can very well matter.) type = type1 *(S "/" S type1) 型は1つ以上の型の選択肢として指定できます。選択肢は、データアイテムが選択肢で指定されたいずれかの型と一致する場合、データアイテムと一致します。選択肢は、付録Aで議論されているPEGセマンティクスを使用します。最初に一致する選択肢が勝利します。（その結果、単一のルール名に寄与するルールの順序は非常に重要です。）

type1 = type2 [S (rangeop / ctlop) S type2]

type1 = type2 [S（rangeop / ctlop）S type2]

Two types can be combined with a range operator (see below) or a control operator (see Section 3.8).

2つのタイプは、範囲演算子（以下参照）または制御演算子（セクション3.8を参照）と組み合わせることができます。

type2 = value

type2 = 値

A type can be just a single value (such as 1 or "icecream" or h'0815'), which matches only a data item with that specific value (no conversions defined),

一つのタイプは単一の値（例えば1や "アイスクリーム"や h'0815'）であり、それは特定の値に一致するデータアイテムにのみ対応します（変換は定義されていません）。

   / typename [genericarg]

   / typename [genericarg]

   / typename [genericarg]

or be defined by a rule giving a meaning to a name (possibly after supplying generic arguments as required by the generic parameters),

または、名前に意味を与える規則によって定義される場合もあります（ジェネリックパラメータが必要な場合、必要に応じて一般的な引数を提供した後で）。

   / "(" S type S ")"

   / "(" S type S ")"

   / "(" S タイプ S ")"

or be defined in a parenthesized type expression (parentheses may be necessary to override some operator precedence), or

または、括弧で囲まれた型式の表現で定義される場合もあります（一部の演算子の優先順位を上書きするためには括弧が必要です）。

   / "{" S group S "}"

   / "{" S group S "}"

   / "{" S グループ S "}"

a map expression, which matches a valid CBOR map the key/value pairs of which can be ordered in such a way that the resulting sequence matches the group expression, or

「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」キーワードは、「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、「要求されています（REQUIRED）」、「することになります（SHALL）」、「することはありません（SHALL NOT）」、「すべきです（SHOULD）」、「すべきではありません（SHOULD NOT）」、「推奨されます（RECOMMENDED）」、「推奨されません（NOT RECOMMENDED）」、「してもよいです（MAY）」、「選択できます（OPTIONAL）」と翻訳されます。「a map expression, which matches a valid CBOR map the key/value pairs of which can be ordered in such a way that the resulting sequence matches the group expression, or」は日本語に翻訳すると、「結果のシーケンスがグループ式に一致するように、キー/値のペアを順序付けることができる有効なCBORマップと一致するマップ式、または」になります。

   / "[" S group S "]"

   / "[" S group S "]"

an array expression, which matches a CBOR array the elements of which -- when taken as values and complemented by a wildcard (matches anything) key each -- match the group, or

配列式は、各要素がグループと一致する場合に、値とワイルドカード（任意のものと一致する）キーとの補足を受けているCBOR配列と一致します。

   / "~" S typename [genericarg]

   / "~" S typename [genericarg]

   / "~" S typename [genericarg]

an "unwrapped" group (see Section 3.7), which matches the group inside a type defined as a map or an array by wrapping the group, or

「アンラップされた」グループ（セクション3.7を参照）は、グループを包むことで定義された型内のグループに一致する。

   / "&" S "(" S group S ")"
   / "&" S groupname [genericarg]

   / "" S "" S group S ""
   / "" S groupname [genericarg]

an enumeration expression, which matches any value that is within the set of values that the values of the group given can take, or

列挙式は、与えられたグループの値を取ることができる値の集合内の任意の値と一致するものとして扱われます。

   / "#" "6" ["." uint] "(" S type S ")"

   / "#" "6" ["." uint] "(" S type S ")"

   / "#" "6" ["." uint] "(" S type S ")"

a tagged data item, tagged with the "uint" given and containing the type given as the tagged value, or

タグ付きのデータ項目で、与えられた「uint」でタグ付けされ、タグ付きの値として与えられたタイプを含んでいます。または

   / "#" DIGIT ["." uint]                ; major/ai

   / "#" DIGIT ["." uint]                ; major/ai

   / "#" DIGIT ["." uint]                ; major/ai

a data item of a major type (given by the DIGIT), optionally constrained to the additional information given by the uint, or

デジットによって与えられた主要なタイプ（データ項目）は、必要に応じてuintによって与えられた追加情報に制約される場合があります。

   / "#"                                 ; any

   / "#"                                 ; 任意の文字

any data item.

任意のデータ項目。

rangeop = "..." / ".."

rangeop = "..." / ".." rangeop =「...」/「..」

A range operator can be used to join two type expressions that stand for either two integer values or two floating-point values; it matches any value that is between the two values, where the first value is always included in the matching set and the second value is included for ".." and excluded for "...".

範囲演算子は、2つの整数値または2つの浮動小数点値を表す2つの型式を結合するために使用できます。その演算子は、2つの値の間にある任意の値にマッチし、最初の値は常にマッチングセットに含まれ、2番目の値は「..」の場合は含まれ、「...」の場合は除外されます。

ctlop = "." id

ctlop = "." ID

A control operator ties a _target_ type to a _controller_ type as defined in Section 3.8. Note that control operators are an extension point for CDDL; additional documents may want to define additional control operators.

制御演算子は、セクション3.8で定義された「_target_」タイプを「_controller_」タイプに関連付けます。制御演算子はCDDLの拡張ポイントであることに注意してください。追加のドキュメントでは、追加の制御演算子を定義することも可能です。

group = grpchoice *(S "//" S grpchoice)

グループ = grpchoice *(S "//" S grpchoice)

A group matches any sequence of key/value pairs that matches any of the choices given (again using PEG semantics).

与えられた選択肢のいずれかに一致するキー/値のシーケンスに一致するグループ（再びPEGセマンティクスを使用して）

grpchoice = *(grpent optcom)

grpchoice = *(grpent optcom) grpchoice = *(grpent optcom)

Each of the component groups is given as a sequence of group entries. For a match, the sequence of key/value pairs given needs to match the sequence of group entries in the sequence given.

各コンポーネントグループは、グループエントリのシーケンスとして与えられます。一致するためには、与えられたシーケンスのキー/値ペアのシーケンスが、与えられたシーケンスのグループエントリのシーケンスと一致する必要があります。

grpent = [occur S] [memberkey S] type

grpent = [occur S] [memberkey S] type grpent = [occur S] [memberkey S] タイプ

A group entry can be given by a value type, which needs to be matched by the value part of a single element; and, optionally, a memberkey type, which needs to be matched by the key part of the element, if the memberkey is given. If the memberkey is not given, the entry can only be used for matching arrays, not for maps. (See below for how that is modified by the occurrence indicator.)

グループエントリは、値型によって指定されることがあります。この値型は、単一要素の値部分と一致する必要があります。また、メンバーキーが指定されている場合は、メンバーキー型も指定することができます。メンバーキーが指定されていない場合、エントリはマップではなく配列の一致にのみ使用できます。（発生指示子によってどのように変更されるかについては、以下を参照してください。）

    / [occur S] groupname [genericarg]  ; preempted by above

/ [occur S] groupname [genericarg] ; 上記によって妨害されます

A group entry can be built from a named group, or

グループエントリは、名前付きグループから構築することができます。または

    / [occur S] "(" S group S ")"

    / [occur S] "(" S group S ")"

from a parenthesized group, again with a possible occurrence indicator.

カッコで囲まれたグループから、再度、可能な出現指示子と共に。

memberkey = type1 S ["^" S] "=>" / bareword S ":" / value S ":"

memberkey = type1 S ["^" S] "=>" / bareword S ":" / value S ":" memberkey = type1 S ["^" S] "=>" / bareword S ":" / value S ":" メンバーキー = タイプ1 S ["^" S] "=>" / ベアワード S ":" / 値 S ":"

Key types can be given by a type expression, a bareword (which stands for a type that just contains a string value created from this bareword), or a value (which stands for a type that just contains this value). A key value matches its key type if the key value is a member of the key type, unless a cut preceding it in the group applies (see Section 3.5.4 for how map matching is influenced by the presence of the cuts denoted by "^" or ":" in previous entries).

キータイプは、タイプ式、ベアワード（このベアワードから作成された文字列の値を含むタイプを表す）、または値（この値を含むタイプを表す）で指定することができます。キーの値は、そのキータイプのメンバーである場合、前のエントリで "^" または ":" で示されるカットの存在がマップマッチングに影響を与えることがない限り、キーのタイプに一致します（カットの影響については、セクション 3.5.4 を参照してください）。

bareword = id

A bareword is an alternative way to write a type with a single text string value; it can only be used in the syntactic context given above.

A bareword is an alternative way to write a type with a single text string value; it can only be used in the syntactic context given above. → 「bareword は単一のテキスト文字列値で型を表すための代替的な方法です。これは上記の構文的な文脈でのみ使用できます。」

optcom = S ["," S]

optcom = S ["," S] optcom = S ["," S]

(Optional commas do not influence the matching.)

（オプションのカンマは、マッチングに影響を与えません。）

occur = [uint] "*" [uint] / "+" / "?"

発生 = [uint] "*" [uint] / "+" / "?"

An occurrence indicator modifies the group given to its right by requiring the group to match the sequence to be matched exactly for a certain number of times (see Section 3.2) in sequence, i.e., it acts as a (possibly infinite) group choice that contains choices with the group repeated each of the occurrences times.

発生指示子は、一定回数（セクション3.2を参照）連続して一致するように、その右側に与えられたグループを修正します。つまり、（無限かもしれない）グループ選択として機能し、各発生回数ごとにグループを繰り返します。

The rest of the ABNF describes syntax for value notation that should be familiar to readers from programming languages, with the possible exception of h'..' and b64'..' for byte strings, as well as syntactic elements such as comments and line ends.

ABNFの残りは、値表記の構文を説明しており、プログラミング言語の読者には馴染みのあるものです。ただし、h'..'とb64'..'のようなバイト文字列や、コメントや行末のような構文要素は除きます。

Appendix D. Standard Prelude

This appendix is normative.

この付録は正式なものです。MUST

The following prelude is automatically added to each CDDL file. (Note that technically, it is a postlude, as it does not disturb the selection of the first rule as the root of the definition.)

次の序文は、各CDDLファイルに自動的に追加されます。（技術的には、これは事実上の後記であるため、定義のルートとして最初の規則の選択を妨げるものではありません。）

               any = #

               任意 = #

               uint = #0
               nint = #1
               int = uint / nint

               uint = #0
               nint = #1
               int = uint / nint

               uint = #0
               nint = #1
               int = uint / nint

               bstr = #2
               bytes = bstr
               tstr = #3
               text = tstr

               bstr = #2
               bytes = bstr
               tstr = #3
               text = tstr

               bstr = #2
               bytes = bstr
               tstr = #3
               text = tstr

               tdate = #6.0(tstr)
               time = #6.1(number)
               number = int / float
               biguint = #6.2(bstr)
               bignint = #6.3(bstr)
               bigint = biguint / bignint
               integer = int / bigint
               unsigned = uint / biguint
               decfrac = #6.4([e10: int, m: integer])
               bigfloat = #6.5([e2: int, m: integer])
               eb64url = #6.21(any)
               eb64legacy = #6.22(any)
               eb16 = #6.23(any)
               encoded-cbor = #6.24(bstr)
               uri = #6.32(tstr)
               b64url = #6.33(tstr)
               b64legacy = #6.34(tstr)
               regexp = #6.35(tstr)
               mime-message = #6.36(tstr)
               cbor-any = #6.55799(any)
               float16 = #7.25
               float32 = #7.26
               float64 = #7.27
               float16-32 = float16 / float32
               float32-64 = float32 / float64
               float = float16-32 / float64

しなければなりません（MUST）

               tdate = #6.0(tstr)
               time = #6.1(number)
               number = int / float
               biguint = #6.2(bstr)
               bignint = #6.3(bstr)
               bigint = biguint / bignint
               integer = int / bigint
               unsigned = uint / biguint
               decfrac = #6.4([e10: int, m: integer])
               bigfloat = #6.5([e2: int, m: integer])
               eb64url = #6.21(any)
               eb64legacy = #6.22(any)
               eb16 = #6.23(any)
               encoded-cbor = #6.24(bstr)
               uri = #6.32(tstr)
               b64url = #6.33(tstr)
               b64legacy = #6.34(tstr)
               regexp = #6.35(tstr)
               mime-message = #6.36(tstr)
               cbor-any = #6.55799(any)
               float16 = #7.25
               float32 = #7.26
               float64 = #7.27
               float16-32 = float16 / float32
               float32-64 = float32 / float64
               float = float16-32 / float64

               false = #7.20
               true = #7.21
               bool = false / true
               nil = #7.22
               null = nil
               undefined = #7.23

               false = #7.20
               true = #7.21
               bool = false / true
               nil = #7.22
               null = nil
               undefined = #7.23

               false = #7.20
               true = #7.21
               bool = false / true
               nil = #7.22
               null = nil
               undefined = #7.23

Figure 14: CDDL Prelude

Note that the prelude is deemed to be fixed. This means, for instance, that additional tags beyond those defined in [RFC7049], as registered, need to be defined in each CDDL file that is using them.

前文は固定されていると見なされます。つまり、例えば、[RFC7049]に定義されている以外の追加のタグは、それらを使用している各CDDLファイルで定義する必要があります。

A common stumbling point is that the prelude does not define a type "string". CBOR has byte strings ("bytes" in the prelude) and text strings ("text"), so a type that is simply called "string" would be ambiguous.

よくある落とし穴は、プレリュードが "string" という型を定義していないことです。CBOR にはバイト文字列（プレリュードでは "bytes"）とテキスト文字列（"text"）があり、単に "string" と呼ばれる型はあいまいです。

Appendix E. Use with JSON

This appendix is normative.

この付録は規範的です。

The JSON generic data model (implicit in [RFC8259]) is a subset of the generic data model of CBOR. So, one can use CDDL with JSON by limiting oneself to what can be represented in JSON. Roughly speaking, this means leaving out byte strings, tags, and simple values other than "false", "true", and "null", leading to the following limited prelude:

JSONの一般的なデータモデル（[RFC8259]で暗黙的に表されます）は、CBORの一般的なデータモデルのサブセットです。そのため、JSONでCDDLを使用する場合は、JSONで表現できるものに自分自身を制限することができます。大まかに言えば、これはバイト文字列、タグ、および「false」、「true」、「null」以外の単純な値を除外することを意味し、以下の限定的な前文が得られます。

                   any = #

                   any = #

                   任意 = #

                   uint = #0
                   nint = #1
                   int = uint / nint

                   uint = #0
                   nint = #1
                   int = uint / nint

                   uint = #0
                   nint = #1
                   int = uint / nint

                   tstr = #3
                   text = tstr

     tstr = #3
     text = tstr

     tstr = #3
     text = tstr

                   number = int / float

                  number = int / float

                  number = 整数 / 浮動小数点数

                   float16 = #7.25
                   float32 = #7.26
                   float64 = #7.27
                   float16-32 = float16 / float32
                   float32-64 = float32 / float64
                   float = float16-32 / float64

                   float16 = #7.25
                   float32 = #7.26
                   float64 = #7.27
                   float16-32 = float16 / float32
                   float32-64 = float32 / float64
                   float = float16-32 / float64

                   float16 = #7.25
                   float32 = #7.26
                   float64 = #7.27
                   float16-32 = float16 / float32
                   float32-64 = float32 / float64
                   float = float16-32 / float64

                   false = #7.20
                   true = #7.21
                   bool = false / true
                   nil = #7.22
                   null = nil

                   false = #7.20
                   true = #7.21
                   bool = false / true
                   nil = #7.22
                   null = nil

                   false = #7.20
                   true = #7.21
                   bool = false / true
                   nil = #7.22
                   null = nil

Figure 15: JSON-Compatible Subset of CDDL Prelude

Figure 15: JSON-Compatible Subset of CDDL Prelude（あらすじ）

(The major types given here do not have a direct meaning in JSON, but they can be interpreted as CBOR major types translated through Section 4 of [RFC7049].)

ここで示されている主要なタイプは、JSONに直接の意味を持っていませんが、CBORの主要なタイプとして解釈することができます。これは、[RFC7049]のSection 4を通じて変換されます。

There are a few fine points in using CDDL with JSON. First, JSON does not distinguish between integers and floating-point numbers; there is only one kind of number (which may happen to be integral). In this context, specifying a type as "uint", "nint", or "int" then becomes a predicate that the number be integral. As an example, this means that the following JSON numbers are all matching "uint":

JSONを使用する際には、いくつかの細かいポイントがあります。まず、JSONでは整数と浮動小数点数を区別しません。数値にはただ一種類の数値（整数になることもある）しかありません。この文脈では、「uint」、「nint」、または「int」という型を指定することは、数値が整数であることを条件とする述語となります。例えば、次のJSONの数値はすべて「uint」と一致します。

   10 10.0 1e1 1.0e1 100e-1

   10 10.0 1e1 1.0e1 100e-1

   10 10.0 1e1 1.0e1 100e-1

(The fact that these are all integers may be surprising to users accustomed to the long tradition in programming languages of using decimal points or exponents in a number to indicate a floating-point literal.)

これらがすべて整数であるという事実は、プログラミング言語の長い伝統で小数点や指数を使用して浮動小数点数リテラルを表すことに慣れているユーザーには驚くかもしれません。

CDDL distinguishes the various CBOR number types, but there is only one number type in JSON. The effect of specifying a floating-point precision (float16/float32/float64) is only to restrict the set of permissible values to those expressible with binary16/binary32/ binary64; this is unlikely to be very useful when using CDDL for specifying JSON data structures.

CDDLは、さまざまなCBORの数値型を区別しますが、JSONには1つの数値型しかありません。浮動小数点精度（float16/float32/float64）を指定する効果は、許容値のセットをbinary16/binary32/binary64で表現可能なものに制限することだけです。これは、JSONデータ構造を指定するためにCDDLを使用する際にはあまり役に立たないでしょう。

Fundamentally, the number system of JSON itself is based on decimal numbers and decimal fractions and does not have limits to its precision or range. In practice, JSON numbers are often parsed into a number type that is called "float64" here, creating a number of limitations to the generic data model [RFC7493]. In particular, this means that integers can only be expressed with interoperable exactness when they lie in the range [-(2**53)+1, (2**53)-1] -- a smaller range than that covered by CDDL "int".

基本的に、JSON自体の数値システムは10進数と10進小数点に基づいており、精度や範囲に制限はありません。実際には、JSONの数値はしばしばここで「float64」と呼ばれる数値型に解析され、一般的なデータモデル[RFC7493]に制約が生じます。特に、これは整数が相互運用性を持つ厳密さで表現できる範囲が[-(2**53)+1, (2**53)-1]という範囲に制限されることを意味します。これはCDDLの「int」がカバーしている範囲よりも狭いです。

JSON applications that want to stay compatible with I-JSON ("Internet JSON"; see [RFC7493]) may therefore want to define integer types with more limited ranges, such as in Figure 16. Note that the types given here are not part of the prelude; they need to be copied into the CDDL specification if needed.

I-JSON（「Internet JSON」：詳細は[RFC7493]を参照）と互換性を維持したいJSONアプリケーションでは、図16のような範囲が制限された整数型を定義することを検討する必要があります。なお、ここで提供されている型は予備の一部ではないため、必要な場合はCDDL仕様にコピーする必要があります。

            ij-uint = 0..9007199254740991
            ij-nint = -9007199254740991..-1
            ij-int = -9007199254740991..9007199254740991

            ij-uint = 0..9007199254740991
            ij-nint = -9007199254740991..-1
            ij-int = -9007199254740991..9007199254740991

            ij-uint = 0..9007199254740991
            ij-nint = -9007199254740991..-1
            ij-int = -9007199254740991..9007199254740991

Figure 16: I-JSON Types for CDDL (Not Part of Prelude)

Figure 16: I-JSONのためのCDDL型（プレリュードの一部ではありません）

JSON applications that do not need to stay compatible with I-JSON and that actually may need to go beyond the 64-bit unsigned and negative integers supported by "int" (= "uint"/"nint") may want to use the following additional types from the standard prelude, which are expressed in terms of tags but can straightforwardly be mapped into JSON (but not I-JSON) numbers:

I-JSONとの互換性を保持する必要のないJSONアプリケーションで、「int」（=「uint」/「nint」）がサポートする64ビット未満の符号なし整数および負の整数を超える必要がある場合は、以下の標準前提条件から以下の追加の型を使用することができます。これらの型はタグに基づいて表現されますが、JSON（ただしI-JSONではありません）の数値に直接マッピングすることができます。

   biguint = #6.2(bstr)
   bignint = #6.3(bstr)
   bigint = biguint / bignint
   integer = int / bigint
   unsigned = uint / biguint

   biguint = #6.2(bstr)
   bignint = #6.3(bstr)
   bigint = biguint / bignint
   integer = int / bigint
   unsigned = uint / biguint

   biguint = #6.2(bstr)
   bignint = #6.3(bstr)
   bigint = biguint / bignint
   integer = int / bigint
   unsigned = uint / biguint

CDDL at this point does not have a way to express the unlimited floating-point precision that is theoretically possible with JSON; at the time of writing, this is rarely used in protocols in practice. この時点のCDDLでは、JSONで理論上可能な無制限の浮動小数点精度を表現する方法はありません。執筆時点では、これは実際のプロトコルでほとんど使用されていません。

Note that a data model described in CDDL is always restricted by what can be expressed in the serialization; e.g., floating-point values such as NaN (not a number) and the infinities cannot be represented in JSON even if they are allowed in the CDDL generic data model.

CDDLで説明されるデータモデルは、シリアライズで表現可能な内容に常に制約があります。たとえば、NaN（数ではない）や無限大などの浮動小数点値は、CDDLの一般的なデータモデルでは許可されていても、JSONで表現することはできません。

Appendix F. A CDDL Tool

This appendix is for information only.

この付録は情報提供のみです。

A rough CDDL tool is available. For CDDL specifications, it can check the syntax, generate one or more instances (expressed in CBOR diagnostic notation or in pretty-printed JSON), and validate an existing instance against the specification:

簡易なCDDLツールが利用可能です。CDDLの仕様に対して、構文をチェックすることができ、1つ以上のインスタンス（CBOR診断用記法または整形されたJSONで表現されます）を生成し、既存のインスタンスを仕様に対して検証することもできます。

                Usage:
                cddl spec.cddl generate [n]
                cddl spec.cddl json-generate [n]
                cddl spec.cddl validate instance.cbor
                cddl spec.cddl validate instance.json

                使用法:
                cddl spec.cddl generate [n]
                cddl spec.cddl json-generate [n]
                cddl spec.cddl validate instance.cbor
                cddl spec.cddl validate instance.json

Figure 17: CDDL Tool Usage

Figure 17: CDDLツールの使用方法

Install on a system with a modern Ruby via:

現代のRubyを使用したシステムにインストールしてください。以下のコマンドを使用します。

                          gem install cddl

                          gemのインストール方法は以下の通りです：cddlをインストールします。

Figure 18: CDDL Tool Installation

Figure 18: CDDL ツールのインストール

The accompanying CBOR diagnostic tools (which are automatically installed by the above) are described in <https://github.com/cabo/ cbor-diag>; they can be used to convert between binary CBOR, a pretty-printed hexadecimal form of binary CBOR, CBOR diagnostic notation, JSON, and YAML [YAML].

Appendix G. Extended Diagnostic Notation

Appendix G. 拡張診断表記

This appendix is normative.

この付録は規範です。

Section 6 of [RFC7049] defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. Diagnostic notation is based on JSON, with extensions for representing CBOR constructs such as binary data and tags.

[RFC7049]のSection 6 は、バイナリデータに頼らずにCBORデータ項目について会話するための「診断表示法」を定義しています。診断表示法はJSONを基にしており、バイナリデータやタグなどのCBOR構造を表現するための拡張機能を持っています。

(Standardizing this together with the actual interchange format does not serve to create another interchange format but enables the use of a shared diagnostic notation in tools for and documents about CBOR.)

（実際のやり取り形式と一緒にこれを標準化することは、別のやり取り形式を作成するためではなく、CBORについてのツールや文書で共有される診断表記の使用を可能にします。）

This appendix discusses a few extensions to the diagnostic notation that have turned out to be useful since RFC 7049 was written. We refer to the result as Extended Diagnostic Notation (EDN).

この付録では、RFC 7049 の作成以降に有用であることがわかった診断表記のいくつかの拡張について説明します。この結果を拡張診断表記 (EDN) と呼びます。

G.1. Whitespace in Byte String Notation

G.1. バイト文字列表記のホワイトスペース

Examples often benefit from some whitespace (spaces, line breaks) in byte strings. In EDN, whitespace is ignored in prefixed byte strings; for instance, the following are equivalent:

例は、バイト文字列にいくつかのホワイトスペース（スペース、改行）を入れることでしばしば利益を得ます。EDNでは、プレフィックス付きバイト文字列では空白は無視されます。例えば、次のものは同等です。

   h'48656c6c6f20776f726c64'
   h'48 65 6c 6c 6f 20 77 6f 72 6c 64'
   h'4 86 56c 6c6f
     20776 f726c64'

   h'48656c6c6f20776f726c64'
   h'48 65 6c 6c 6f 20 77 6f 72 6c 64'
   h'4 86 56c 6c6f
     20776 f726c64'

G.2. Text in Byte String Notation

G.2. バイト文字列表記のテキスト

Diagnostic notation notates byte strings in one of the base encodings per [RFC4648], enclosed in single quotes, prefixed by >h< for base16, >b32< for base32, >h32< for base32hex, or >b64< for base64 or base64url. Quite often, byte strings carry bytes that are meaningfully interpreted as UTF-8 text. EDN allows the use of single quotes without a prefix to express byte strings with UTF-8 text; for instance, the following are equivalent:

診断表記法は、バイト文字列を[RFC4648]のいずれかの基底エンコーディングで表記し、シングルクォートで囲み、>h<をbase16のプレフィックスとして、>b32<をbase32のプレフィックスとして、>h32<をbase32hexのプレフィックスとして、または>b64<をbase64またはbase64urlのプレフィックスとして使用します。よくあることですが、バイト文字列はUTF-8テキストとして意味を持つバイトを携行します。EDNは、UTF-8テキストを持つバイト文字列を表現するために、プレフィックスなしのシングルクォートの使用を許可します。例えば、以下の表記は等価です:

   'hello world'
   h'68656c6c6f20776f726c64'

   'hello world'
   h'68656c6c6f20776f726c64'

The escaping rules of JSON strings are applied equivalently for text-based byte strings, e.g., "\" stands for a single backslash and "'" stands for a single quote. Whitespace is included literally, i.e., the previous section does not apply to text-based byte strings.

JSON文字列のエスケープルールは、テキストベースのバイト文字列にも同様に適用されます。たとえば、"\"は単一のバックスラッシュを表し、"'"は単一のクオートを表します。空白は文字通り含まれるため、前のセクションはテキストベースのバイト文字列には適用されません。

G.3. Embedded CBOR and CBOR Sequences in Byte Strings

G.3. バイト文字列内の埋め込みCBORとCBORシーケンス

Where a byte string is to carry an embedded CBOR-encoded item, or more generally a sequence of zero or more such items, the diagnostic notation for these zero or more CBOR data items, separated by commas, can be enclosed in << and >> to notate the byte string resulting from encoding the data items and concatenating the result. For instance, each pair of columns in the following are equivalent:

バイト文字列が埋め込みCBORエンコードアイテム、または一般的にはそのようなアイテムの0個以上のシーケンスを携行する場合、これらの0個以上のCBORデータアイテムの診断表記法は、コンマで区切られ、<<と>>で囲まれて、データアイテムをエンコードし、結果を連結した結果となるバイト文字列を表記します。例えば、以下の各列のペアは等価です:

   <<1>>              h'01'
   <<1, 2>>           h'0102'
   <<"foo", null>>    h'63666F6FF6'
   <<>>               h''

   <<1>>              h'01'
   <<1, 2>>           h'0102'
   <<"foo", null>>    h'63666F6FF6'
   <<>>               h''

G.4. Concatenated Strings

G.4. 連結された文字列

While the ability to include whitespace enables line-breaking of encoded byte strings, a mechanism is needed to be able to include text strings as well as byte strings in direct UTF-8 representation into line-based documents (such as RFCs and source code).

エンコードされたバイト文字列にホワイトスペースを含めることで改行が可能になります。一方で、テキスト文字列とバイト文字列を直接のUTF-8表現で行ベースのドキュメント（RFCやソースコードなど）に含めるためのメカニズムが必要です。

We extend the diagnostic notation by allowing multiple text strings or multiple byte strings to be notated separated by whitespace; these are then concatenated into a single text or byte string, respectively. Text strings and byte strings do not mix within such a concatenation, except that byte string notation can be used inside a sequence of concatenated text string notation to encode characters that may be better represented in an encoded way. The following four values are equivalent:

診断表記法を拡張し、テキスト文字列またはバイト文字列をホワイトスペースで区切って示すことを許可します。これらはそれぞれ一つのテキスト文字列またはバイト文字列に連結されます。ただし、テキスト文字列とバイト文字列は、そのような連結の中で混在しませんが、より適切に表現できる文字をエンコードするために、エンコードされた形式でバイト文字列表記をテキスト文字列表記の連結の中に使用することができます。以下の4つの値は同等です。

   "Hello world"
   "Hello " "world"
   "Hello" h'20' "world"
   "" h'48656c6c6f20776f726c64' ""

   "Hello world"
   "Hello " "world"
   "Hello" h'20' "world"
   "" h'48656c6c6f20776f726c64' ""

Similarly, the following byte string values are equivalent:

同様に、次のバイトストリングの値は等価です：

   'Hello world'
   'Hello ' 'world'
   'Hello ' h'776f726c64'
   'Hello' h'20' 'world'
   '' h'48656c6c6f20776f726c64' '' b64''
   h'4 86 56c 6c6f' h' 20776 f726c64'

   'Hello world'
   'Hello ' 'world'
   'Hello ' h'776f726c64'
   'Hello' h'20' 'world'
   '' h'48656c6c6f20776f726c64' '' b64''
   h'4 86 56c 6c6f' h' 20776 f726c64'

(Note that the approach of separating by whitespace, while familiar from the C language, requires some attention -- a single comma makes a big difference here.)

（C言語でよく見られる方法である空白文字での区切りの手法に注意してください。ここでは、単一のカンマが大きな違いを生じます。）

G.5. Hexadecimal, Octal, and Binary Numbers

G.5. 16進数、8進数、および2進数

In addition to JSON's decimal numbers, EDN provides hexadecimal, octal, and binary numbers in the usual C-language notation (octal with 0o prefix present only).

JSONの10進数に加えて、EDNは通常のC言語表記（8進数は0o接頭辞に限ります）で16進数、8進数、および2進数を提供します。

The following are equivalent:

以下の表記は等価です：

   4711
   0x1267
   0o11147
   0b1001001100111

   4711
   0x1267
   0o11147
   0b1001001100111

As are:

同様に、以下の表記は等価です。

   1.5
   0x1.8p0
   0x18p-4

   1.5
   0x1.8p0
   0x18p-4

G.6. Comments

G.6. コメント

Longer pieces of diagnostic notation may benefit from comments. JSON famously does not provide for comments, and basic diagnostic notation per RFC 7049 inherits this property.

長い診断表記にはコメントが役立つ場合があります。JSONはコメントを提供しないことで有名であり、RFC 7049の基本的な診断表記もこの特性を継承しています。

In EDN, comments can be included, delimited by slashes ("/"). Any text within and including a pair of slashes is considered a comment.

EDNでは、コメントを含むことができます。コメントはスラッシュ("/")で区切られます。スラッシュのペア内にあるテキストはコメントとして扱われます。

Comments are considered whitespace. Hence, they are allowed in prefixed byte strings; for instance, the following are equivalent:

コメントは空白として扱われます。したがって、プレフィックス付きバイト列でも許可されます。たとえば、以下は同等です。

   h'68656c6c6f20776f726c64'
   h'68 65 6c /doubled l!/ 6c 6f /hello/
     20 /space/
     77 6f 72 6c 64' /world/

   h'68656c6c6f20776f726c64'
   h'68 65 6c /doubled l!/ 6c 6f /hello/
     20 /space/
     77 6f 72 6c 64' /world/

This can be used to annotate a CBOR structure as in:

これはCBOR構造に注釈を付けるために使用することができます。

   /grasp-message/ [/M_DISCOVERY/ 1, /session-id/ 10584416,
                    /objective/ [/objective-name/ "opsonize",
                                 /D, N, S/ 7, /loop-count/ 105]]

   /grasp-message/ [/M_DISCOVERY/ 1, /session-id/ 10584416,
                    /objective/ [/objective-name/ "opsonize",
                                 /D, N, S/ 7, /loop-count/ 105]]

(There are currently no end-of-line comments. If we want to add them, "//" sounds like a reasonable delimiter given that we already use slashes for comments, but we could also go, for example, for "#".)

（現在、行末コメントはありません。追加する場合は、「//」はコメント用のスラッシュを既に使用しているため、理にかなっているようですが、例えば「#」を選択することもできます。

Appendix H. Examples

This appendix is for information only.

この付録は情報提供のみです。

This appendix contains a few examples of structures defined using CDDL. The theme for the examples is taken from [RFC7071], which defines certain JSON structures in English. For a similar example, it may also be of interest to examine Appendix A of [RFC8007], which contains a CDDL definition for a JSON structure defined in the main body of that RFC.

この付録には、CDDLを使用して定義されたいくつかの構造の例がいくつか含まれています。これらの例のテーマは、英語で定義されたあるJSON構造を定義している[RFC7071]から取られています。同様の例として、[RFC8007]の付録Aを調べることも興味深いかもしれません。付録Aには、そのRFCの本文で定義されたJSON構造のCDDL定義が含まれています。

These examples all happen to describe data that is interchanged in JSON. Examples for CDDL definitions of data that is interchanged in CBOR can be found in [RFC8152], [GRASP], and [RFC8428].

これらの例はすべて、JSONで交換されるデータを説明しています。CBORで交換されるデータのCDDL定義の例は、[RFC8152]、[GRASP]、および[RFC8428]で見つけることができます。

[RFC7071] defines the "reputon" structure for JSON using somewhat formalized English text. Here is a (somewhat verbose) equivalent definition using the same terms, but notated in CDDL:

[RFC7071]は、「reputon」構造体について、いくぶん形式化された英文テキストを使用したJSONを定義しています。以下は、同じ用語を使用しているがCDDLで表記された（やや冗長な）同等の定義です。

              reputation-object = {
                reputation-context,
                reputon-list
              }

              reputation-object = {
                reputation-context,
                reputon-list
              }

              reputation-object = {
                reputation-context,
                reputon-list
              }

              reputation-object = {
                reputation-context,
                reputon-list
              }

              reputation-context = (
                application: text
              )

              reputation-context = (
                application: text
              )

               = (

              )

              reputon-list = (
                reputons: reputon-array
              )

              reputon-list = (
                reputons: reputon-array
              )

              reputon-list = (
                reputons: reputon-array
              )

              reputon-list = (
                reputons: reputon-array
              )

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon-array = [* reputon]

              reputon = {
                rater-value,
                assertion-value,
                rated-value,
                rating-value,
                ? conf-value,
                ? normal-value,
                ? sample-value,
                ? gen-value,
                ? expire-value,
                * ext-value,
              }
              rater-value = ( rater: text )
              assertion-value = ( assertion: text )
              rated-value = ( rated: text )
              rating-value = ( rating: float16 )
              conf-value = ( confidence: float16 )
              normal-value = ( normal-rating: float16 )
              sample-value = ( sample-size: uint )
              gen-value = ( generated: uint )
              expire-value = ( expires: uint )
              ext-value = ( text => any )

              reputon = {
                rater-value,
                assertion-value,
                rated-value,
                rating-value,
                ? conf-value,
                ? normal-value,
                ? sample-value,
                ? gen-value,
                ? expire-value,
                * ext-value,
              }
              rater-value = ( rater: text )
              assertion-value = ( assertion: text )
              rated-value = ( rated: text )
              rating-value = ( rating: float16 )
              conf-value = ( confidence: float16 )
              normal-value = ( normal-rating: float16 )
              sample-value = ( sample-size: uint )
              gen-value = ( generated: uint )
              expire-value = ( expires: uint )
              ext-value = ( text => any )

              reputon = {
                rater-value,
                assertion-value,
                rated-value,
                rating-value,
                ? conf-value,
                ? normal-value,
                ? sample-value,
                ? gen-value,
                ? expire-value,
                * ext-value,
              }
              rater-value = ( rater: text )
              assertion-value = ( assertion: text )
              rated-value = ( rated: text )
              rating-value = ( rating: float16 )
              conf-value = ( confidence: float16 )
              normal-value = ( normal-rating: float16 )
              sample-value = ( sample-size: uint )
              gen-value = ( generated: uint )
              expire-value = ( expires: uint )
              ext-value = ( text => any )

An equivalent, more compact form of this example would be:

この例の同等かつより縮小された形式は以下の通りです：

                     reputation-object = {
                       application: text
                       reputons: [* reputon]
                     }

                     reputation-object = {
                       application: text
                       reputons: [* reputon]
                     }

                     reputation-object = {
                       application: text
                       reputons: [* reputon]
                     }

                     reputon = {
                       rater: text
                       assertion: text
                       rated: text
                       rating: float16
                       ? confidence: float16
                       ? normal-rating: float16
                       ? sample-size: uint
                       ? generated: uint
                       ? expires: uint
                       * text => any
                     }

                     reputon = {
                       rater: text
                       assertion: text
                       rated: text
                       rating: float16
                       ? confidence: float16
                       ? normal-rating: float16
                       ? sample-size: uint
                       ? generated: uint
                       ? expires: uint
                       * text => any
                     }

                     reputon = {
                       rater: text
                       assertion: text
                       rated: text
                       rating: float16
                       ? confidence: float16
                       ? normal-rating: float16
                       ? sample-size: uint
                       ? generated: uint
                       ? expires: uint
                       * text => any
                     }

Note how this rather clearly delineates the structure somewhat shrouded by so many words in Section 6.2.2 of [RFC7071]. Also, this definition makes it clear that several ext-values are allowed (by definition with different member names); RFC 7071 could be read to forbid the repetition of ext-value ("A specific reputon-element MUST NOT appear more than once" is ambiguous).

Note how this rather clearly delineates the structure somewhat shrouded by so many words in [RFC7071]のSection 6.2.2. Also, this definition makes it clear that several ext-values are allowed (by definition with different member names); RFC 7071 could be read to forbid the repetition of ext-value ("A specific reputon-element MUST NOT appear more than once" is ambiguous).

The CDDL tool described in Appendix F generates as one example:

付録Fで説明されているCDDLツールは、以下の例のように生成します：

               {
                 "application": "conchometry",
                 "reputons": [
                   {
                     "rater": "Ephthianura",
                     "assertion": "codding",
                     "rated": "sphaerolitic",
                     "rating": 0.34133473256800795,
                     "confidence": 0.9481983064298332,
                     "expires": 1568,
                     "unplaster": "grassy"
                   },
                   {
                     "rater": "nonchargeable",
                     "assertion": "raglan",
                     "rated": "alienage",
                     "rating": 0.5724646875815566,
                     "sample-size": 3514,
                     "Aldebaran": "unchurched",
                     "puruloid": "impersonable",
                     "uninfracted": "pericarpoidal",
                     "schorl": "Caro"
                   },
                   {
                     "rater": "precollectable",
                     "assertion": "Merat",
                     "rated": "thermonatrite",
                     "rating": 0.19164006323936977,
                     "confidence": 0.6065252103391268,
                     "normal-rating": 0.5187773690879303,
                     "generated": 899,
                     "speedy": "solidungular",
                     "noviceship": "medicine",
                     "checkrow": "epidictic"
                   }
                 ]
               }

               {
                 "application": "conchometry",
                 "reputons": [
                   {
                     "rater": "Ephthianura",
                     "assertion": "codding",
                     "rated": "sphaerolitic",
                     "rating": 0.34133473256800795,
                     "confidence": 0.9481983064298332,
                     "expires": 1568,
                     "unplaster": "grassy"
                   },
                   {
                     "rater": "nonchargeable",
                     "assertion": "raglan",
                     "rated": "alienage",
                     "rating": 0.5724646875815566,
                     "sample-size": 3514,
                     "Aldebaran": "unchurched",
                     "puruloid": "impersonable",
                     "uninfracted": "pericarpoidal",
                     "schorl": "Caro"
                   },
                   {
                     "rater": "precollectable",
                     "assertion": "Merat",
                     "rated": "thermonatrite",
                     "rating": 0.19164006323936977,
                     "confidence": 0.6065252103391268,
                     "normal-rating": 0.5187773690879303,
                     "generated": 899,
                     "speedy": "solidungular",
                     "noviceship": "medicine",
                     "checkrow": "epidictic"
                   }
                 ]
               }

               {
                 "application": "conchometry",
                 "reputons": [
                   {
                     "rater": "Ephthianura",
                     "assertion": "codding",
                     "rated": "sphaerolitic",
                     "rating": 0.34133473256800795,
                     "confidence": 0.9481983064298332,
                     "expires": 1568,
                     "unplaster": "grassy"
                   },
                   {
                     "rater": "nonchargeable",
                     "assertion": "raglan",
                     "rated": "alienage",
                     "rating": 0.5724646875815566,
                     "sample-size": 3514,
                     "Aldebaran": "unchurched",
                     "puruloid": "impersonable",
                     "uninfracted": "pericarpoidal",
                     "schorl": "Caro"
                   },
                   {
                     "rater": "precollectable",
                     "assertion": "Merat",
                     "rated": "thermonatrite",
                     "rating": 0.19164006323936977,
                     "confidence": 0.6065252103391268,
                     "normal-rating": 0.5187773690879303,
                     "generated": 899,
                     "speedy": "solidungular",
                     "noviceship": "medicine",
                     "checkrow": "epidictic"
                   }
                 ]
               }

Acknowledgements

Inspiration was taken from the C and Pascal languages, MPEG's conventions for describing structures in the ISO base media file format, RELAX NG and its compact syntax [RELAXNG], and, in particular, Andrew Lee Newton's early proposals on JSON Content Rules (JCR) as found in draft version four (-04) of [JCR]. Inspiration was taken from the C and Pascal languages, MPEG's conventions for describing structures in the ISO base media file format, RELAX NG (Resource Description Framework for XML Next Generation)とそれの簡潔な構文[RELAXNG]、そして特にAndrew Lee Newtonが提案したJSON Content Rules (JCR) found in draft version four (-04)の[JCR]を元にしています。

Lots of highly useful feedback came from members of the IETF CBOR WG -- in particular, Ari Keranen, Brian Carpenter, Burt Harris, Jeffrey Yasskin, Jim Hague, Jim Schaad, Joe Hildebrand, Max Pritikin, Michael Richardson, Pete Cordell, Sean Leonard, and Yaron Sheffer. Also, Francesca Palombini and Joe volunteered to chair the WG when it was created, providing the framework for generating and processing this feedback, with Barry Leiba having taken over from Joe since then. Chris Lonvick and Ines Robles provided additional reviews during IESG processing, and Alexey Melnikov steered the process as the responsible Area Director.

IETFのCBORワーキンググループのメンバーから、非常に有益なフィードバックがたくさん寄せられました。特に、アリ・ケラネン、ブライアン・カーペンター、バート・ハリス、ジェフリー・ヤスキン、ジム・ヘーグ、ジム・シャード、ジョー・ヒルデブランド、マックス・プリティキン、マイケル・リチャードソン、ピート・コーデル、ショーン・レナード、ヤロン・シェファーからのフィードバックがありました。また、フランチェスカ・パロンビーニとジョーがワーキンググループの議長を志 volunteersdersし、このフィードバックの生成と処理のための枠組みを提供しました。その後、バリー・ライバがジョーの後を引き継いでいます。Chris LonvickとInes RoblesはIESGの処理中に追加のレビューを提供し、Alexey Melnikovは責任あるエリアディレクターとしてプロセスを指導しました。

The CDDL tool described in Appendix F was written by Carsten Bormann, building on previous work by Troy Heninger and Tom Lord.

付録 F で説明されている CDDL ツールは、Carsten Bormann によって書かれ、Troy Heninger と Tom Lord の先行作業を基にしています。

RFC 8610

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures

RFC 8610

簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現するための表記法

Abstract

概要