[要約] RFC 8610は、CBORとJSONデータ構造を表現するための簡潔なデータ定義言語（CDDL）の規定です。このRFCの目的は、データ構造を明確に定義し、相互運用性を向上させることです。
Internet Engineering Task Force (IETF) H. Birkholz
Request for Comments: 8610 Fraunhofer SIT
Category: Standards Track C. Vigano
ISSN: 2070-1721 Universitaet Bremen
C. Bormann
Universitaet Bremen TZI
June 2019
Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則
Abstract
概要
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）データ構造（RFC 7049）を表現する表記規則を提案します。その主な目的は、CBORまたはJSONを使用するプロトコルメッセージおよびデータ形式の構造を表現する簡単で明確な方法を提供することです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Notation ......................................5
1.2. Terminology ................................................5
2. The Style of Data Structure Specification .......................5
2.1. Groups and Composition in CDDL .............................7
2.1.1. Usage ..............................................10
2.1.2. Syntax .............................................10
2.2. Types .....................................................11
2.2.1. Values .............................................11
2.2.2. Choices ............................................11
2.2.3. Representation Types ...............................13
2.2.4. Root Type ..........................................14
3. Syntax .........................................................15
3.1. General Conventions .......................................15
3.2. Occurrence ................................................16
3.3. Predefined Names for Types ................................17
3.4. Arrays ....................................................18
3.5. Maps ......................................................19
3.5.1. Structs ............................................19
3.5.2. Tables .............................................22
3.5.3. Non-deterministic Order ............................23
3.5.4. Cuts in Maps .......................................24
3.6. Tags ......................................................25
3.7. Unwrapping ................................................26
3.8. Controls ..................................................27
3.8.1. Control Operator .size .............................27
3.8.2. Control Operator .bits .............................28
3.8.3. Control Operator .regexp ...........................29
3.8.4. Control Operators .cbor and .cborseq ...............30
3.8.5. Control Operators .within and .and .................30
3.8.6. Control Operators .lt, .le, .gt, .ge, .eq,
.ne, and .default ..................................31
3.9. Socket/Plug ...............................................32
3.10. Generics .................................................33
3.11. Operator Precedence ......................................34
4. Making Use of CDDL .............................................36
4.1. As a Guide for a Human User ...............................36
4.2. For Automated Checking of CBOR Data Structures ............36
4.3. For Data Analysis Tools ...................................37
5. Security Considerations ........................................37
6. IANA Considerations ............................................38
6.1. CDDL Control Operators Registry ...........................38
7. References .....................................................40
7.1. Normative References ......................................40
7.2. Informative References ....................................41
Appendix A. Parsing Expression Grammars (PEGs) ....................43
Appendix B. ABNF Grammar ..........................................45
Appendix C. Matching Rules ........................................47
Appendix D. Standard Prelude ......................................52
Appendix E. Use with JSON .........................................53
Appendix F. A CDDL Tool ...........................................56
Appendix G. Extended Diagnostic Notation ..........................56
G.1. Whitespace in Byte String Notation .........................57
G.2. Text in Byte String Notation ...............................57
G.3. Embedded CBOR and CBOR Sequences in Byte Strings ...........57
G.4. Concatenated Strings .......................................58
G.5. Hexadecimal, Octal, and Binary Numbers .....................59
G.6. Comments ...................................................59
Appendix H. Examples ..............................................60
Acknowledgements ..................................................63
Contributors ......................................................63
Authors' Addresses ................................................64
In this document, a notational convention to express Concise Binary Object Representation (CBOR) data structures [RFC7049] is defined.
このドキュメントでは、簡潔なバイナリオブジェクト表現（CBOR）データ構造[RFC7049]を表現する表記規則が定義されています。
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を使用するプロトコルを定義するときに使用できる統一表記を提供することです。規約を「簡潔なデータ定義言語」または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).
それ自体は本来の目標ではありませんが、CBOR汎用データモデルのサブセットであるJSON汎用データモデルの便利な副作用は、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で定義されています。JSON形式を使用するCDDLおよび関連するCBORデータ項目（「インスタンス」）の例は、付録Hで説明されています。セクション4では、CDDLの使用法について説明します。概念の定義をわかりやすく説明するために、テキスト全体に例が示されています。 ABNF文法[RFC5234]を使用したCDDLの正式な定義は、付録Bにあります。最後に、すべてのCDDL仕様に自動的に付加され、利用できる標準CDDL定義の_prelude_が付録Dにリストされています。
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]で説明されているように解釈されます。
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).
新しい用語が_cursive_で導入されました。アンダースコアで囲まれた新しい用語としてプレーンテキストで表示されます。実行中のテキストのCDDLテキストは「タイプライター」にあり、これは二重引用符で囲まれたCDDLテキストとしてプレーンテキストでレンダリングされます（二重引用符は通常の英語の意味でも使用されます。読者はこれを文脈によって明確にすることが期待されます）。
In this specification, the term "byte" is used in its now-customary sense as a synonym for "octet".
この仕様では、「バイト」という用語は「オクテット」の同義語として現在慣習的な意味で使用されています。
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つの構成スタイルを指定するために使用されます。
o 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.
o _vector_：ほとんどが同じセマンティクスの要素の配列。署名されたデータアイテムに関連付けられた署名のセットは、ベクターの典型的なアプリケーションです。
o 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.
o _record_：データ構造定義で詳述されているように、その要素が異なる位置的に定義されたセマンティクスを持つ配列。 x座標（最初に来る）とy座標（次から来る）の配列として指定された2Dポイントは、CBOR 10進数の指数（最初）と仮数（秒）のペアと同様に、レコードの例です分数。
o 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.
o _table_：マップキーのドメインからマップ値のドメインへのマップ。これらはほとんど同じセマンティクスです。それぞれがその特定の言語に翻訳されたテキスト文字列にマップされた言語タグのセットは、テーブルの例です。キードメインは通常、仕様による特定のセットに限定されていませんが、アプリケーションに対して開かれています。たとえば、IPアドレスをメディアアクセス制御（MAC）アドレスにマッピングするテーブルでは、仕様はすべての可能なIPアドレスを予測することを試みません。 JavaScriptなどの言語では、（単純な「オブジェクト」ではなく）「マップ」を使用して、キードメインの汎用性を実現することがよくあります。
o 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.
o _struct_：仕様で定義されているマップキーのドメインから、それぞれのセマンティクスが特定のマップキーにバインドされているマップ値のドメインへのマップ。これは、JSONオブジェクトについて考えるときに多くの人が心に留めていることです。 CBORは、単なるテキスト文字列ではないマップキーを使用する機能を追加します。構造体は、レコードが使用されるのと同様の問題を解決するために使用できます。明示的なマップキーを使用すると、オプション性と拡張性が向上します。
Two important concepts provide the foundation for CDDL:
2つの重要な概念がCDDLの基盤を提供します。
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で4種類の構成すべてを個別に定義する代わりに、配列（ベクトルとレコード）に1種類、マップ（テーブルと構造体）に1種類を定義する代わりに、CDDLには_group_の1種類の構成しかありません（セクション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. その他の重要な概念は、_type_の概念です。 CDDL仕様全体でタイプ（最初の_rule_によって定義されたタイプ）を定義します。これは正式には、この仕様の「インスタンス」として受け入れられるCBORデータ項目のセットです。 CDDLは "uint"（符号なし整数）や "tstr"（テキスト文字列）などのいくつかの基本的な型を事前定義しており、多くの場合、CBORデータ項目の単純な形式表記法を利用しています。 CBORデータ項目として表現できる各値も、それ自体がタイプです（例：「1」）。タイプは他のタイプの_choice_として構築できます。たとえば、「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のセマンティクスの簡潔な要約を示しています。
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グループは、グループ_entries_のリストであり、それぞれが名前/値のペアまたはより複雑なグループ式（順番に名前/値のペアのシーケンスを表す）にすることができます。 CDDLグループは、名前と値のペアの特定のシーケンスに一致し、その他には一致しない文法の生成物です。文法は、解析式文法（PEG）の概念に基づいています（付録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,
}
Figure 1: Using a Group Directly in a Map
図1：マップでグループを直接使用する
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,
)
Figure 2: A Basic Group
図2：基本的なグループ
This separate, named group definition allows us to rephrase Figure 1 as:
この個別の名前付きグループ定義により、図1を次のように言い換えることができます。
person = {
pii
}
Figure 3: Using a Group by Name
図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,
)}
Figure 4: Using a Parenthesized Group in a Map
図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,
}
dog = {
age: int,
name: tstr,
leash-length: float,
}
Figure 5: Maps with Copy/Paste
図5：コピー/貼り付けを使用したマップ
person = {
identity,
employer: tstr,
}
dog = {
identity,
leash-length: float,
}
identity = (
age: int,
name: tstr,
)
Figure 6: Using a Group for Factorization
図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」は名前付きグループであり、他のグループの一部として含めることができます（例のように匿名、またはそれ自体が名前付き）。
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つだけ持つことができます。
The composition syntax is intended to be concise and easy to read:
合成構文は、簡潔で読みやすいものにすることを目的としています。
o The start and end of a group can be marked by "(" and ")".
o グループの開始と終了は、「（」と「）」でマークできます。
o 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.
o グループ内のエントリの定義は次のとおりです：_keytype => valuetype、_（「keytype maps to 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）。このエントリは、名前がキータイプにあり、値が値タイプにある名前/値ペアに一致します。
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.
グループエントリのシーケンスとして定義されたグループは、エントリが一致する順序で連結によって構成される名前/値ペアのシーケンスと一致します。
A group definition can also contain choices between groups; see Section 2.2.2.
グループ定義には、グループ間の選択肢を含めることもできます。セクション2.2.2を参照してください。
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"は "数値表現"を表す）と浮動小数点値（小数部、指数）の区別をCから継承します、または両方が存在する（NR2またはNR3）。したがって、タイプ「1」には浮動小数点数が含まれず、タイプ「1e3」と「1.5」はどちらも浮動小数点数であり、整数は含まれません。
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
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 )
city = (
name: tstr, zip-code: uint
)
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
)
It is not an error if a name is first used with a "/=" or "//=" (there is no need to "create it" with "=").
名前が「/ =」または「// =」で最初に使用されてもエラーではありません（「=」で「作成」する必要はありません）。
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番目の値）です。範囲には、指定された両方の境界を含めることも（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
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は現在、整数（一致する整数値）間または浮動小数点値（一致する浮動小数点値）間の範囲のみを許可します。 1つの型で両方が必要な場合は、2種類の範囲の中から型の選択を（適度に）使用できます。
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
(See also the control operators .lt/.ge and .le/.gt in Section 3.8.6.)
（セクション3.8.6の制御演算子.lt / .geおよび.le / .gtも参照してください。）
Note that the dot is a valid name continuation character in CDDL, so
ドットはCDDLで有効な名前継続文字であるため、
min..max
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.
範囲演算子を分離します。
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:
一部の選択肢は、多くの場合は整数である多数の値から構築されており、仕様ではそれぞれに意味的な名前が付けられています。これらの整数のそれぞれに名前を付けて選択肢に累積するのではなく、CDDLでは、「＆」文字を前に付けることにより、グループから選択肢を構築できます。
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）と同様に、メンバー名はドキュメンタリー値のみを持ちます（特に、その選択から取得した整数を表示するときにツールによって使用される場合があります）。
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]のセクション2を参照）。これがどのように使用されるかは、プレリュード（付録D）から明らかです：ハッシュマーク（ "＃"）の後にオプションでメジャータイプを識別する0から7までの数字が続き、その後にドットと数字を指定することができます。追加情報。この構造は、CBOR（つまり、「any」）でシリアル化できる値のセットを指定します（指定されている場合は指定されたメジャータイプによって、または両方が指定されている場合は追加情報を含む指定されたメジャータイプによって）。メジャータイプ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は、シリアル化バリアントの選択を制限する言語手段を提供していません。これにより、同じ値（の一部）をシリアル化する根本的に異なる方法を使用するJSONでCDDLを使用できるようになります。
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
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.)
（グループをルートとして使用する方法はありません。タイプである必要があります。）
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を参照してください。）
The basic syntax is inspired by ABNF [RFC5234], with the following:
基本的な構文は、ABNF [RFC5234]に着想を得ており、次のようになっています。
o 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.
o ルールは、グループとタイプのどちらを定義する場合でも、名前で定義され、その後に等号「=」が続き、実際の定義は、その定義のそれぞれの構文ルールに従っています。
o 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.
o 名前は、{"A"から "Z"、 "a"から "z"、 "0"から "9"、 "_"、 "-"、 "@"、 "までの任意の文字で構成できます。 。 "、" $ "}、アルファベット文字（" @ "、" _ "、" $ "を含む）で始まり、そのような文字または数字で終わる。
* 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.
* 付録Dにリストされているように、CDDLプレリュードにはいくつかの名前が事前定義されています。
* Rule names (types or groups) do not appear in the actual CBOR encoding, but names used as "barewords" in member keys do.
* ルール名（タイプまたはグループ）は実際のCBORエンコーディングには表示されませんが、メンバーキーで「ベアワード」として使用される名前は表示されます。
o Comments are started by a ";" (semicolon) character and finish at the end of a line (LF or CRLF).
o コメントは「;」で始まります（セミコロン）文字で、行末（LFまたはCRLF）で終了します。
o 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.
o 文字列内を除いて、空白（スペース、改行、コメント）は、読みやすくするために構文要素を区切るために使用されます（識別子、範囲演算子、または連続する数字を区切るためにも使用されます）。それ以外の場合は完全にオプションです。
o Hexadecimal numbers are preceded by "0x" (without quotes) and are case insensitive. Similarly, binary numbers are preceded by "0b".
o 16進数の前には "0x"（引用符なし）が付き、大文字と小文字は区別されません。同様に、2進数の前には「0b」が付きます。
o 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).)
o テキスト文字列は二重引用符「」で囲まれています。[RFC8259]のセクション7で定義されている文字列の規則に従います（ABNFユーザーは、テキストの大文字と小文字を区別しないという概念がCDDLでサポートされていないことに注意してください。文字列;必要に応じて、正規表現を使用できます（セクション3.8.3）。
o 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.
o バイト文字列は単一引用符「 '」で囲まれ、「h」または「b64」が前に付いている場合があります。接頭辞がない場合、文字列はテキスト文字列と同様に解釈されますが、単一引用符はエスケープする必要があり、結果のUTF-8バイトはバイト文字列（メジャータイプ2）としてマークされます。接頭辞が「h」または「b64」の場合、文字列は16進数のペアのシーケンス（base16。[RFC4648]のセクション8を参照）またはbase64（url）文字列（[RFC4648]のセクション4またはセクション5）として解釈されます。 ]）、それぞれ（[RFC7049]のセクション6の診断表記と同様。付録G.2を参照）。文字列内に存在する空白（コメントを含む）は、接頭辞付きの場合は無視されます。
o CDDL uses UTF-8 [RFC3629] for its encoding. Processing of CDDL does not involve Unicode normalization processes.
o CDDLは、エンコーディングにUTF-8 [RFC3629]を使用します。 CDDLの処理には、Unicodeの正規化プロセスは含まれません。
Example:
例：
; This is a comment
person = { g }
g = (
"name": tstr,
age: int, ; "age" is a bareword
)
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.
オプションの_occurrence_インジケーターをグループエントリの前に付けることができます。 （1）「？」のいずれかです。 （オプション）、 "*"（ゼロ以上）、または "+"（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
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:
以前の仕様は、キー「寝室」を複数回使用できるようにCBORが変更されることを意味していません。つまり、データモデルによって課せられた制限により、3行目はほとんど次のようになります。
? bedroom: size,
？ベッドルーム：サイズ、
(Occurrence indicators beyond one are still useful in maps for groups that allow a variety of keys.)
（1つを超えるオカレンスインジケーターは、さまざまなキーを許可するグループのマップで引き続き役立ちます。）
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).
"float32"単精度浮動小数点数として表現可能な数値[IEEE754]（メジャータイプ7、追加情報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"または "bytes"バイト文字列（メジャータイプ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タグに関連付けられている多くのタイプがプレリュードで定義されています。
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,
)
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]
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に関連する値を探すことができます。順序が修正され、デコーダーがキー4に遭遇したが、キーに遭遇しなかった場合3、キー3はより複雑な簿記を行わないと利用できないと結論付けることができます。残念ながら、JSONもCBORもこれをサポートしていないため、CDDLでもこれをサポートする試みは行われていません。
The "struct" usage of maps is similar to the way JSON objects are used in many JSON applications.
マップの「構造体」の使用法は、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.
セクション3.2で指定されているオカレンスインジケーターは、各グループエントリに使用できます。
The following is an example of a record with a structure embedded:
以下は、構造が埋め込まれたレコードの例です。
Geography = [
city : tstr,
gpsCoordinates : GpsCoordinates,
]
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],
}
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」は構造体を参照するときに使用されるデータ型であり、「sample-point」と「samples」は使用されるキーです。これは実際には完全な例です。コロンが後に続く識別子は、二重引用符で囲まれた文字列や数値と同様に、メンバーキー（「裸の」メンバーキーと呼ばれます）のテキスト文字列として直接使用できます。 （他のタイプ、特に複数の値を含むタイプがキーのタイプとして使用される場合、それらの後に二重矢印が続きます。以下を参照してください。）
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],
}
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]]
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,
}
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
}
NameComponents = (
? firstName: tstr,
? familyName: tstr,
)
Figure 7: Personal Data: Example for Extensibility
図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"}
(See Section 3.9 for one way to explicitly identify an extension point.)
（拡張ポイントを明示的に識別する1つの方法については、セクション3.9を参照してください。）
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
Here, the key in each key/value pair has datatype x (defined as int), and the value has datatype y (defined as float).
ここで、各キー/値ペアのキーはデータ型x（intとして定義）を持ち、値はデータ型y（floatとして定義）を持っています。
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
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
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,
}
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.)
（賢明な読者は、Standard Generalized Markup Language（SGML）では「あいまいなコンテンツモデル」と呼ばれ、XMLでは「非決定的コンテンツモデル」と呼ばれていました。この問題は、ここで説明されている問題に関連していますが、ここでの問題具体的には、XMLスキーマ言語が対処する必要のない、マップ内の順序の欠如によって引き起こされます。RELAXNGの「インターリーブ」パターンは、仕様側で明示的に順序の欠如を処理しますが、XMLのインスタンスは常に確定します。注文。）
The extensibility idiom discussed above for structs has one problem:
上記で説明した構造体の拡張性のイディオムには、1つの問題があります。
extensible-map-example = {
? "optional-key" => 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-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
}
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
}
or even shorter, using a bareword for the key:
またはさらに短く、キーにベアワードを使用します：
extensible-map-example = {
? optional-key: int,
* tstr => any
}
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.
タイプは、表現タイプ表記を使用してCBORタグ（メジャータイプ6）を使用できます。＃6.nnn（type）を指定します。ここで、nnnはタグ番号を示す符号なし整数で、「type」はデータ項目のタイプです。タグ付けされています。
For example, the following line from the CDDL prelude (Appendix D) defines "biguint" as a type name for an unsigned bignum N:
たとえば、CDDLプレリュード（付録D）の次の行は、「biguint」を符号なしbignum Nの型名として定義しています。
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
[RFC7049]で定義されたタグは、プレリュードに含まれています。 [RFC7049]の作成後に登録された追加のタグは、必要に応じてCDDL仕様に追加する必要があります。たとえば、バイナリユニバーサルユニーク識別子（UUID）タグは、定義後に仕様で「buuid」として参照できます。
buuid = #6.37(bstr)
In the following example, usage of tag 32 for URIs is optional:
次の例では、URIのタグ32の使用はオプションです。
my_uri = #6.32(tstr) / tstr
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).
「アンラップ」演算子（名前の前にチルダ文字「〜」を付けることで記述）を使用すると、名前に定義されたタイプを1つのレイヤーで削除し、基になるグループ（マップと配列の場合）またはタイプ（タグの場合）を公開できます。 。
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 = [ basic-header-group ]
advanced-header = [
basic-header-group,
field3: bytes,
field4: number, ; as in the tagged type "time"
]
Unwrapping simplifies this to:
アンラップはこれを単純化して次のようにします。
basic-header = [
field1: int,
field2: text,
]
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.)
（後者の例で最初のアンラップ演算子を省略すると、ベーシックヘッダーがアドバンスドヘッダー内の独自の配列にネストされることに注意してください。一方、アンラップされたベーシックヘッダーでは、ベーシックヘッダー内のグループの定義は次のようになります。基本的に、advanced-header内で繰り返され、単一の配列になります。これは、プログラミング言語の継承によって解決されることが多いさまざまなアプリケーションに使用できます。アンラップの効果は、参照された型内のグループまたは型の「スレッド化」として説明することもできます。これは、スレッドのような「〜」文字を示唆しています。）
A _control_ allows relating a _target_ type with a _controller_ type via a _control operator_.
_control_は、_control_を_control operator_を介して_control_に関連付けることを可能にします。
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.)
コントロールタイプの構文は "target .control-operator controller"です。コントロールオペレーターは、ドットが前に付いた特別な識別子です。 （_target_または_controller_は括弧で囲む必要があることに注意してください。）
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の手順に従ってそれらを登録することによって定義できます。
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.
「.size」コントロールは、コントロールタイプによって、ターゲットのサイズをバイト単位で制御します。コントロールはテキストとバイト文字列に対して定義され、文字列のバイト数を直接制御します。また、符号なし整数に対しても定義されています（以下を参照）。図8は、バイト文字列の使用例を示しています。
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
図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ビット、0 ... 16777216と同等
Figure 9: Control for Integer Size in Bytes
図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の値の制限と同様に、このコントロールは表現の制約ではないことに注意してください。より少ないバイトに収まる数値もその形式で表すことができ、非効率的な実装ではより長い形式を使用できます（ただし、[RFC7049]のセクション3.9のルールなど、CDDL以外のいくつかの形式の制約によって制限されている場合を除く）。
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.
バイト文字列の「.bits」コントロールは、ターゲットで、コントロールタイプの番号で番号付けされたビットのみが設定できることを示します。 （ビットは通常の方法でカウントされ、ビット番号「n」は「str」に設定されます。つまり、「（str [n >> 3]＆（1 <<（n＆7）））！= 0 "です。）同様に、符号なし整数 "i"の ".bits"コントロールは、すべての符号なし整数 "n"について、 "（i＆（1 << n））！= 0"の場合、 "n"がコントロールタイプにある必要があることを示します。
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
rwxbits = uint .bits rwx
rwx = &(r: 2, w: 1, x: 0)
Figure 10: Control for What Bits Can Be Set
図10：設定できるビットの制御
The CDDL tool described in Appendix F generates the following ten example instances for "tcpflagbytes":
付録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'
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」でさえあります。 " 同じように。
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スキーマ定義（XSD）正規表現と一致する必要があることを示します。 XSD正規表現は、[W3C.REC-xmlschema-2-20041028]の付録Fで定義されています。
nai = tstr .regexp "[A-Za-z0-9]+@[A-Za-z0-9]+(\\.[A-Za-z0-9]+)+"
Figure 11: Control with an XSD regexp
図11：XSD正規表現による制御
An example matching this regular expression:
この正規表現に一致する例：
"N1@CH57HF.4Znqe0.dYJRN.igjf"
”ん１＠ＣＨ５７ＨＦ。４Ｚんくぇ０。ｄＹＪＲん。いｇｊｆ”
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正規表現は、バイトまたはUnicodeコードポイントの16進表現の通常の\ 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バージョンが対処されているかを識別する必要があります（SHOULD）。
Other surprises for infrequent users of XSD regular expressions may include the following:
XSD正規表現の使用頻度の低いユーザーにとってのその他の驚きには、次のものがあります。
o 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]".
o 大文字と小文字の区別を直接サポートしていません。大文字と小文字の区別はプロトコル設計ではほとんど時代遅れになっていますが、必要な場合があり、「[Cc] [Aa] [Ss] [Ee]」のように手動で表現する必要があります。
o 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.)
o \ wや\ dなどの一般的な文字クラスのサポートは、Unicode文字プロパティに基づいています。これは、ASCIIベースのプロトコルで望まれることではないことがよくあり、そのために驚きにつながる可能性があります。 （\ sと\ Sには従来の意味があり、 "。"は行末文字\ rまたは\ n以外の任意の文字に一致します。）
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互換の正規表現（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]で定義されています。
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).
バイト文字列の「.cbor」コントロールは、バイト文字列がCBORエンコードされたデータ項目を運ぶことを示します。デコードすると、データ項目は右側の引数として指定されたタイプ（次の例ではtype1）と一致します。
"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"
「バイト.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.)
（エンコードされたシーケンスの配列への変換は、たとえば、2つのバイト0x9fと0xffの間でバイト文字列をラップし、ラップされたバイト文字列をCBORエンコードされたデータアイテムとしてデコードすることによって実行できます。）
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。および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.
「.and」コントロールの変形は「.within」コントロールで、これは追加の意図を表します。左側のタイプは右側のタイプのサブセットであることを意味します。
"type1 .within type2"
「タイプ1とタイプ2」
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 /= [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のサブセットであるとは想定されていません。
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
.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は、数値と他のタイプの値の両方に対して定義されます。値の1つが数値型ではない場合、等価性は次のように決定されます。テキスト文字列は、バイトごとに等しい場合は等しい（.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
}
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拡張ポイントは、先頭のドル記号（タイプ）または2つの先頭のドル記号（グループ）でマークされています。ツールは、そのようなタイプまたはグループがまったく定義されていない場合にエラーを発生させないことにより、その規則を尊重します。次に、シンボルは空のタイプの選択肢（グループの選択肢）と見なされます。つまり、選択肢はありません。
tcp-header = {seq: uint, ack: uint, * $$tcp-option}
; later, in a different file
;後で、別のファイルで
$$tcp-option //= (
sack: [+(left: uint, right: uint)]
)
; and, maybe in another file
;そして、おそらく別のファイルに
$$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
}
NameComponents = (
? firstName: tstr,
? familyName: tstr,
)
; The above already works as is. ; But then, we can add later:
;上記はすでにそのまま動作します。 ;ただし、後で追加できます。
$$personaldata-extensions //= (
favorite-salsa: tstr,
)
; and again, somewhere else:
;そして再び、どこか他の場所：
$$personaldata-extensions //= (
shoesize: uint,
)
Figure 12: Personal Data Example: Using Socket/Plug Extensibility
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}
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).
ジェネリックルールを使用する場合、仮パラメーターは、ジェネリックルールのスコープ内で（山括弧も使用して）指定された実際の引数にバインドされます（フォームパラメーター=引数のルールがあるかのように）。
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ツールでのジェネリックのネストにはいくつかの制限があります。）
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には他の言語よりも強く結合する演算子があります。 CDDLにはタイプとグループの両方があり、これらの概念に固有の演算子があるため、これはたとえばABNFよりも複雑になっています。タイプ演算子（タイプ選択の「/」など）はタイプを操作し、グループ演算子（グループ選択の「//」など）はグループを操作します。タイプは単にグループで使用できますが、グループはタイプになるために（配列またはマップとして）括弧で囲む必要があります。したがって、タイプ演算子はグループ演算子よりも自然に近くバインドされます。
For instance, in
たとえば、
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
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.
タイプaまたはbのオプションのメンバー「ab」とタイプcまたはdのメンバー「cd」の間のグループ選択です。オプション性は、2番目の選択肢ではなく、最初の選択肢（ "ab"）に付加されることに注意してください。
Similarly, in
同様に、
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:
group3は、a、b、cの間のタイプ選択の繰り返しです。 aだけを繰り返し可能にする場合は、発生を集中させるためにグループを選択する必要があります。
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
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 |
+----------+-------+---------------------------+------------+
Table 1: Summary of Operator Precedences
表1：演算子の優先順位のまとめ
In this section, we discuss several potential ways to employ CDDL.
このセクションでは、CDDLを使用するいくつかの潜在的な方法について説明します。
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定義に準拠しながらそのようなデータを編集できるツールを構築できます。
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ツールが実装の「コードを書く」ことは意図されていません。
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は制約されたデバイスを念頭に置いて設計されているので、CBORの使用法としては小さなセンサーが考えられます。したがって、興味深い用途は、センサーデータの自動分析です。
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）で定義されています。プロトコルでCBOR構造を定義するためにCDDLを使用する仕様は、これらのガイドラインに従う必要があります。 CDDLを使用してCBOR構造を定義する仕様のセキュリティに関する考慮事項のセクションで検討できる追加のトピックには、次のものがあります。
o Where could the language maybe cause confusion in a way that will enable security issues?
o 言語はどこでセキュリティの問題を可能にする方法で混乱を引き起こす可能性がありますか？
o 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.
o CDDLマッチャーがシステムの実装の一部である場合、システムのセキュリティは、適切な防御策がなければ、CDDL仕様またはCDDL実装の正確さに依存するべきではありません。
o Where the CDDL specification includes extension points, the impact of extensions on the security of the system needs to be carefully considered.
o 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).
CDDL仕様の作成者が心に留めておくことを強くお勧めする、一般的な形式的記述手法に関する関連する観察：CDDLが仕様の複雑さを処理するのを容易にするので、その複雑さは何とかそれほど悪くはありません（たぶん仕様を読みながら複雑な構造を把握する必要がある人間のレベル）。
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 Control Operators」レジストリは、「簡潔なデータ定義言語（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 |
+----------+---------------+
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ポリシーは、[RFC8126]（エキスパートレビューを含む）で定義されている、内部ドットを含まない名前の「仕様が必要です」と、内部ドットを含む名前の「IETFレビュー」です。専門家レビューアは、他の標準開発組織（SDO）が、そのフィールドに固有の制御演算子（たとえば、SDOですでに使用されているバイナリ構文に基づく）を定義することを希望する可能性があることを特に指示されています。レビュープロセスは、そのような事業を促進するよう努めるべきです。
[ISO6093] ISO, "Information processing -- Representation of numerical values in character strings for information interchange", ISO 6093, 1985.
[ISO6093] ISO、「情報処理-情報交換のための文字列内の数値の表現」、ISO 6093、1985。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストの記述に関するガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https://www.rfc-editor.org/ info / rfc3552>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7049] Bormann、C。およびP. Hoffman、「簡潔なバイナリオブジェクト表現（CBOR）」、RFC 7049、DOI 10.17487 / RFC7049、2013年10月、<https://www.rfc-editor.org/info/rfc7049> 。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493]ブレイ、T。、編、「The I-JSON Message Format」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https://www.rfc-editor.org/info/rfc7493>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-xmlschema-2-20041028] Biron、P.およびA. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、World Wide Web Consortium Recommendation REC-xmlschema-2-20041028、2004年10月、<https： //www.w3.org/TR/2004/REC-xmlschema-2-20041028>。
[CDDL-Freezer] Bormann, C., "A feature freezer for the Concise Data Definition Language (CDDL)", Work in Progress, draft-bormann-cbor-cddl-freezer-01, August 2018.
[CDDL-Freezer] Bormann、C.、 "A feature freezer for the Concise Data Definition Language（CDDL）"、Work in Progress、draft-bormann-cbor-cddl-freezer-01、August 2018。
[GRASP] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "A Generic Autonomic Signaling Protocol (GRASP)", Work in Progress, draft-ietf-anima-grasp-15, July 2017.
[GRASP] Bormann、C.、Carpenter、B。、編、およびB. Liu、編、「A Generic Autonomic Signaling Protocol（GRASP）」、Work in Progress、draft-ietf-anima-grasp-15、7月2017。
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2008.
[IEEE754] IEEE、「IEEE Standard for Floating-Point Arithmetic」、IEEE Std 754-2008。
[JCR] Newton, A. and P. Cordell, "A Language for Rules Describing JSON Content", Work in Progress, draft-newton-json-content-rules-09, September 2017.
[JCR]ニュートンA.およびP.コーデル、「JSONコンテンツを記述するルールの言語」、作業中、draft-newton-json-content-rules-09、2017年9月。
[PEG] Ford, B., "Parsing expression grammars: a recognition-based syntactic foundation", Proceedings of the 31st ACM SIGPLAN-SIGACT symposium on Principles of programming languages - POPL '04, DOI 10.1145/964001.964011, January 2004.
[PEG]フォードB.、「構文文法の解析：認識ベースの構文基盤」、プログラミング言語の原則に関する第31回ACM SIGPLAN-SIGACTシンポジウムの議事録-POPL '04、DOI 10.1145 / 964001.964011、2004年1月。
[RELAXNG] ISO/IEC, "Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG", ISO/IEC 19757-2, December 2008.
[RELAXNG] ISO / IEC、「情報技術-ドキュメントスキーマ定義言語（DSDL）-パート2：通常の文法ベースの検証-RELAX NG」、ISO / IEC 19757-2、2008年12月。
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, DOI 10.17487/RFC7071, November 2013, <https://www.rfc-editor.org/info/rfc7071>.
[RFC7071] Borenstein、N。およびM. Kucherawy、「A Reputation for Reputation Interchange」、RFC 7071、DOI 10.17487 / RFC7071、2013年11月、<https://www.rfc-editor.org/info/rfc7071>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M。、編、「The YANG 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers", RFC 8007, DOI 10.17487/RFC8007, December 2016, <https://www.rfc-editor.org/info/rfc8007>.
[RFC8007] Murray、R。およびB. Niven-Jenkins、「Content Delivery Network Interconnection（CDNI）Control Interface / Triggers」、RFC 8007、DOI 10.17487 / RFC8007、2016年12月、<https：//www.rfc-editor。 org / info / rfc8007>。
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152] Schaad、J。、「CBOR Object Signing and Encryption（COSE）」、RFC 8152、DOI 10.17487 / RFC8152、2017年7月、<https://www.rfc-editor.org/info/rfc8152>。
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, <https://www.rfc-editor.org/info/rfc8428>.
[RFC8428]ジェニングス、C。、シェルビー、Z。、アルコ、J。、ケラネン、A。、およびC.ボーマン、「センサー測定リスト（SenML）」、RFC 8428、DOI 10.17487 / RFC8428、2018年8月、<https ：//www.rfc-editor.org/info/rfc8428>。
[YAML] Ben-Kiki, O., Evans, C., and I. Net, "YAML Ain't Markup Language (YAML[TM]) Version 1.2", 3rd Edition, October 2009, <https://yaml.org/spec/1.2/spec.html>.
[YAML] Ben-Kiki、O.、Evans、C。、およびI. Net、「YAML Ai n't Markup Language（YAML [TM]）Version 1.2」、第3版、2009年10月、<https：// yaml。 org / spec / 1.2 / spec.html>。
Appendix A. Parsing Expression Grammars (PEGs)
付録A.式文法（PEG）の解析
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.
1950年代以降、多くの文法表記は、チョムスキーの生成文法システム内の文脈自由文法（CFG）の表記であるバッカスナウルフォーム（BNF）に基づいています。 IETF仕様で広く使用され、CDDLの構文にも影響を与えるAugmented Backus-Naur Form（ABNF）[RFC5234]は、この例です。
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に非常に近く、繰り返しなどの通常の「拡張BNF」機能が追加されています。ただし、BNFが順序付けられていない（対称）選択演算子「|」を使用する場合（誤ってABNFでは「/」と表記されます）、PEGは優先順位付きの選択演算子「/」を提供します。リストされた2つの代替案は左から右の順序でテストされ、最初に成功した一致をロックし、選択肢内の潜在的な一致を無視します（ただし、この選択肢を含む選択肢の代替案をカットとして無効にしません（セクション3.5.4）。 ）するでしょう）。
For example, the ABNF expressions
たとえば、ABNF式
A = "a" "b" / "a" (1)
and
そして
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）では、「a」で始まる入力文字列は最初の選択肢ですでに成功しているため、2番目の選択肢は一致しません。
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では「貪欲」です。つまり、それらは一致するだけの入力を消費します（結果として、PEG表記では「a * a」になります）。またはCDDL構文の "* aa"は何にも一致しません。 "a"に一致するすべての入力は最初の "a *"によってすでに消費されており、2番目の "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コンポーネントを表現するために使用される構文は、ABNFに基づいており、PEGセマンティクスで明白な方法で解釈されます。制御されたプライマリの前にオカレンスインジケーターを表記し、「*」記号の周囲に最小および最大オカレンスの数値を許可するという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 |
+-------+-------+-------------------------------------------+
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.
リテラル表記、および角括弧、中括弧、チルダ、アンパサンド、およびハッシュマークの使用は、CDDLに固有であり、従来のPEG表記とは関係ありません。 PEGのDOT（ "。"）は、修飾されていない "＃"またはそのエイリアス "any"に置き換えられます。また、CDDLは、PEGからの構文述語演算子NOT（ "！"）またはAND（ "＆"）を提供しないため、表現力と複雑さを軽減します。
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]を参照してください。
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).
以下は、ABNF [RFC5234]でのCDDL構文の正式な定義です。 ABNFで定義されているように、以下の引用符で区切られた文字列は大文字と小文字を区別しません（文字列の値と名前はCDDLで大文字と小文字を区別します）。
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
assignt = "=" / "/="
assigng = "=" / "//="
genericparm = "<" S id S *("," S id S ) ">"
genericarg = "<" S type1 S *("," S type1 S ) ">"
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
rangeop = "..." / ".."
ctlop = "." id
ctlop = "。" id
group = 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 ")"
memberkey = type1 S ["^" S] "=>"
/ bareword S ":"
/ value S ":"
bareword = id
optcom = S ["," S]
optcom = S ["、" S]
occur = [uint] "*" [uint]
/ "+"
/ "?"
uint = DIGIT1 *DIGIT
/ "0x" 1*HEXDIG
/ "0b" 1*BINDIG
/ "0"
value = number / text / bytes
値=数値/テキスト/バイト
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
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
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
図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は、接頭辞付きのバイト文字列に含めることができるものの詳細な規則を反映しようとするものではないことに注意してください。
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)
cddl = S 1 *（ルールS）
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.)
1. 最初のルールは、仕様全体のセマンティクスを定義します。したがって、そのルートルールに言語で特別な名前や構文を与える必要はありません（たとえば、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
rule = typename [generic parm] S assignt S type / group name [generic parm] S assigng S grpent
typename = id groupname = id
typename = id groupname = id
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.)
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
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や "icecream"やh'0815 'など）にすることができ、その特定の値（定義された変換なし）のデータ項目のみに一致します。
/ 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タイプS "）"
or be defined in a parenthesized type expression (parentheses may be necessary to override some operator precedence), or
または括弧で囲まれた型式で定義されている（演算子の優先順位をオーバーライドするには括弧が必要な場合があります）、または
/ "{" S group 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
結果のシーケンスがグループ式に一致するように順序付けできるキー/値ペアの有効なCBORマップに一致するマップ式、または
/ "[" S group S "]"
/ "[" Sグループ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タイプ名[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グループS "）" / "＆" Sグループ名[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 ")"
a tagged data item, tagged with the "uint" given and containing the type given as the tagged value, or
指定された「uint」でタグ付けされ、タグ付き値として指定されたタイプを含むタグ付きデータ項目、または
/ "#" 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
メジャータイプのデータアイテム（DIGITによって指定）、オプションでuintによって指定された追加情報に制約されている、または
/ "#" ; any
any data item.
任意のデータ項目。
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)
A group matches any sequence of key/value pairs that matches any of the choices given (again using PEG semantics).
グループは、与えられた選択肢のいずれかに一致するキー/値ペアのシーケンスに一致します（これもPEGセマンティクスを使用）。
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
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.)
グループエントリは、1つの要素の値の部分と一致する必要がある値のタイプで指定できます。また、オプションで、memberkeyが指定されている場合、要素のキー部分と一致する必要があるmemberkeyタイプ。 memberkeyが指定されていない場合、エントリは一致する配列にのみ使用でき、マップには使用できません。 （それが発生インジケーターによってどのように変更されるかについては、以下を参照してください。）
/ [occur S] groupname [genericarg] ; preempted by above
/ [occur S]グループ名[genericarg];上で横取り
A group entry can be built from a named group, or
グループエントリは、名前付きグループから構築できます。
/ [occur S] "(" S group S ")"
/ [Sが発生] "（" SグループS "）"
from a parenthesized group, again with a possible occurrence indicator.
かっこで囲まれたグループから、発生の可能性を示すインジケーターで。
memberkey = type1 S ["^" S] "=>"
/ bareword S ":"
/ value 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.
ベアワードは、単一のテキスト文字列値を持つタイプを書くための代替方法です。上記の構文コンテキストでのみ使用できます。
optcom = S ["," S]
optcom = S ["、" S]
(Optional commas do not influence the matching.)
（オプションのコンマはマッチングに影響しません。）
occur = [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 '..'の例外、およびコメントや行などの構文要素を除いて、プログラミング言語の読者にとって馴染みのある値表記の構文について説明します終了します。
This appendix is normative.
この付録は規範的です。
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
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
false = #7.20
true = #7.21
bool = false / true
nil = #7.22
null = nil
undefined = #7.23
Figure 14: CDDL Prelude
図14：CDDLプレリュード
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.
よくある問題は、プレリュードがタイプ「文字列」を定義しないことです。 CBORにはバイト文字列（プレリュードの「バイト」）とテキスト文字列（「テキスト」）があるため、単に「文字列」と呼ばれる型があいまいになります。
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で表現できるものに制限することにより、JSONでCDDLを使用できます。大まかに言えば、これはバイト文字列、タグ、および「false」、「true」、「null」以外の単純な値を除外することを意味し、次の限定されたプレリュードにつながります。
any = #
uint = #0
nint = #1
int = uint / nint
tstr = #3
text = tstr
number = int / float
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
Figure 15: JSON-Compatible Subset of CDDL Prelude
図15：CDDL PreludeのJSON互換サブセット
(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では直接的な意味はありませんが、[RFC7049]のセクション4で翻訳されたCBORの主要なタイプとして解釈できます）。
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でCDDLを使用する場合、いくつかの細かい点があります。まず、JSONは整数と浮動小数点数を区別しません。数は1種類だけです（たまたま整数になる場合があります）。このコンテキストでは、型を "uint"、 "nint"、または "int"として指定すると、数値が整数であるという述語になります。例として、これは次のJSON番号がすべて「uint」に一致することを意味します。
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自体の数体系は、小数と小数に基づいており、その精度や範囲に制限はありません。実際には、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（ "インターネットJSON"; [RFC7493]を参照）との互換性を維持したいJSONアプリケーションは、図16のように、より制限された範囲で整数型を定義する必要がある場合があります。プレリュード。必要に応じて、CDDL仕様にコピーする必要があります。
ij-uint = 0..9007199254740991
ij-nint = -9007199254740991..-1
ij-int = -9007199254740991..9007199254740991
Figure 16: I-JSON Types for CDDL (Not Part of Prelude)
図16：CDDLのI-JSONタイプ（プレリュードの一部ではない）
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との互換性を維持する必要がなく、「int」（=「uint」/「nint」）でサポートされる64ビットの符号なしおよび負の整数を実際に超える必要があるJSONアプリケーションは、次のように使用できます。標準のプレリュードからの追加のタイプ。タグで表されますが、JSON（ただしI-JSONではない）番号に直接マッピングできます。
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で表すことはできません。
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
図17：CDDLツールの使用法
Install on a system with a modern Ruby via:
最新のRubyがインストールされたシステムに次の方法でインストールします。
gem install cddl
gem install cddl
Figure 18: CDDL Tool Installation
図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].
付随するCBOR診断ツール（上記で自動的にインストールされます）については、<https://github.com/cabo/ cbor-diag>で説明されています。それらは、バイナリCBOR、きれいに印刷された16進形式のバイナリCBOR、CBOR診断表記、JSON、およびYAML [YAML]間の変換に使用できます。
Appendix G. Extended Diagnostic Notation
付録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]のセクション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が作成されてから有用であることが判明した診断表記のいくつかの拡張について説明します。結果をExtended Diagnostic Notation（EDN）と呼びます。
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 '
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]のベースエンコーディングの1つでバイト文字列を表記し、単一引用符で囲みます。base16の場合は> h <、base32の場合は> b32 <、base32hexの場合は> h32 <、base64またはbase64urlの場合は> b64 <で始まります。多くの場合、バイト文字列は、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文字列のエスケープルールは、テキストベースのバイト文字列に同等に適用されます。たとえば、「\」は単一のバックスラッシュを表し、「 '」は単一引用符を表します。空白は文字通り含まれています。つまり、前のセクションはテキストベースのバイト文字列には適用されません。
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''
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言語には馴染みがありますが、注意が必要です。ここでは、1つのカンマで大きな違いが生じます。）
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).
EDNは、JSONの10進数に加えて、通常のC言語表記で16進数、8進数、および2進数を提供します（接頭辞が0oの8進数のみが表示されます）。
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
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/
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]]
(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
付録H.例
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を調べることも興味深いかもしれません。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]は、多少形式化された英語のテキストを使用して、JSONの「レピュトン」構造を定義します。以下は、同じ用語を使用した（やや冗長な）同等の定義ですが、CDDLで表記されています。
reputation-object = {
reputation-context,
reputon-list
}
reputation-context = (
application: text
)
reputon-list = (
reputons: reputon-array
)
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 )
An equivalent, more compact form of this example would be:
この例の同等でよりコンパクトな形式は次のようになります。
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
}
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).
これが、[RFC7071]のセクション6.2.2の非常に多くの単語で覆われた構造をかなり明確に示していることに注意してください。また、この定義により、複数のext-valueが（定義により、異なるメンバー名で）許可されていることが明確になります。 RFC 7071を読み取って、ext-valueの繰り返しを禁止することができます（「特定のreputon要素は複数回出現してはなりません」はあいまいです）。
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"
}
]
}
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].
CとPascal言語、ISOベースのメディアファイル形式で構造を記述するためのMPEGの規約、RELAX NGとそのコンパクトな構文[RELAXNG]、そして特に、JSONコンテンツルール（JCR）に関するAndrew Lee Newtonの初期の提案からインスピレーションを得ました[JCR]のドラフトバージョン4（-04）に記載されています。
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 WGのメンバー、特にAri Keranen、Brian Carpenter、Burt Harris、Jeffrey Yasskin、Jim Hague、Jim Schaad、Joe Hildebrand、Max Pritikin、Michael Richardson、Pete Cordell、Sean Leonardからの非常に役立つフィードバックがたくさんありました、そしてYaron Sheffer。また、Francesca PalombiniとJoeは、WGの作成時に議長を務め、このフィードバックを生成および処理するためのフレームワークを提供し、それ以来Barry LeibaがJoeから引き継いだ。 IESGの処理中に、Chris LonvickとInes Roblesが追加のレビューを提供し、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ツールは、Crosten Bormannによって作成され、Troy HeningerとTom Lordによる以前の研究に基づいて作成されました。
Contributors
貢献者
CDDL was originally conceived by Bert Greevenbosch, who also wrote the original five draft versions of this document.
CDDLは、もともとこのドキュメントの最初の5つのドラフトバージョンを書いたBert Greevenboschによって考案されました。
Authors' Addresses
著者のアドレス
Henk Birkholz Fraunhofer SIT Rheinstrasse 75 Darmstadt 64295 Germany
Henk Birkholz Fraunhofer SIT Rheinstrasse 75ダルムシュタットドイツ
Email: henk.birkholz@sit.fraunhofer.de
Christoph Vigano Universitaet Bremen
クリストフ・ビガーノ大学ブレーメン
Email: christoph.vigano@uni-bremen.de
Carsten Bormann Universitaet Bremen TZI Bibliothekstr. 1 Bremen D-28359 Germany
カルステンボルマンブレーメン大学TZI Bibliothekstr。 1ブレーメンD-28359ドイツ
Phone: +49-421-218-63921
Email: cabo@tzi.org