Internet Engineering Task Force (IETF) M. Koster, Ed.
Request for Comments: 9880 KTC Control AB
Category: Standards Track C. Bormann, Ed.
ISSN: 2070-1721 Universität Bremen TZI
A. Keränen
Ericsson
January 2026
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, and Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed.
セマンティック定義フォーマット (SDF) は、ドメインの専門家が、モノ (ネットワーク上で対話できる物理オブジェクト) を記述するデータおよび対話モデルの作成と保守に使用するフォーマットです。SDF 仕様では、SDF オブジェクト/SDF モノとそれに関連するインタラクション (イベント、アクション、プロパティ) の定義、およびそれらのインタラクションで交換される情報のデータ タイプについて説明します。ツールは、必要に応じて、この形式をデータベース形式や他のシリアル化に変換します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9880.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9880 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Structure of This Document
1.2. Terminology and Conventions
1.2.1. Programming Platform Terms
1.2.2. Conceptual Terms
1.2.3. Specification Language Terms
1.2.4. Conventions
2. Overview
2.1. Example Definition
2.2. Elements of an SDF Model
2.2.1. sdfObject
2.2.2. sdfProperty
2.2.3. sdfAction
2.2.4. sdfEvent
2.2.5. sdfData
2.2.6. sdfThing
2.3. Member Names: Given Names and Quality Names
2.3.1. Given Names and Quality Names
2.3.2. Hierarchical Names
2.3.3. Extensibility of Given Names and Quality Names
3. SDF Structure
3.1. Information Block
3.2. Namespaces Block
3.3. Definitions Block
3.4. Top-Level Affordances and sdfData
4. Names and Namespaces
4.1. Structure
4.2. Contributing Global Names
4.3. Referencing Global Names
4.4. sdfRef
4.4.1. Resolved Models
4.5. sdfRequired
4.6. Common Qualities
4.7. Data Qualities
4.7.1. sdfType
4.7.2. sdfChoice
5. Keywords for Definition Groups
5.1. sdfObject
5.2. sdfProperty
5.3. sdfAction
5.4. sdfEvent
5.5. sdfData
6. High-Level Composition
6.1. Paths in the Model Namespaces
6.2. Modular Composition
6.2.1. Use of the "sdfRef" Keyword to Reuse a Definition
6.3. sdfThing
7. IANA Considerations
7.1. Media Type
7.2. Content-Format
7.3. IETF URN Sub-Namespace for Unit Names
(urn:ietf:params:unit)
7.4. SenML Registry Group
7.5. Registries
7.5.1. SDF Quality Names
7.5.2. SDF Quality Name Prefixes
7.5.3. sdfType Values
7.5.4. SDF Feature Names
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Formal Syntax of SDF
Appendix B. json-schema.org Rendition of SDF Syntax
Appendix C. Data Qualities Inspired by json-schema.org
C.1. type "number", type "integer"
C.2. type "string"
C.3. type "boolean"
C.4. type "array"
C.5. type "object"
C.6. Implementation Notes
Appendix D. Composition Examples
D.1. Outlet Strip Example
D.2. Refrigerator-Freezer Example
Appendix E. Some Changes from Earlier Draft Versions of this
Specification
List of Figures
List of Tables
Acknowledgements
Contributors
Authors' Addresses
The Semantic Definition Format (SDF) is concerned with Things, namely physical objects that are available for interaction over a network. SDF is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, and Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed.
セマンティック定義フォーマット (SDF) は、モノ、つまりネットワーク上で対話可能な物理オブジェクトに関係します。SDF は、ドメインの専門家がモノを記述するデータと対話モデルの作成と保守に使用する形式です。SDF 仕様では、SDF オブジェクト/SDF モノとそれに関連するインタラクション (イベント、アクション、プロパティ) の定義、およびそれらのインタラクションで交換される情報のデータ タイプについて説明します。ツールは、必要に応じて、この形式をデータベース形式や他のシリアル化に変換します。
SDF is designed to be an extensible format. The present document constitutes the base specification for SDF, "base SDF" for short. In addition, SDF extensions can be defined, some of which may make use of extension points specifically defined for this in base SDF. One area for such extensions would be refinements of SDF's abstract interaction models into protocol bindings for specific ecosystems (e.g., [SDF-MAPPING]). For the use of certain other extensions, it may be necessary to indicate in the SDF document using them that a specific extension is in effect; see Section 3.1 for details of the features quality that can be used for such indications. With extension points and feature indications available, base SDF does not define a "version" concept for the SDF format itself (as opposed to version indications within SDF documents indicating their own evolution; see Section 3.1).
SDF は拡張可能な形式になるように設計されています。この文書は、SDF の基本仕様、略して「ベース SDF」を構成します。さらに、SDF 拡張を定義することができ、その一部は基本 SDF でこのために特別に定義された拡張ポイントを利用する場合があります。このような拡張の領域の 1 つは、SDF の抽象対話モデルを改良して、特定のエコシステム用のプロトコル バインディングにすることです (例: [SDF-MAPPING])。他の特定の拡張機能を使用する場合は、それらを使用する SDF ドキュメント内で特定の拡張機能が有効であることを示す必要がある場合があります。このような指標に使用できる機能品質の詳細については、セクション 3.1 を参照してください。拡張ポイントと機能表示が利用できるため、基本 SDF は SDF 形式自体の「バージョン」概念を定義しません (SDF ドキュメント内のバージョン表示が独自の進化を示すのとは対照的です。セクション 3.1 を参照)。
After introductory material and an overview (Section 2) over the elements of the model and the different kinds of names used, Section 3 introduces the main components of an SDF model. Section 4 revisits names and structures them into namespaces. Section 5 discusses the inner structure of the Objects defined by SDF, the sdfObjects, in further detail. Section 6 discusses how SDF supports composition. Conventional Sections (IANA Considerations, Security Considerations, Normative References, and Informative References) follow. The normative Appendix A defines the syntax of SDF in terms of its JSON structures, employing the Concise Data Definition Language (CDDL) [RFC8610]. This is followed by the informative Appendix B, a rendition of the SDF syntax in a "JSON Schema" format as they are defined by json-schema.org (collectively called JSO). The normative Appendix C defines certain terms ("data qualities") used at the SDF data model level that were inspired by JSO. The informative Appendix D provides a few examples for the use of composition in SDF. Finally, Appendix E provides some historical information that can be useful in upgrading earlier, pre-standard SDF models and implementations to base SDF.
モデルの要素と使用されるさまざまな種類の名前に関する入門資料と概要 (セクション 2) の後、セクション 3 では SDF モデルの主要コンポーネントを紹介します。セクション 4 では、名前を再検討し、それらを名前空間に構造化します。セクション 5 では、SDF によって定義されるオブジェクト (sdfObject) の内部構造についてさらに詳しく説明します。セクション 6 では、SDF が合成をどのようにサポートするかについて説明します。従来のセクション (IANA の考慮事項、セキュリティの考慮事項、規範的な参照、および有益な参照) が続きます。規範的な付録 A は、簡潔データ定義言語 (CDDL) [RFC8610] を使用して、JSON 構造に関して SDF の構文を定義します。この後には、json-schema.org (総称して JSO と呼ばれます) で定義されている「JSON スキーマ」形式での SDF 構文の表現である有益な付録 B が続きます。規範的な付録 C は、JSO からインスピレーションを得た SDF データ モデル レベルで使用される特定の用語 (「データ品質」) を定義します。有益な付録 D では、SDF での合成の使用例がいくつか提供されています。最後に、付録 E では、以前の標準以前の SDF モデルおよび実装を基本 SDF にアップグレードする際に役立ついくつかの履歴情報を提供します。
Terms introduced in this section are capitalized when used in this section. To maintain readability, capitalization is only used when needed where they are used in the body of this document.
このセクションで紹介される用語は、このセクションで使用される場合は大文字で表記されます。読みやすさを維持するために、この文書の本文で大文字が使用されている場合は、必要な場合にのみ大文字が使用されます。
The following definitions mention terms that are used with specific meanings in various programming platforms, but often have an independent definition for this document, which can be found further below in this section.
次の定義では、さまざまなプログラミング プラットフォームで特定の意味で使用される用語について説明しますが、多くの場合、このドキュメントでは独立した定義があり、このセクションの以下で説明します。
Element:
要素：
A generic term used here in its English sense. Exceptionally, in Appendix C, the term is used explicitly in accordance with its meaning in the JSON ecosystem, i.e., the elements of JSON arrays.
ここでは英語の意味で使用される一般的な用語。例外的に、付録 C では、この用語は JSON エコシステム、つまり JSON 配列の要素における意味に従って明示的に使用されます。
Entry:
エントリ：
A key-value pair in a map. (In JSON maps, sometimes also called "member".)
マップ内のキーと値のペア。(JSON マップでは、「メンバー」とも呼ばれます。)
Map:
Map:
A collection of entries (key-value pairs) where there are no two entries with equivalent keys. (Also known as associative array, dictionary, or symbol table.)
同等のキーを持つ 2 つのエントリが存在しないエントリ (キーと値のペア) のコレクション。(連想配列、辞書、シンボル テーブルとも呼ばれます。)
Object:
物体：
An otherwise very generic term that JavaScript (and thus JSON) uses for the kind of maps that were part of the original languages from the outset. In this document, Object is used exclusively in its general English meaning or as the colloquial shorthand for sdfObject, even if the type name "object" is imported with JSON-related semantics from a data definition language.
JavaScript (したがって JSON) が、最初から元の言語の一部であった種類のマップに対して使用する非常に一般的な用語。このドキュメントでは、型名 "object" がデータ定義言語から JSON 関連のセマンティクスを使用してインポートされた場合でも、Object は一般的な英語の意味でのみ、または sdfObject の口語的な短縮形としてのみ使用されます。
Property:
財産：
Certain environments use the term "property" for a JSON concept that JSON calls "member" and is called "entry" here, or sometimes just for the map key of these. In this document, the term Property is specifically reserved for a certain kind of Affordance, even if the map key "properties" is imported with JSON-related semantics from a data definition language.
特定の環境では、JSON では「メンバー」と呼ばれる JSON の概念に対して「プロパティ」という用語が使用され、ここでは「エントリ」と呼ばれます。また、場合によってはこれらのマップ キーに対してのみ使用されます。このドキュメントでは、マップ キーの「プロパティ」がデータ定義言語から JSON 関連のセマンティクスを使用してインポートされる場合でも、プロパティという用語は特定の種類のアフォーダンスのために特別に予約されています。
Byte:
バイト：
This document uses the term "byte" in its now-customary sense as a synonym for "octet".
この文書では、「バイト」という用語を、現在慣用されている意味で「オクテット」の同義語として使用しています。
Thing:
もの：
A physical item that is also available for interaction over a network.
ネットワーク経由でも対話できる物理的なアイテム。
Element:
要素：
A part or an aspect of something abstract; i.e., the term is used here in its usual English definition.
抽象的なものの一部または側面。つまり、この用語はここでは通常の英語の定義で使用されています。
Affordance:
アフォーダンス:
An element of an interface offered for interaction. Such an element becomes an Affordance when information is available (directly or indirectly) that indicates how it can or should be used. In the present document, the term is used for the digital (network-directed) interfaces of a Thing only; as it is a physical object as well, the Thing might also have physical affordances such as buttons, dials, and displays. The specification language offers certain ways to create sets of related Affordances and combine them into "Groupings" (see below).
インタラクションのために提供されるインターフェースの要素。このような要素は、その要素をどのように使用できるか、または使用する必要があるかを示す情報が (直接的または間接的に) 利用可能になると、アフォーダンスになります。このドキュメントでは、この用語はモノのデジタル (ネットワーク指向) インターフェイスに対してのみ使用されます。物体も物理的なオブジェクトであるため、ボタン、ダイヤル、ディスプレイなどの物理的なアフォーダンスも備えている場合があります。仕様言語では、関連するアフォーダンスのセットを作成し、それらを「グループ化」に結合するための特定の方法が提供されています (下記を参照)。
Property:
財産：
An Affordance that can potentially be used to read, write, and/or observe state (current/stored information) on a Grouping.
グループ化の状態 (現在/保存されている情報) の読み取り、書き込み、および/または観察に使用できる可能性があるアフォーダンス。
Action:
アクション：
An Affordance that can potentially be used to perform a named operation on a Grouping.
グループに対して名前付き操作を実行するために使用できる可能性があるアフォーダンス。
Event:
イベント：
An Affordance that can potentially be used to obtain information about what happened to a Grouping.
グループ化に何が起こったのかに関する情報を取得するために使用できる可能性があるアフォーダンス。
SDF Document:
自衛隊文書:
Container for SDF Definitions, together with data about the SDF Document itself (information block). Represented as a JSON text representing a single JSON map, which is built from nested maps.
SDF 定義のコンテナと、SDF ドキュメント自体に関するデータ (情報ブロック)。ネストされたマップから構築された単一の JSON マップを表す JSON テキストとして表されます。
SDF Model:
自衛隊モデル:
Definitions and declarations that model the digital interaction opportunities offered by one or more kinds of Things, represented by Groupings (sdfObjects and sdfThings). An SDF Model can be fully contained in a single SDF Document, or it can be built from an SDF Document that references definitions and declarations from additional SDF documents. The term SDF Specification can be used when the distinction between the distribution into individual SDF Documents and the abstract nature of the SDF Model is not of interest.
グループ化 (sdfObjects および sdfThings) によって表される、1 つ以上の種類のモノによって提供されるデジタル インタラクションの機会をモデル化する定義と宣言。SDF モデルは、単一の SDF ドキュメントに完全に含めることも、追加の SDF ドキュメントの定義と宣言を参照する SDF ドキュメントから構築することもできます。SDF 仕様という用語は、個々の SDF ドキュメントへの配布と SDF モデルの抽象的な性質との区別が重要でない場合に使用できます。
Block:
ブロック：
One or more entries in a JSON map that is part of an SDF specification. These entries can be described as a Block to emphasize that they serve a specific function together.
SDF 仕様の一部である JSON マップ内の 1 つ以上のエントリ。これらのエントリは、特定の機能を一緒に提供することを強調するために、ブロックとして記述することができます。
Group:
グループ：
An entry in the top-level JSON map that represents the SDF document. Groups also can be used in certain nested definitions. A group has a Class Name Keyword as its key and a map of named definition entries (Definition Group) as a value.
SDF ドキュメントを表すトップレベル JSON マップ内のエントリ。グループは、特定のネストされた定義でも使用できます。グループは、キーとしてクラス名キーワードを持ち、値として名前付き定義エントリのマップ (定義グループ) を持ちます。
Class Name Keyword:
クラス名のキーワード:
One of sdfThing, sdfObject, sdfProperty, sdfAction, sdfEvent, or sdfData. The Classes for these type keywords are capitalized and prefixed with sdf.
sdfThing、sdfObject、sdfProperty、sdfAction、sdfEvent、または sdfData のいずれか。これらのタイプのキーワードのクラスは大文字で始まり、sdf という接頭辞が付けられます。
Class:
クラス：
Abstract term for the information that is contained in groups identified by a Class Name Keyword.
クラス名キーワードによって識別されるグループに含まれる情報を表す抽象用語。
Quality:
品質：
A metadata item in a definition or declaration that says something about that definition or declaration. A quality is represented in SDF as an entry in a JSON map (JSON object) that serves as a definition or declaration. (The term "Quality" is used because another popular term, "Property", already has a different meaning.)
定義または宣言内の、その定義または宣言について何かを示すメタデータ項目。品質は、定義または宣言として機能する JSON マップ (JSON オブジェクト) のエントリとして SDF で表されます。(「品質」という用語が使用されているのは、「プロパティ」という別の一般的な用語がすでに別の意味を持っているためです。)
Definition:
意味：
An entry in a Definition Group. The entry creates a new semantic term for use in SDF models and associates it with a set of qualities. Unless the Class Name Keyword of the Group also makes it a Declaration (see Section 3.3), a definition just defines a term and it does not create a component item within the enclosing definition.
定義グループ内のエントリ。このエントリは、SDF モデルで使用するための新しい意味用語を作成し、それを一連の品質に関連付けます。グループのクラス名キーワードによって宣言にもならない限り (セクション 3.3 を参照)、定義は用語を定義するだけであり、それを囲む定義内にコンポーネント項目は作成されません。
Declaration:
宣言：
A definition within an enclosing definition that is intended to create a component item within that enclosing definition. Every declaration can also be used as a definition for reference elsewhere.
囲んでいる定義内でコンポーネント項目を作成することを目的とした、囲んでいる定義内の定義。すべての宣言は、他の場所で参照するための定義として使用することもできます。
Grouping:
グループ化:
An sdfThing or sdfObject, i.e., (directly or indirectly) a description for a combination of Affordances.
sdfThing または sdfObject、つまり、(直接的または間接的に) アフォーダンスの組み合わせの説明。
Object, sdfObject:
オブジェクト、sdfオブジェクト:
A Grouping where the declarations that it contains are for Affordances only (Property, Action, and Event declarations). It serves as the main "atom" of reusable semantics for model construction, representing the interaction model for a Thing that is simple enough to not require a nested structure. Therefore, sdfObjects are similar to sdfThings, but do not allow nesting, i.e., they cannot contain other Groupings (sdfObjects or sdfThings).
含まれる宣言がアフォーダンスのみ (プロパティ、アクション、およびイベントの宣言) であるグループ。これは、モデル構築のための再利用可能なセマンティクスの主要な「アトム」として機能し、入れ子構造を必要としないほど単純なモノの対話モデルを表します。したがって、sdfObject は sdfThings に似ていますが、ネストは許可されていません。つまり、他のグループ (sdfObject または sdfThings) を含めることはできません。
sdfThing:
sdfThing:
A Grouping that can contain nested Groupings (sdfThings and sdfObjects). Like sdfObject, it can also contain Affordance declarations (Property, Action, and Event declarations). (Note that "Thing" has a different meaning from sdfThing and is therefore not available as a colloquial shorthand of sdfThing.)
ネストされたグループ (sdfThings および sdfObject) を含めることができるグループ。sdfObject と同様に、アフォーダンス宣言 (プロパティ、アクション、イベント宣言) を含めることもできます。(「Thing」は sdfThing とは異なる意味を持っているため、sdfThing の口語的な短縮表現としては使用できないことに注意してください。)
Augmentation Mechanism:
拡張メカニズム:
A companion document to a base SDF Model that provides additional information ("augments" the base specification). The information may be for use in a specific ecosystem or with a specific protocol ("Protocol Binding"). No specific Augmentation Mechanisms are defined in base SDF. A simple mechanism for such augmentations has been discussed as a "mapping file" [SDF-MAPPING].
追加情報を提供する (基本仕様を「拡張」する)、基本 SDF モデルの付属ドキュメント。情報は、特定のエコシステムまたは特定のプロトコル (「プロトコル バインディング」) で使用される場合があります。Base SDF では特定の拡張メカニズムは定義されていません。このような拡張のための単純なメカニズムは、「マッピング ファイル」[SDF-MAPPING] として議論されています。
Protocol Binding:
プロトコルバインディング:
A companion document to an SDF Model that defines how to map the abstract concepts in the model into the protocols that are in use in a specific ecosystem. The Protocol Binding might supply URL components, numeric IDs, and similar details. Protocol Bindings are one case of an Augmentation Mechanism.
SDF モデルの付属文書。モデル内の抽象概念を特定のエコシステムで使用されているプロトコルにマッピングする方法を定義します。プロトコル バインディングは、URL コンポーネント、数値 ID、および同様の詳細を提供する場合があります。プロトコル バインディングは、拡張メカニズムの一例です。
Regular expressions that are used in the text as a "pattern" for some string are interpreted as per [RFC9485]. (Note that a form of regular expressions is also used as values of the quality pattern; see Appendix C.2.)
テキスト内で何らかの文字列の「パターン」として使用される正規表現は、[RFC9485] に従って解釈されます。(正規表現の形式も品質パターンの値として使用されることに注意してください。付録 C.2 を参照してください。)
The term "URI" in this document always refers to "full" URIs ("URI" in Section 3 of RFC 3986 [STD66]), never to relative URI references ("relative-ref" in Section 4.1 of RFC 3986 [STD66]), so the term "URI" does _NOT_ serve as the colloquial abbreviation of "URI-Reference" it is often used for. Therefore, the "reference resolution" process defined in Section 5 of RFC 3986 [STD66] is _NOT_ used in this specification. Where necessary, full URIs are assembled out of substrings by simple concatenation, e.g., when CURIEs are expanded (Section 4.3) or when a global name is formed out of a namespace absolute-URI (Section 5 of RFC 3986 [STD66]) and a fragment identifier part (Section 4.1). Also note that URIs are not only used to construct the SDF models, they are also the _subject_ of SDF models where they are used as data in actual interactions (and could even be represented as relative references there); these two usages are entirely separate.
この文書の「URI」という用語は常に「完全な」URI (RFC 3986 [STD66] のセクション 3 の「URI」) を指し、相対 URI 参照 (RFC 3986 [STD66] のセクション 4.1 の「relative-ref」) を指すことは決してありません。そのため、「URI」という用語は、よく使用される「URI 参照」の口語的な略語としての役割を_NOT_ しません。したがって、RFC 3986 [STD66] のセクション 5 で定義されている「参照解像度」プロセスは、この仕様では使用されません。必要に応じて、完全な URI は単純な連結によって部分文字列から組み立てられます。たとえば、CURIE が展開されるとき (セクション 4.3)、またはグローバル名が名前空間の絶対 URI (RFC 3986 [STD66] のセクション 5) とフラグメント識別子部分 (セクション 4.1) から形成されるときです。また、URI は SDF モデルの構築に使用されるだけでなく、実際の対話でデータとして使用される SDF モデルの「主題」でもあることにも注意してください (そこでは相対参照として表すこともできます)。これら 2 つの使用法はまったく別のものです。
The singular form is chosen as the preferred one for the keywords defined in this specification.
単数形は、この仕様で定義されるキーワードの優先形式として選択されます。
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] で説明されているように解釈されます。
The overview starts with an example for the SDF definition of a simple sdfObject called "Switch" (Figure 1).
概要は、「Switch」と呼ばれる単純な sdfObject の SDF 定義の例から始まります (図 1)。
{
"info": {
"title": "Example document for SDF (Semantic Definition Format)",
"version": "2019-04-24",
"copyright": "Copyright 2019 Example Corp. All rights reserved.",
"license": "https://example.com/license"
},
"namespace": {
"cap": "https://example.com/capability/cap"
},
"defaultNamespace": "cap",
"sdfObject": {
"Switch": {
"sdfProperty": {
"value": {
"description":
"The state of the switch; false for off and true for on.",
"type": "boolean"
}
},
"sdfAction": {
"on": {
"description":
"Turn the switch on; equivalent to setting value to true."
},
"off": {
"description":
"Turn the switch off; equivalent to setting value to false."
},
"toggle": {
"description":
"Toggle the switch; equivalent to setting value to its complement."
}
}
}
}
}
Figure 1: A Simple Example of an SDF Document
図 1: SDF 文書の簡単な例
This is a model of a switch. The state value declared in the sdfProperty group, represented by a Boolean, will be true for "on" and will be false for "off". The Actions on or off declared in the sdfAction group are redundant with setting the value and are in the example to illustrate that there are often different ways of achieving the same effect. The action toggle will invert the value of the sdfProperty value so that 2-way switches can be created; having such action will avoid the need for retrieving the current value first and then applying/setting the inverted value.
こちらはスイッチの模型です。sdfProperty グループで宣言された状態値はブール値で表され、「オン」の場合は true、「オフ」の場合は false になります。sdfAction グループで宣言されたアクションのオンまたはオフは、値の設定と重複しており、同じ効果を達成するさまざまな方法があることを示すためにこの例に含まれています。アクションの切り替えにより sdfProperty 値の値が反転され、双方向スイッチを作成できるようになります。このようなアクションがあると、最初に現在の値を取得してから、反転した値を適用/設定する必要がなくなります。
The sdfObject group lists the affordances of Things modeled by this sdfObject. The sdfProperty group lists the Property affordances described by the model; these represent various perspectives on the state of the sdfObject. Properties can have additional qualities to describe the state more precisely. Properties can be annotated to be read, write, or read/write; how this is actually done by the underlying transfer protocols is not described in the SDF model but left to companion protocol bindings. Properties are often used with RESTful paradigms [REST-IOT] describing state. The sdfAction group is the mechanism to describe other interactions in terms of their names, input, and output data (no data are used in the example), as in a POST method in REST or in a remote procedure call. The example toggle is an Action that changes the state based on the current state of the Property named value. (The third type of affordance is Events, which are not described in this example.)
sdfObject グループには、この sdfObject によってモデル化されたモノのアフォーダンスがリストされます。sdfProperty グループには、モデルによって記述されたプロパティ アフォーダンスがリストされます。これらは、sdfObject の状態に関するさまざまな視点を表します。プロパティには、状態をより正確に記述するための追加の品質を含めることができます。プロパティには、読み取り、書き込み、または読み取り/書き込みの注釈を付けることができます。これが基礎となる転送プロトコルによって実際にどのように行われるかは、SDF モデルには記述されておらず、コンパニオン プロトコル バインディングに委ねられています。プロパティは、状態を記述する RESTful パラダイム [REST-IOT] でよく使用されます。sdfAction グループは、REST の POST メソッドやリモート プロシージャ コールのように、名前、入力データ、および出力データ (この例ではデータは使用されていません) に関して他の対話を記述するメカニズムです。トグルの例は、値という名前のプロパティの現在の状態に基づいて状態を変更するアクションです。(3 番目のタイプのアフォーダンスはイベントですが、この例では説明されていません。)
In the JSON representation, the info group is an exception in that this group's map has keys taken from the SDF vocabulary. All other groups (such as namespace and sdfObject) have maps with keys that are freely defined by the model writer (Switch, value, on, etc.). These map keys are therefore called _Given Names_. The groups made up of entries with Given Names as keys usually use the named<> production in the formal syntax of SDF (Appendix A). Where the values of these entries are maps, these again use SDF vocabulary keys, and so on, generally alternating in further nesting. The SDF-defined vocabulary items used in the hierarchy of such groups are often, but not always, called _Quality Names_ or _qualities_. See Section 2.3 for more information about naming in SDF.
JSON 表現では、情報グループは例外であり、このグループのマップには SDF 語彙から取得されたキーが含まれています。他のすべてのグループ (名前空間や sdfObject など) には、モデル作成者によって自由に定義されたキー (スイッチ、値、オンなど) を含むマップがあります。したがって、これらのマップ キーは _Given Names_ と呼ばれます。キーとして指定された名前を持つエントリで構成されるグループは、通常、SDF の正式な構文のnamed<> プロダクションを使用します (付録 A)。これらのエントリの値がマップである場合、これらは再び SDF ボキャブラリ キーなどを使用し、通常はさらに入れ子になって交互に使用されます。このようなグループの階層で使用される SDF 定義の語彙項目は、常にではありませんが、しばしば「品質名」または「品質」と呼ばれます。SDF での名前付けの詳細については、セクション 2.3 を参照してください。
The SDF language uses six predefined Class Name Keywords for modeling connected Things, which are illustrated in Figure 2 (limited rendition in the plaintext form of this document, please use typographic forms for full information).
SDF 言語は、接続されたモノをモデル化するために 6 つの事前定義されたクラス名キーワードを使用します。これを図 2 に示します (この文書の平文形式での表現は限られています。完全な情報については活版印刷形式を使用してください)。
,--------.
|sdfThing|------.
,--------------|--------| | hasThing
| |--------|<-----'
| `--------'
| | | |
| hasObject | | \
| v | \
| ,---------. | \
| |sdfObject| | \
| |---------| | \
,--------|---------|---------.
| `---------' | |
has|Property | hasAction | hasEvent
v v v v
,-----------. ,---------. ,--------.
|sdfProperty| |sdfAction| |sdfEvent|
|-----------| |---------| |--------|
|-----------| |---------| |--------|
`-----------' `---------' `--------'
| hasInput| |hasOutput |
| Data| |Data |
| v v |
| ,-------. |
| isInst |sdfData| hasOutp |
`----------->|-------|<----------'
anceOf |-------| utData
`-------'
Figure 2: Main Classes Used in SDF Models
図 2: SDF モデルで使用される主なクラス
The six main Class Name Keywords are discussed below.
6 つの主要なクラス名キーワードについては、以下で説明します。
sdfObjects, the items listed in an sdfObject definition group, are the main "atom" of reusable semantics for model construction. The concept aligns in scope with common definition items from many IoT modeling systems, e.g., ZigBee Clusters [ZCL], OMA SpecWorks LwM2M Objects [OMA], OCF Resource Types [OCF], and W3C Web of Things Thing Descriptions [WoT].
sdfObject は、sdfObject 定義グループにリストされている項目であり、モデル構築のための再利用可能なセマンティクスの主要な「アトム」です。この概念は、ZigBee Clusters [ZCL]、OMA SpecWorks LwM2M Objects [OMA]、OCF Resource Types [OCF]、W3C Web of Things Thing description [WoT] など、多くの IoT モデリング システムの共通定義項目と範囲が一致しています。
An sdfObject definition contains a set of sdfProperty, sdfAction, and sdfEvent definitions that describe the interaction affordances associated with some scope of functionality.
sdfObject 定義には、一部の機能範囲に関連付けられたインタラクション アフォーダンスを記述する sdfProperty、sdfAction、および sdfEvent 定義のセットが含まれています。
For the granularity of definition, sdfObject definitions are meant to be kept narrow enough in scope to enable broad reuse and interoperability. For example, defining a light bulb using separate sdfObject definitions for on/off control, dimming, and color control affordances will enable interoperable functionality to be configured for diverse product types. An sdfObject definition for a common on/ off control may be used to control many different kinds of Things that require on/off control.
定義の粒度を高めるため、sdfObject 定義は、広範な再利用と相互運用性を可能にするために、範囲を十分に狭くする必要があります。たとえば、オン/オフ制御、調光、色制御アフォーダンスに個別の sdfObject 定義を使用して電球を定義すると、さまざまな製品タイプに対して相互運用可能な機能を構成できるようになります。共通のオン/オフ制御の sdfObject 定義は、オン/オフ制御を必要とするさまざまな種類のモノを制御するために使用できます。
The presence of one or both of the optional qualities "minItems" and "maxItems" defines the sdfObject as an array, i.e., all the affordances defined for the sdfObject exist a number of times, indexed by a number constrained to be between minItems and maxItems, inclusive, if given. (Note: Setting "minItems" to zero and leaving out "maxItems" puts the minimum constraints on that array.)
オプションの品質「minItems」と「maxItems」の一方または両方が存在すると、sdfObject が配列として定義されます。つまり、sdfObject に定義されたすべてのアフォーダンスは、minItems と maxItems (指定されている場合) の間に制限される数値によってインデックスが付けられ、何度も存在します。(注: 「minItems」をゼロに設定し、「maxItems」を省略すると、その配列に最小制約が設定されます。)
sdfProperty is used to model elements of state within Things modeled by the enclosing grouping.
sdfProperty は、囲むグループによってモデル化されたモノ内の状態の要素をモデル化するために使用されます。
A named definition entry in an sdfProperty may be associated with some protocol affordance to enable the application to obtain the state variable and, optionally, modify the state variable. Additionally, some protocols provide for in-time reporting of state changes. (These three aspects are described by the qualities readable, writable, and observable defined for an sdfProperty.)
sdfProperty 内の名前付き定義エントリは、アプリケーションが状態変数を取得し、必要に応じて状態変数を変更できるようにするために、何らかのプロトコル アフォーダンスに関連付けることができます。さらに、一部のプロトコルは、状態変化の即時レポートを提供します。(これら 3 つの側面は、sdfProperty に対して定義された読み取り可能、書き込み可能、および監視可能という品質によって説明されます。)
Definitions in sdfProperty groups look like the definitions in sdfData groups. However, they actually declare that a Property with the given qualities potentially is present in the containing sdfObject.
sdfProperty グループの定義は、sdfData グループの定義と似ています。ただし、実際には、指定された品質を持つプロパティが、それを含む sdfObject 内に存在する可能性があると宣言されています。
For definitions in sdfProperty and sdfData, SDF provides qualities that can constrain the structure and values of data allowed in the interactions modeled by them. It also provides qualities that associate semantics to this data, such as engineering units and unit scaling information.
sdfProperty および sdfData の定義については、SDF は、モデル化された相互作用で許可されるデータの構造と値を制約できる品質を提供します。また、工学単位や単位スケーリング情報など、セマンティクスをこのデータに関連付ける品質も提供します。
For the data definition within sdfProperty or sdfData, SDF borrows some vocabulary proposed for drafts 4 [JSO4] [JSO4V] and 7 [JSO7] [JSO7V] of the json-schema.org "JSON Schema" format (collectively called JSO here), enhanced by qualities that are specific to SDF. Details about the JSO-inspired vocabulary are in Appendix C. For base SDF, data are constrained to be of simple types (number, string, boolean), JSON maps composed of named data, and arrays of these types. Syntax extension points are provided that can be used to provide richer types in a future extension of this specification (possibly more of which can be borrowed from json-schema.org).
sdfProperty または sdfData 内のデータ定義について、SDF は、json-schema.org の「JSON スキーマ」形式 (ここでは総称して JSO と呼びます) のドラフト 4 [JSO4] [JSO4V] および 7 [JSO7] [JSO7V] で提案されているいくつかの語彙を借用しており、SDF に固有の品質によって強化されています。JSO からインスピレーションを得たボキャブラリーの詳細については、付録 C を参照してください。ベース SDF の場合、データは単純なタイプ (数値、文字列、ブール値)、名前付きデータで構成される JSON マップ、およびこれらのタイプの配列であるように制約されます。この仕様の将来の拡張でより豊富な型を提供するために使用できる構文拡張ポイントが提供されています (おそらく、json-schema.org からさらに多くの型を借用できます)。
Note that sdfProperty definitions (and sdfData definitions in general) are not intended to constrain the formats of data used for communication over network interfaces. Where needed, data definitions for payloads of protocol messages are expected to be part of the protocol binding.
sdfProperty 定義 (および一般的な sdfData 定義) は、ネットワーク インターフェイスを介した通信に使用されるデータの形式を制限することを目的としたものではないことに注意してください。必要に応じて、プロトコル メッセージのペイロードのデータ定義はプロトコル バインディングの一部であることが期待されます。
The sdfAction group contains declarations of Actions, which model affordances that, when triggered, have an effect that can go beyond just reading, updating, or observing Thing state. Actions often result in some outward physical effect (which, itself, cannot be modeled in SDF). From a programmer's perspective, they might be considered to be roughly analogous to method calls.
sdfAction グループには、アクションの宣言が含まれています。これは、トリガーされると、モノの状態の読み取り、更新、または観察を超える効果をもたらすアフォーダンスをモデル化します。アクションは、多くの場合、外部への物理的な影響をもたらします (それ自体は SDF でモデル化できません)。プログラマの観点からは、これらはメソッド呼び出しにほぼ似ていると考えることができます。
Actions may have data parameters; these are each modeled as a single item of input data and output data. Where multiple parameters need to be modeled, an "object" type can be used to combine these parameters into one; for an example, see Figure 6 in Appendix C.5.
アクションにはデータパラメータが含まれる場合があります。これらはそれぞれ、入力データと出力データの単一項目としてモデル化されます。複数のパラメータをモデル化する必要がある場合、「オブジェクト」タイプを使用してこれらのパラメータを 1 つに結合できます。例については、付録 C.5 の図 6 を参照してください。
Actions may be long-running, that is to say that the effects may not take place immediately as would be expected for an update to an sdfProperty; the effects may play out over time and emit action results. Actions may also not always complete and may result in application errors, such as an item blocking the closing of an automatic door.
アクションは長時間実行される可能性があります。つまり、sdfProperty の更新で予期されるような効果がすぐに発生しない可能性があります。効果は時間の経過とともに再生され、アクションの結果が出力される場合があります。また、アクションが常に完了するとは限らず、アイテムが自動ドアの閉まりを妨げるなど、アプリケーション エラーが発生する可能性があります。
One idiom for giving an action initiator status and control about the ongoing action is to provide a URI for an ephemeral "action resource" in the sdfAction output data, allowing the action to deliver immediate feedback (including errors that prevent the action from starting) and the action initiator to use the action resource for further observation or modification of the ongoing action (including canceling it). Base SDF does not provide any tailored support for describing such action resources; an extension for modeling links in more detail (for instance, [SDFTYPE-LINK]) may be all that is needed to fully enable modeling them.
アクションの開始者にステータスと進行中のアクションに関する制御を与えるための 1 つのイディオムは、sdfAction 出力データ内の一時的な「アクション リソース」の URI を提供することです。これにより、アクションは即座にフィードバック (アクションの開始を妨げるエラーを含む) を配信でき、アクションの開始者は進行中のアクションをさらに観察または変更する (キャンセルを含む) ためにアクション リソースを使用できます。Base SDF は、そのようなアクション リソースを説明するための特別なサポートを提供しません。リンクのモデル化を完全に有効にするために必要なのは、リンクをより詳細にモデル化するための拡張機能 ([SDFTYPE-LINK] など) だけである可能性があります。
Actions may have (or lack) the characteristics of idempotence and side-effect safety (see Section 9.2 of RFC 9110 [STD97] for more on these terms).
アクションには、冪等性と副作用安全性の特性がある (または欠けている) 場合があります (これらの用語の詳細については、RFC 9110 [STD97] のセクション 9.2 を参照してください)。
Base SDF only provides data constraint modeling and semantics for the input and output data of definitions in sdfAction groups. Again, data definitions for payloads of protocol messages, and detailed protocol settings for invoking the action, are expected to be part of the protocol binding.
Base SDF は、sdfAction グループの定義の入力データと出力データのデータ制約モデリングとセマンティクスのみを提供します。繰り返しますが、プロトコル メッセージのペイロードのデータ定義と、アクションを呼び出すための詳細なプロトコル設定は、プロトコル バインディングの一部であることが期待されます。
The sdfEvent group contains declarations of Events, which model affordances that inform about "happenings" associated with a Thing modeled by the enclosing sdfObject; these may result in a signal being stored or emitted as a result.
sdfEvent グループには、イベントの宣言が含まれています。イベントは、囲んでいる sdfObject によってモデル化されたモノに関連付けられた「出来事」について通知するアフォーダンスをモデル化します。その結果、信号が保存または発信される可能性があります。
Note that there is a trivial overlap with sdfProperty state changes, which may also be defined as Events but are not generally required to be defined as such. However, Events may exhibit certain ordering, consistency, and reliability requirements that are expected to be supported in various implementations of sdfEvent that do distinguish sdfEvent from sdfProperty. For instance, while a state change may simply be superseded by another state change, some Events are "precious" and need to be preserved even if further Events follow.
sdfProperty の状態変更とわずかな重複があることに注意してください。これはイベントとして定義することもできますが、通常はイベントとして定義する必要はありません。ただし、イベントは、sdfEvent と sdfProperty を区別する sdfEvent のさまざまな実装でサポートされることが期待される、特定の順序付け、一貫性、および信頼性の要件を示す場合があります。たとえば、状態変化は単に別の状態変化によって置き換えられる可能性がありますが、一部のイベントは「貴重」であり、さらにイベントが続く場合でも保存する必要があります。
Base SDF only provides data constraint modeling and semantics for the output data of Event affordances. Again, data definitions for payloads of protocol messages, and detailed protocol settings for soliciting the event, are expected to be part of the protocol binding.
Base SDF は、イベント アフォーダンスの出力データのデータ制約モデリングとセマンティクスのみを提供します。繰り返しますが、プロトコル メッセージのペイロードのデータ定義と、イベントを要求するための詳細なプロトコル設定は、プロトコル バインディングの一部であることが期待されます。
Definitions in sdfData groups do not themselves specify affordances. These definitions are provided separately from those in sdfProperty groups to enable common modeling patterns, data constraints, and semantic anchor concepts to be factored out for data items that make up sdfProperty items and serve as input and output data for sdfAction and sdfEvent items. The data types defined in sdfData definitions only spring to life by being referenced in one of these contexts (directly or indirectly via some other sdfData definitions).
sdfData グループの定義自体はアフォーダンスを指定しません。これらの定義は、sdfProperty グループの定義とは別に提供され、sdfProperty 項目を構成し、sdfAction および sdfEvent 項目の入力および出力データとして機能するデータ項目に対して共通のモデリング パターン、データ制約、およびセマンティック アンカーの概念を除外できるようにします。sdfData 定義で定義されたデータ型は、これらのコンテキストのいずれかで (直接または他の sdfData 定義を介して間接的に) 参照されることによってのみ有効になります。
It is a common use case for such a data definition to be shared between an sdfProperty item and input or output parameters of an sdfAction or output data provided by an sdfEvent. sdfData definitions also enable factoring out extended application data types, such as mode and machine state enumerations to be reused across multiple definitions that have similar basic characteristics and requirements.
このようなデータ定義が sdfProperty 項目と、sdfAction の入力パラメータまたは出力パラメータ、または sdfEvent によって提供される出力データの間で共有されるのは、一般的な使用例です。sdfData 定義では、モードやマシン状態の列挙などの拡張アプリケーション データ型を取り除き、同様の基本特性と要件を持つ複数の定義間で再利用することもできます。
Back at the top level, the sdfThing group enables definition of models for complex devices that will use one or more sdfObject definitions. Like sdfObject, sdfThing groups allow for the inclusion of interaction affordances, sdfData, as well as "minItems" and "maxItems" qualities. Therefore, they can be seen as a superset of sdfObject groups, additionally allowing for composition.
トップレベルに戻ると、sdfThing グループにより、1 つ以上の sdfObject 定義を使用する複雑なデバイスのモデルの定義が可能になります。sdfObject と同様に、sdfThing グループでは、インタラクション アフォーダンス、sdfData、および「minItems」および「maxItems」品質を含めることができます。したがって、これらは sdfObject グループのスーパーセットとして見ることができ、さらに合成が可能になります。
As a result, an sdfThing directly or indirectly contains a set of sdfProperty, sdfAction, and sdfEvent definitions that describe the interaction affordances associated with some scope of functionality.
その結果、sdfThing には、機能の一部に関連付けられたインタラクション アフォーダンスを記述する sdfProperty、sdfAction、および sdfEvent 定義のセットが直接的または間接的に含まれます。
A definition in an sdfThing group can refine the metadata of the definitions it is composed of: other definitions in sdfThing groups or definitions in sdfObject groups.
sdfThing グループ内の定義は、それを構成する定義 (sdfThing グループ内の他の定義または sdfObject グループ内の定義) のメタデータを調整できます。
SDF documents are JSON maps that mostly employ JSON maps as member values, which in turn mostly employ JSON maps as their member values, and so on. This nested structure of JSON maps creates a tree, where the edges are the member names (map keys) used in these JSON maps. (In certain cases, where member names are not needed, JSON arrays may be interspersed in this tree.)
SDF ドキュメントは、主に JSON マップをメンバー値として使用する JSON マップであり、さらに主に JSON マップをメンバー値として使用します。JSON マップのこの入れ子構造によりツリーが作成されます。エッジは、これらの JSON マップで使用されるメンバー名 (マップ キー) です。(メンバー名が必要ない特定のケースでは、JSON 配列がこのツリーに散在する場合があります。)
For any particular JSON map in an SDF document, the set of member names that are used is either:
SDF ドキュメント内の特定の JSON マップについて、使用されるメンバー名のセットは次のいずれかです。
* A set of "_Quality Names_", where the entries in the map are Qualities. Quality Names are defined by the present specification and its extensions, together with specific semantics to be associated with the member value given with a certain Quality Name.
* 「_Quality Names_」のセット。マップ内のエントリは品質です。品質名は、特定の品質名で指定されたメンバー値に関連付けられる特定のセマンティクスとともに、現在の仕様とその拡張によって定義されます。
* A set of "_Given Names_", where the entries in the map are separate entities (definitions, declarations, etc.) that each have names that are chosen by the SDF document author in order that these names can be employed by a user of that model.
* 「_指定名_」のセット。マップ内のエントリは個別のエンティティ (定義、宣言など) であり、それぞれの名前は、そのモデルのユーザーが使用できるように SDF ドキュメント作成者によって選択された名前を持ちます。
In a path from the root of the tree to any leaf, Quality Names and Given Names roughly alternate (with the information block, Section 3.1, as a prominent exception).
ツリーのルートから任意のリーフまでのパスでは、品質名と指定名がほぼ交互になります (情報ブロック、セクション 3.1 は顕著な例外として)。
The meaning of the JSON map that is the member value associated with a Given Name is derived from the Quality Name that was used as the member name associated to the parent. In the CDDL grammar given in Appendix A, JSON maps with member names that are Given Names are defined using the CDDL generic rule reference named<membervalues>, where membervalues is in turn the structure of the member values of the JSON map, i.e., the value of the member named by the Given Name. As quality-named maps and given-named maps roughly alternate in a path down the tree, membervalues is usually a map built from Quality Names as keys.
指定された名前に関連付けられたメンバー値である JSON マップの意味は、親に関連付けられたメンバー名として使用された品質名から派生します。付録 A に示されている CDDL 文法では、指定された名前であるメンバー名を持つ JSON マップは、<membervalues> という名前の CDDL 汎用ルール参照を使用して定義されます。ここで、membervalues は、JSON マップのメンバー値の構造、つまり指定された名前で指定されたメンバーの値です。品質名付きマップと指定名付きマップはツリーの下位パスでほぼ交互に現れるため、通常、membervalue は品質名をキーとして構築されたマップです。
From the outside of a specification, Given Names are usually used as part of a hierarchical name that looks like a JSON Pointer [RFC6901]. These hierarchical names are generally rooted in (used as the fragment identifier in) an outer namespace that looks like an https:// URL (see Section 4).
仕様の外から見ると、指定名は通常、JSON ポインタ [RFC6901] のように見える階層名の一部として使用されます。これらの階層名は通常、https:// URL のように見える外部名前空間にルートされます (フラグメント識別子として使用されます) (セクション 4 を参照)。
As Quality Names and Given Names roughly alternate in a path into the model, the JSON Pointer part of the hierarchical name also alternates between Quality Names and Given Names.
モデルへのパス内で品質名と指定名がほぼ交互に配置されるため、階層名の JSON ポインター部分も品質名と指定名が交互に表示されます。
Note that the actual Given Names may need to be encoded when specified via the JSON Pointer fragment identifier syntax. There are two layers of such encoding: tilde encoding of ~ and / as per Section 3 of [RFC6901], as well as percent encoding of the tilde-encoded name into a valid URI fragment as per Section 6 of [RFC6901]. For example, when a model is using the Given Name
JSON ポインター フラグメント識別子構文で指定する場合、実際の指定名をエンコードする必要がある場合があることに注意してください。このようなエンコーディングには 2 つの層があります。1 つは [RFC6901] のセクション 3 に基づく ~ と / のチルダエンコーディング、もう 1 つは [RFC6901] のセクション 6 に基づく有効な URI フラグメントへのチルダエンコードされた名前のパーセントエンコーディングです。たとえば、モデルが指定された名前を使用している場合、
warning/danger alarm
(with an embedded slash and a space) for an sdfObject, that sdfObject may need to be referenced as
sdfObject の場合 (スラッシュとスペースが埋め込まれている)、その sdfObject は次のように参照する必要がある場合があります。
#/sdfObject/warning~1danger%20alarm
To sidestep potential interoperability problems, it is probably wise to avoid characters in Given Names that need such encoding (Quality Names are already defined in such a way that they never do).
潜在的な相互運用性の問題を回避するには、そのようなエンコーディングを必要とする指定名の文字を避けるのが賢明でしょう (品質名は、決してエンコーディングを必要としない方法ですでに定義されています)。
In SDF, both Quality Names and Given Names are _extension points_. This is more obvious for Quality Names. Extending SDF is mostly done by defining additional qualities. To enable non-conflicting third party extensions to SDF, qualified names (names with an embedded colon) can be used as Quality Names.
SDF では、品質名と指定名の両方が_拡張ポイント_です。これは品質名の場合により明らかです。SDF の拡張は、主に追加の品質を定義することによって行われます。SDF に対する競合しないサードパーティ拡張を有効にするために、修飾名 (コロンが埋め込まれた名前) を品質名として使用できます。
A nonqualified Quality Name is composed of ASCII letters, digits, and $ signs, starting with a lowercase letter or a $ sign (i.e., using a pattern of "[a-z$][A-Za-z$0-9]*"). Names with $ signs are intended to be used for functions separate from most other names; for instance, $comment is used for the comment quality in this specification (the presence or absence of a $comment quality does not change the meaning of the SDF model). Names that are composed of multiple English words can use the "lowerCamelCase" convention [CamelCase] for indicating the word boundaries; no other use is intended for upper case letters in Quality Names.
非修飾品質名は、小文字または $ 記号で始まる ASCII 文字、数字、および $ 記号で構成されます (つまり、「[a-z$][A-Za-z$0-9]*」のパターンを使用します)。$ 記号の付いた名前は、他のほとんどの名前とは別の関数に使用することを目的としています。たとえば、この仕様では $comment がコメント品質に使用されます ($comment 品質の有無によって SDF モデルの意味は変わりません)。複数の英語の単語で構成される名前は、単語の境界を示すために「 lowerCamelCase 」規則 [CamelCase] を使用できます。品質名の大文字はそれ以外の用途には使用されません。
A qualified Quality Name is composed of a Quality Name Prefix, a : (colon) character, and a nonqualified Quality Name. Quality Name Prefixes are registered in the "Quality Name Prefixes" registry in the "Semantic Definition Format (SDF)" registry group (Section 7.5.2). They are composed of lowercase ASCII letters and digits, starting with a lowercase ASCII letter (i.e., using a pattern of "[a-z][a-z0-9]*").
修飾された品質名は、品質名のプレフィックス、: (コロン) 文字、および非修飾された品質名で構成されます。品質名プレフィックスは、「Semantic Definition Format (SDF)」レジストリ グループの「Quality Name Prefixes」レジストリに登録されます (セクション 7.5.2)。これらは、小文字の ASCII 文字と数字で構成され、小文字の ASCII 文字で始まります (つまり、「[a-z][a-z0-9]*」のパターンを使用します)。
Given Names are not restricted by the formal SDF syntax. To enable non-surprising name translations in tools, combinations of ASCII alphanumeric characters and - (ASCII hyphen/minus) are preferred, typically employing kebab-case for names constructed out of multiple words [KebabCase]. ASCII hyphen/minus can then unambiguously be translated to an ASCII _ underscore character and back depending on the programming environment. Some styles also allow a dot (".") in Given Names. Given Names are often sufficiently self-explanatory that they can be used in place of the label quality if that is not given. In turn, if a Given Name turns out too complicated, a more elaborate label can be given and the Given Name kept simple. As Given Names are "programmers' names", base SDF does not address internationalization of Given Names. (More likely qualities to receive localizable equivalents by exercising the Quality Name extension point are label and description).
指定された名前は、正式な SDF 構文によって制限されません。ツールで意外性のない名前変換を可能にするには、ASCII 英数字と - (ASCII ハイフン/マイナス) の組み合わせが推奨され、通常、複数の単語で構成される名前にはケバブケースが使用されます [KebabCase]。ASCII ハイフン/マイナスは、プログラミング環境に応じて、明確に ASCII _ アンダースコア文字に変換したり、その逆に変換したりすることができます。一部のスタイルでは、名にドット (「.」) を使用することもできます。多くの場合、指定された名前は一目瞭然なので、指定されていない場合はラベルの品質の代わりに使用できます。逆に、指定した名前が複雑すぎることが判明した場合は、より複雑なラベルを付けて、指定した名前を単純にすることができます。名は「プログラマーの名前」であるため、Base SDF は名名の国際化には対応していません。(品質名拡張ポイントを実行することでローカライズ可能な同等の品質を受け取る可能性が最も高いのは、ラベルと説明です)。
Further, to enable Given Names to have a more powerful role in building global hierarchical names, an extension is foreseen that makes use of qualified names for Given Names. So, until that extension is defined, Given Names with one or more embedded colons are reserved and MUST NOT be used in an SDF document.
さらに、グローバル階層名の構築において名がより強力な役割を果たせるようにするために、名に修飾名を使用する拡張機能が予定されています。したがって、その拡張が定義されるまで、1 つ以上のコロンが埋め込まれた指定名は予約されており、SDF ドキュメントで使用してはなりません (MUST NOT)。
All names in SDF are case-sensitive.
SDF 内のすべての名前は大文字と小文字が区別されます。
SDF definitions are contained in SDF documents together with data about the SDF document itself (information block). Definitions and declarations from additional SDF documents can be referenced; together with the definitions and declarations in the referencing SDF document, they build the SDF model expressed by that SDF document.
SDF 定義は、SDF ドキュメント自体に関するデータ (情報ブロック) とともに SDF ドキュメントに含まれます。追加の SDF 文書の定義と宣言を参照できます。参照する SDF ドキュメント内の定義と宣言とともに、その SDF ドキュメントによって表現される SDF モデルを構築します。
Each SDF document is represented as a single JSON map. This map can be thought of as having three blocks: the information block, the namespaces block, and the definitions block. These blocks contain zero or more JSON name/value pairs, the names of which are Quality Names and the values of which mostly are (nested) maps (the exception defined in base SDF is the defaultNamespace quality, the value of which is a text string). An empty nested map of this kind is equivalent to not having the quality included at all.
各 SDF ドキュメントは、単一の JSON マップとして表されます。このマップには、情報ブロック、名前空間ブロック、定義ブロックの 3 つのブロックがあると考えることができます。これらのブロックには 0 個以上の JSON 名/値ペアが含まれており、その名前は品質名であり、その値のほとんどは (ネストされた) マップです (ベース SDF で定義されている例外は、defaultNamespace 品質であり、その値はテキスト文字列です)。この種の空のネストされたマップは、品質がまったく含まれていないことと同じです。
The information block contains generic metadata for the SDF document itself and all included definitions. To enable tool integration, the information block is optional in the grammar of SDF; most processes for working with SDF documents will have policies that only SDF documents with an info block can be processed. It is therefore RECOMMENDED that SDF validator tools emit a warning when no information block is found.
情報ブロックには、SDF ドキュメント自体と含まれるすべての定義の一般的なメタデータが含まれています。ツールの統合を可能にするために、SDF の文法では情報ブロックはオプションです。SDF ドキュメントを操作するほとんどのプロセスには、情報ブロックを含む SDF ドキュメントのみを処理できるポリシーがあります。したがって、情報ブロックが見つからない場合には、SDF 検証ツールが警告を発することが推奨されます。
The keyword (map key) that defines an information block is "info". The keyword's value is a nested JSON map with a set of entries that represent qualities that apply to the included definitions.
情報ブロックを定義するキーワード（マップキー）は「info」です。キーワードの値は、含まれる定義に適用される品質を表すエントリのセットを含むネストされた JSON マップです。
Qualities of this map are shown in Table 1. None of these qualities are required or have default values that are assumed if the quality is absent.
このマップの品質を表 1 に示します。これらの品質はいずれも必須ではなく、品質が存在しない場合に想定されるデフォルト値もありません。
+=============+==========+=================================+
| Quality | Type | Description |
+=============+==========+=================================+
| title | string | A short summary to be displayed |
| | | in search results, etc. |
+-------------+----------+---------------------------------+
| description | string | Long-form text description (no |
| | | constraints) |
+-------------+----------+---------------------------------+
| version | string | The incremental version of the |
| | | definition |
+-------------+----------+---------------------------------+
| modified | string | Time of the latest modification |
+-------------+----------+---------------------------------+
| copyright | string | Link to text or embedded text |
| | | containing a copyright notice |
+-------------+----------+---------------------------------+
| license | string | Link to text or embedded text |
| | | containing license terms |
+-------------+----------+---------------------------------+
| features | array of | List of extension features used |
| | strings | |
+-------------+----------+---------------------------------+
| $comment | string | Source code comments only, no |
| | | semantics |
+-------------+----------+---------------------------------+
Table 1: Qualities of the Information Block
表 1: 情報ブロックの品質
The version quality is used to indicate version information about the set of definitions in the SDF document. The version is RECOMMENDED to be lexicographically increasing over the life of a model; a newer model always has a version string that string-compares higher than all previous versions. This is easily achieved by following the convention to start the version with a date-time as defined in [RFC3339] or, if new versions are generated less frequently than once a day, just the full-date (i.e., YYYY-MM-DD); in many cases, that will be all that is needed (see Figure 1 for an example). This specification does not give a strict definition for the format of the version string, but each system or organization using the version string should define internal structure and semantics to the level needed for their use. If no further details are provided, a date-time or full-date in this field can be assumed to indicate the latest update time of the definitions in the SDF document.
バージョン品質は、SDF ドキュメント内の一連の定義に関するバージョン情報を示すために使用されます。バージョンは、モデルの存続期間中に辞書順に増加することが推奨されます。新しいモデルには常に、以前のすべてのバージョンよりも上位の文字列比較を行うバージョン文字列が含まれます。これは、[RFC3339] で定義されている日付/時刻でバージョンを開始する規則に従うか、新しいバージョンが 1 日に 1 回より少ない頻度で生成される場合は完全な日付 (つまり、YYYY-MM-DD) だけで開始するという規則に従うことで簡単に実現できます。多くの場合、必要なのはこれだけです (例については図 1 を参照)。この仕様はバージョン文字列の形式について厳密な定義を与えていませんが、バージョン文字列を使用する各システムまたは組織は、使用に必要なレベルまで内部構造とセマンティクスを定義する必要があります。それ以上の詳細が提供されない場合、このフィールドの日時または完全な日付は、SDF ドキュメント内の定義の最新の更新時刻を示していると想定できます。
The modified quality can be used with a value using date-time as defined in [RFC3339] (with Z for time-zone) or full-date format to express time of the latest revision of the definitions.
変更された品質は、[RFC3339] で定義されている日時 (タイムゾーンの Z を含む) または完全な日付形式を使用した値とともに使用して、定義の最新リビジョンの時刻を表すことができます。
The license string is preferably either a URI that points to a web page with an unambiguous definition of the license or an [SPDX] license identifier. (As an example, for models to be handled by the One Data Model liaison group, this license identifier will typically be "BSD-3-Clause".)
ライセンス文字列は、ライセンスの明確な定義を持つ Web ページを指す URI、または [SPDX] ライセンス識別子のいずれかであることが好ましい。(例として、One Data Model 連絡グループによって処理されるモデルの場合、このライセンス識別子は通常「BSD-3-Clause」になります。)
The features quality can be used to list names of critical (i.e., cannot be safely ignored) SDF extension features that need to be understood for the definitions to be properly processed. Extension feature names will be specified in extension documents. They can either be registered (see Section 7.5.4 for specifics, which make sure that a registered feature name does not contain a colon) or be a URI (which always contain a colon). Note that SDF processors are not expected to, and normally SHOULD NOT, dereference URIs used as feature names; any representation retrievable under such a URI could be useful to humans, though. (See [DEREF-ID-PATTERN] for a more extensive discussion of dereferenceable identifiers).
機能の品質を使用して、定義を適切に処理するために理解する必要がある重要な (つまり、無視して安全な) SDF 拡張機能の名前をリストすることができます。拡張機能名は拡張ドキュメントで指定されます。これらは登録することもできます (詳細については、登録された機能名にコロンが含まれていないことを確認するセクション 7.5.4 を参照) か、URI (常にコロンが含まれる) にすることができます。SDF プロセッサは、機能名として使用される URI を逆参照することを期待されておらず、通常はすべきではないことに注意してください。ただし、そのような URI で取得できる表現はすべて人間にとって役立つ可能性があります。(逆参照可能な識別子の詳細については、[DEREF-ID-PATTERN] を参照してください)。
The namespaces block contains the namespace map and the defaultNamespace setting; none of these qualities are required or have default values that are assumed if the quality is absent.
名前空間ブロックには、名前空間マップとdefaultNamespace設定が含まれています。これらの品質はいずれも必須ではなく、品質がない場合に想定されるデフォルト値もありません。
The namespace map is a map from short names for URIs to the namespace URIs themselves.
名前空間マップは、URI の短縮名から名前空間 URI 自体へのマップです。
The defaultNamespace setting selects one of the entries in the namespace map by giving its short name. The associated URI (value of this entry) becomes the default namespace for the SDF document.
defaultNamespace 設定では、名前空間マップ内のエントリの 1 つを、短い名前を指定して選択します。関連付けられた URI (このエントリの値) が、SDF ドキュメントのデフォルトの名前空間になります。
+==================+========+===================================+
| Quality | Type | Description |
+==================+========+===================================+
| namespace | map | Defines short names mapped to |
| | | namespace URIs, to be used as |
| | | identifier prefixes |
+------------------+--------+-----------------------------------+
| defaultNamespace | string | Identifies one of the prefixes in |
| | | the namespace map to be used as a |
| | | default in resolving identifiers |
+------------------+--------+-----------------------------------+
Table 2: Namespaces Block
表 2: 名前空間ブロック
The following example declares a set of namespaces and defines cap as the default namespace. By convention, the values in the namespace map contain full URIs without a fragment identifier and the fragment identifier is then added, if needed, where the namespace entry is used.
次の例では、名前空間のセットを宣言し、cap をデフォルトの名前空間として定義します。慣例により、名前空間マップ内の値にはフラグメント識別子のない完全な URI が含まれており、必要に応じて、名前空間エントリが使用される場所にフラグメント識別子が追加されます。
"namespace": {
"cap": "https://example.com/capability/cap",
"zcl": "https://zcl.example.com/sdf"
},
"defaultNamespace": "cap"
Multiple SDF documents can contribute to the same namespace by using the same namespace URI for the default namespace across the documents.
複数の SDF ドキュメントは、ドキュメント全体でデフォルトの名前空間に同じ名前空間 URI を使用することで、同じ名前空間に貢献できます。
If no defaultNamespace setting is given, the SDF document does not contribute to a global namespace (all definitions remain local to the model and are not accessible for re-use by other models). As the defaultNamespace is set by supplying a namespace short name, its presence requires a namespace map that contains a mapping for that namespace short name.
defaultNamespace 設定が指定されていない場合、SDF ドキュメントはグローバル名前空間に寄与しません (すべての定義はモデルに対してローカルのままであり、他のモデルから再利用するためにアクセスすることはできません)。defaultNamespace は名前空間の短縮名を指定することによって設定されるため、その存在には、その名前空間の短縮名に対するマッピングを含む名前空間マップが必要です。
If no namespace map is given, no short names for namespace URIs are set up and no defaultNamespace can be given.
名前空間マップが指定されていない場合、名前空間 URI の短縮名は設定されず、defaultNamespace も指定できません。
The Definitions block contains one or more groups, each identified by a Class Name Keyword such as sdfObject or sdfProperty. There can only be one group per keyword at this level; putting all the individual definitions in the group under that keyword is just a shortcut for identifying the class name keyword that applies to each of them without repeating it for each definition.
Definitions ブロックには 1 つ以上のグループが含まれており、各グループは sdfObject や sdfProperty などのクラス名キーワードによって識別されます。このレベルでは、キーワードごとに 1 つのグループのみが存在できます。グループ内のすべての個別の定義をそのキーワードの下に置くことは、定義ごとに繰り返すことなく、それぞれに適用されるクラス名のキーワードを識別するための単なる近道です。
The value of each group is a JSON map, the keys of which serve for naming the individual definitions in this group, and the corresponding values provide a set of qualities (name-value pairs) for the individual definition. (In short, these map entries are also termed "named sets of qualities".)
各グループの値は JSON マップであり、そのキーはこのグループ内の個々の定義に名前を付けるために使用され、対応する値は個々の定義に一連の品質 (名前と値のペア) を提供します。(要するに、これらのマップ エントリは「品質の名前付きセット」とも呼ばれます。)
Each group may contain zero or more definitions. Each identifier defined creates a new type and term in the target namespace. Declarations have a scope of the definition block they are directly contained in.
各グループには 0 個以上の定義が含まれる場合があります。定義された各識別子は、ターゲット名前空間に新しい型と用語を作成します。宣言には、それが直接含まれる定義ブロックのスコープがあります。
In turn, a definition may contain other definitions. Each definition is a named set of qualities, i.e., it consists of the newly defined identifier and a set of key-value pairs that represent the defined qualities and contained definitions.
さらに、定義には他の定義が含まれる場合があります。各定義は名前付きの品質のセットです。つまり、新しく定義された識別子と、定義された品質および含まれる定義を表すキーと値のペアのセットで構成されます。
An example for an sdfObject definition is given in Figure 3:
sdfObject 定義の例を図 3 に示します。
"sdfObject": {
"foo": {
"sdfProperty": {
"bar": {
"type": "boolean"
}
}
}
}
Figure 3: Example sdfObject Definition
図 3: sdfObject 定義の例
This example defines an sdfObject "foo" that is defined in the default namespace (full address: #/sdfObject/foo), containing a Property that can be addressed as #/sdfObject/foo/sdfProperty/bar, with data of type boolean.
この例では、デフォルトの名前空間 (完全なアドレス: #/sdfObject/foo) で定義される sdfObject "foo" を定義します。これには、#/sdfObject/foo/sdfProperty/bar としてアドレス指定できる、ブール型のデータを持つプロパティが含まれます。
Often, definitions are also declarations. The definition of the entry "bar" in the Property "foo" means that data corresponding to the "foo" Property in a Property interaction offered by Thing can have zero or one components modeled by "bar". Entries within sdfProperty, sdfAction, and sdfEvent that are in turn within sdfObject or sdfThing entries, are also declarations; entries within sdfData are not. Similarly, sdfObject or sdfThing entries within an sdfThing definition specify that the interactions offered by a Thing modeled by this sdfThing include the interactions modeled by the nested sdfObject or sdfThing.
多くの場合、定義は宣言でもあります。プロパティ「foo」のエントリ「bar」の定義は、Thing によって提供されるプロパティ インタラクションの「foo」プロパティに対応するデータが、「bar」によってモデル化されたコンポーネントを 0 つまたは 1 つ持つことができることを意味します。sdfProperty、sdfAction、および sdfEvent 内のエントリ、つまり sdfObject または sdfThing エントリ内のエントリも宣言です。sdfData 内のエントリはそうではありません。同様に、sdfThing 定義内の sdfObject または sdfThing エントリは、この sdfThing によってモデル化された Thing によって提供されるインタラクションに、ネストされた sdfObject または sdfThing によってモデル化されたインタラクションが含まれることを指定します。
Besides their placement within an sdfObject or sdfThing, affordances (i.e., sdfProperty, sdfAction, and sdfEvent) as well as sdfData can also be placed at the top level of an SDF document. Since they are not associated with an sdfObject or sdfThing, these kinds of definitions are intended to be reused via the sdfRef mechanism (see Section 4.4).
sdfObject または sdfThing 内に配置する以外に、アフォーダンス (つまり、sdfProperty、sdfAction、および sdfEvent) および sdfData を SDF ドキュメントの最上位に配置することもできます。これらは sdfObject または sdfThing に関連付けられていないため、これらの種類の定義は sdfRef メカニズムを介して再利用されることを目的としています (セクション 4.4 を参照)。
SDF documents may contribute to a global namespace and may reference elements from that global namespace. (An SDF document that does not set a defaultNamespace does not contribute to a global namespace.)
SDF ドキュメントはグローバル名前空間に貢献し、そのグローバル名前空間から要素を参照する場合があります。(defaultNamespace を設定しない SDF ドキュメントは、グローバル名前空間に寄与しません。)
Global names look exactly like https:// URIs with attached fragment identifiers.
グローバル名は、フラグメント識別子が付加された https:// URI とまったく同じように見えます。
There is no intention to require that these URIs can be dereferenced. (However, as future extensions of SDF might find a use for dereferencing global names, the URI should be chosen in such a way that this may become possible in the future. See also [DEREF-ID-PATTERN] for a discussion of dereferenceable identifiers.)
これらの URI を逆参照できるようにすることを要求するつもりはありません。(ただし、SDF の将来の拡張では、グローバル名の逆参照が使用される可能性があるため、これが将来可能になるような方法で URI を選択する必要があります。逆参照可能な識別子の議論については、[DEREF-ID-PATTERN] も参照してください。)
The absolute-URI of a global name should be a URI as per Section 3 of RFC 3986 [STD66] with a scheme of "https" and a path (hier-part in [STD66]). For base SDF, the query part should not be used (it might be used in extensions).
グローバル名の絶対 URI は、RFC 3986 [STD66] のセクション 3 に従って、「https」スキームとパス ([STD66] の階層部分) を備えた URI である必要があります。基本 SDF の場合、クエリ部分は使用しないでください (拡張で使用される可能性があります)。
The fragment identifier is constructed as per Section 6 of [RFC6901].
フラグメント識別子は、[RFC6901] のセクション 6 に従って構築されます。
The fragment identifier part of a global name defined in an SDF document is constructed from a JSON Pointer that selects the element defined for this name in the SDF document. The absolute-URI part is a copy of the default namespace.
SDF ドキュメントで定義されたグローバル名のフラグメント識別子部分は、SDF ドキュメント内でこの名前に対して定義された要素を選択する JSON ポインタから構築されます。絶対 URI 部分はデフォルトの名前空間のコピーです。
As a result, the default namespace is always the target namespace for a name for which a definition is contributed. In order to emphasize that name definitions are contributed to the default namespace, this namespace is also termed the "target namespace" of the SDF document.
その結果、デフォルトの名前空間は常に、定義が提供される名前のターゲット名前空間になります。名前定義がデフォルトの名前空間に提供されることを強調するために、この名前空間は SDF ドキュメントの「ターゲット名前空間」とも呼ばれます。
For instance, in Figure 1, definitions for the following global names are contributed:
たとえば、図 1 では、次のグローバル名の定義が提供されています。
* https://example.com/capability/cap#/sdfObject/Switch
* https://example.com/capability/cap#/sdfObject/Switch
* https://example.com/capability/cap#/sdfObject/Switch/sdfProperty/ value
* https://example.com/capability/cap#/sdfObject/Switch/sdfProperty/value
* https://example.com/capability/cap#/sdfObject/Switch/sdfAction/on
* https://example.com/capability/cap#/sdfObject/Switch/sdfAction/on
* https://example.com/capability/cap#/sdfObject/Switch/sdfAction/off
* https://example.com/capability/cap#/sdfObject/Switch/sdfAction/off
* https://example.com/capability/cap#/sdfObject/Switch/sdfAction/ toggle
* https://example.com/capability/cap#/sdfObject/Switch/sdfAction/切り替え
Note the #, which separates the absolute-URI part (Section 4.3 of RFC 3986 [STD66]) from the fragment identifier part (including the #, a JSON Pointer as in Section 6 of [RFC6901]).
絶対 URI 部分 (RFC 3986 [STD66] のセクション 4.3) とフラグメント識別子部分 ([RFC6901] のセクション 6 のような JSON ポインターである # を含む) を区切る # に注意してください。
A name reference takes the form of the production curie in Section 3 of [W3C.NOTE-curie-20101216], but limiting the IRIs involved in that grammar to URIs as per [STD66] and the prefixes to ASCII characters [STD80]. (Note that this definition does not make use of the production safe-curie in [W3C.NOTE-curie-20101216].)
名前参照は、[W3C.NOTE-curie-20101216] のセクション 3 の本番キュリーの形式をとりますが、その文法に含まれる IRI を [STD66] に従って URI に、プレフィックスを ASCII 文字 [STD80] に制限します。(この定義では、[W3C.NOTE-curie-20101216] の本番環境のsafe-curie が使用されないことに注意してください。)
A name that is contributed by the current SDF document can be referenced by a Same-Document Reference as per Section 4.4 of RFC 3986 [STD66]. As there is little point in referencing the entire SDF document, this will be a # followed by a JSON Pointer. This is the only kind of name reference to itself that is possible in an SDF document that does not set a default namespace.
現在の SDF ドキュメントによって提供される名前は、RFC 3986 [STD66] のセクション 4.4 に従って、Same-Document Reference によって参照できます。SDF ドキュメント全体を参照することにはほとんど意味がないため、これは # の後に JSON ポインターが続きます。これは、デフォルトの名前空間を設定しない SDF ドキュメントで可能な、それ自体への名前参照の唯一の種類です。
Name references that point outside the current SDF document need to contain CURIE prefixes. These then reference namespace declarations in the namespaces block.
現在の SDF ドキュメントの外部を指す名前参照には、CURIE 接頭辞が含まれている必要があります。これらは、名前空間ブロック内の名前空間宣言を参照します。
For example, if a namespace prefix is defined:
たとえば、名前空間プレフィックスが定義されている場合は、次のようになります。
"namespace": {
"foo": "https://example.com/"
}
then this reference to that namespace:
次に、その名前空間への参照:
"sdfRef": "foo:#/sdfData/temperatureData"
references the global name:
グローバル名を参照します。
"https://example.com/#/sdfData/temperatureData"
Note that there is no way to provide a URI scheme name in a CURIE, so all references to outside of the document need to go through the namespace map.
CURIE では URI スキーム名を提供する方法がないため、ドキュメントの外部へのすべての参照は名前空間マップを通過する必要があることに注意してください。
Name references occur only in specific elements of the syntax of SDF:
名前参照は、SDF 構文の特定の要素でのみ発生します。
* copying elements via sdfRef values
* sdfRef 値を介して要素をコピーする
* pointing to elements via sdfRequired value elements
* sdfRequired 値要素を介して要素を指す
In a JSON map establishing a definition, the keyword sdfRef is used to copy the qualities and enclosed definitions of the referenced definition, indicated by the included name reference, into the newly formed definition. (This can be compared to the processing of the $ref keyword in [JSO7].) The referenced definition should be such that, after copying and applying the additional qualities in the referencing definition, the newly built definition is also valid SDF (e.g., the copied qualities and definitions are valid in the context of the new definition).
定義を確立する JSON マップでは、キーワード sdfRef を使用して、含まれる名前参照によって示される参照先定義の品質と囲まれた定義を、新しく形成された定義にコピーします。(これは、[JSO7] の $ref キーワードの処理と比較できます。) 参照される定義は、参照元の定義内の追加の品質をコピーして適用した後、新しく構築された定義も有効な SDF である必要があります (たとえば、コピーされた品質と定義は新しい定義のコンテキストで有効です)。
For example, this reference:
たとえば、このリファレンスは次のとおりです。
"temperatureProperty": {
"sdfRef": "#/sdfData/temperatureData"
}
creates a new definition "temperatureProperty" that contains all of the qualities defined in the definition at /sdfData/temperatureData.
/sdfData/temperatureData の定義で定義されているすべての品質を含む新しい定義「tempertyProperty」を作成します。
The sdfRef member need not be the only member of a map. Additional members may be present with the intention of overriding parts of the referenced map or adding new qualities or definitions.
sdfRef メンバーはマップの唯一のメンバーである必要はありません。追加のメンバーは、参照されたマップの一部をオーバーライドしたり、新しい品質や定義を追加したりする目的で存在する場合があります。
When processing sdfRef, if the target definition contains also sdfRef (i.e., is based on yet another definition), that MUST be processed as well.
sdfRef を処理するとき、ターゲット定義に sdfRef も含まれている場合 (つまり、さらに別の定義に基づいている場合)、それも同様に処理しなければなりません (MUST)。
More formally, for a JSON map that contains an sdfRef member, the semantics are defined to be as if the following steps were performed:
より正式には、sdfRef メンバーを含む JSON マップの場合、セマンティクスは次の手順が実行されたかのように定義されます。
1. The JSON map that contains the sdfRef member is copied into a variable named "patch".
1. sdfRef メンバーを含む JSON マップは、「patch」という名前の変数にコピーされます。
2. The sdfRef member of the copy in "patch" is removed.
2. 「patch」内のコピーの sdfRef メンバーが削除されます。
3. The JSON Pointer that is the value of the sdfRef member is dereferenced and the result is copied into a variable named "original".
3. sdfRef メンバーの値である JSON ポインターが逆参照され、結果が「original」という名前の変数にコピーされます。
4. The JSON Merge Patch algorithm [RFC7396] is applied to patch the contents of "original" with the contents of "patch".
4. JSON Merge Patch アルゴリズム [RFC7396] は、「オリジナル」の内容を「パッチ」の内容でパッチするために適用されます。
5. The result of the Merge Patch is used in place of the value of the original JSON map.
5. マージ パッチの結果は、元の JSON マップの値の代わりに使用されます。
Note that the formal syntaxes given in Appendices A and B generally describe the _result_ of applying a merge-patch. The notations are not powerful enough to describe, for instance, how the merge-patch algorithm causes null values within the sdfRef to remove members of JSON maps from the referenced target. Nonetheless, the syntaxes also give the syntax of the sdfRef itself, which vanishes during the resolution; therefore, in many cases, even merge-patch inputs will validate with these formal syntaxes.
付録 A および B に示されている正式な構文は、通常、マージ パッチを適用した結果を説明していることに注意してください。この表記法は、たとえば、マージパッチ アルゴリズムが sdfRef 内の null 値をどのようにして参照対象から JSON マップのメンバーを削除するかを説明するのに十分強力ではありません。それにもかかわらず、構文は sdfRef 自体の構文も示しますが、これは解決中に消えます。したがって、多くの場合、マージパッチ入力であっても、これらの正式な構文で検証されます。
Given the example (Figure 1) and the following definition:
例 (図 1) と次の定義があるとします。
{
"info": {
"title": "Example light switch using sdfRef"
},
"namespace": {
"cap": "https://example.com/capability/cap"
},
"defaultNamespace": "cap",
"sdfObject": {
"BasicSwitch": {
"sdfRef": "cap:#/sdfObject/Switch",
"sdfAction": {
"toggle": null
}
}
}
}
The resulting definition of the "BasicSwitch" sdfObject would be identical to the definition of the "Switch" sdfObject, except it would not contain the "toggle" Action.
結果として得られる「BasicSwitch」sdfObject の定義は、「toggle」アクションが含まれないことを除いて、「Switch」sdfObject の定義と同じになります。
{
"info": {
"title": "Example light switch using sdfRef"
},
"namespace": {
"cap": "https://example.com/capability/cap"
},
"defaultNamespace": "cap",
"sdfObject": {
"BasicSwitch": {
"sdfProperty": {
"value": {
"description":
"The state of the switch; false for off and true for on.",
"type": "boolean"
}
},
"sdfAction": {
"on": {
"description":
"Turn the switch on; equivalent to setting value to true."
},
"off": {
"description":
"Turn the switch off; equivalent to setting value to false."
}
}
}
}
}
A model where all sdfRef references are processed as described in Section 4.4 is called a resolved model.
すべての sdfRef 参照がセクション 4.4 で説明されているように処理されるモデルは、解決されたモデルと呼ばれます。
For example, given the following sdfData definitions:
たとえば、次の sdfData 定義があるとします。
"sdfData": {
"Coordinate" : {
"type": "number", "unit": "m"
},
"X-Coordinate" : {
"sdfRef" : "#/sdfData/Coordinate",
"description":
"Distance from the base of the Thing along the X axis."
},
"Non-neg-X-Coordinate" : {
"sdfRef": "#/sdfData/X-Coordinate",
"minimum": 0
}
}
the definitions would look as follows after being resolved:
解決後の定義は次のようになります。
"sdfData": {
"Coordinate" : {
"type": "number", "unit": "m"
},
"X-Coordinate" : {
"description":
"Distance from the base of the Thing along the X axis.",
"type": "number", "unit": "m"
},
"Non-neg-X-Coordinate" : {
"description":
"Distance from the base of the Thing along the X axis.",
"minimum": 0, "type": "number", "unit": "m"
}
}
The keyword sdfRequired is provided to apply a constraint that defines for which declarations the corresponding data are mandatory in a grouping (sdfThing or sdfObject) modeled by the current definition.
キーワード sdfRequired は、現在の定義によってモデル化されたグループ化 (sdfThing または sdfObject) 内で、対応するデータがどの宣言に対して必須であるかを定義する制約を適用するために提供されます。
The value of sdfRequired is an array of references, each indicating one or more declarations that are mandatory to be represented.
sdfRequired の値は参照の配列であり、各参照は表現することが必須である 1 つ以上の宣言を示します。
References in this array can be SDF names (JSON Pointers) or one of two abbreviated reference formats:
この配列内の参照は、SDF 名 (JSON ポインター) または 2 つの短縮参照形式のいずれかになります。
* A text string with a "referenceable-name", namely an affordance name or a grouping name:
* 「参照可能な名前」、つまりアフォーダンス名またはグループ名を含むテキスト文字列:
- All affordance declarations that are directly in the same grouping (i.e., not nested further in another grouping) and that carry this name are declared to be mandatory to be represented. Note that there can be multiple such affordance declarations, one per affordance type.
- 同じグループに直接属し (つまり、別のグループにさらにネストされていない)、この名前を持つすべてのアフォーダンス宣言は、表現することが必須であると宣言されます。このようなアフォーダンス宣言は、アフォーダンス タイプごとに 1 つずつ、複数存在できることに注意してください。
- The same applies to groupings made mandatory within groupings containing them.
- 同じことが、グループを含むグループ内で必須にされたグループにも当てはまります。
* The Boolean value true. The affordance or grouping itself that carries the sdfRequired keyword is declared to be mandatory to be represented.
* ブール値 true。sdfRequired キーワードを含むアフォーダンスまたはグループ化自体は、表現することが必須であると宣言されます。
Note that referenceable-names are not subject to the encoding JSON Pointers require as discussed in Section 2.3.2. To ensure that referenceable-names are reliably distinguished from JSON Pointers, they are defined such that they cannot contain ":" or "#" characters (see rule referenceable-name in Appendix A). (If these characters are indeed contained in a Given Name, a JSON Pointer needs to be formed instead in order to reference it in "sdfRequired", potentially requiring further path elements as well as JSON Pointer encoding. The need for this is best avoided by choosing Given Names without these characters.)
セクション 2.3.2 で説明したように、参照可能名は JSON ポインターに必要なエンコーディングの対象にはならないことに注意してください。参照可能名が JSON ポインタと確実に区別されるように、「:」または「#」文字を含めることができないように定義されています (付録 A のルール参照可能名を参照)。(これらの文字が実際に指定された名前に含まれている場合は、「sdfRequired」でそれを参照するために代わりに JSON ポインターを形成する必要があり、JSON ポインターのエンコーディングだけでなく追加のパス要素が必要になる可能性があります。この必要性を回避するには、これらの文字を含まない指定された名前を選択するのが最善です。)
The example in Figure 4 shows two required elements in the sdfObject definition for "temperatureWithAlarm", the sdfProperty "currentTemperature", and the sdfEvent "overTemperatureEvent". The example also shows the use of JSON Pointers with "sdfRef" to use a pre-existing definition for the sdfProperty "currentTemperature" and for the sdfOutputData produced by the sdfEvent "overTemperatureEvent".
図 4 の例は、sdfObject 定義の「temperatureWithAlarm」、sdfProperty「currentTemperature」、および sdfEvent「overTemperatureEvent」の 2 つの必須要素を示しています。この例では、「sdfRef」による JSON ポインターを使用して、sdfProperty「currentTemperature」および sdfEvent「overTemperatureEvent」によって生成された sdfOutputData の既存の定義を使用することも示しています。
"sdfObject": {
"temperatureWithAlarm": {
"sdfRequired": [
"#/sdfObject/temperatureWithAlarm/sdfProperty/currentTemperature",
"#/sdfObject/temperatureWithAlarm/sdfEvent/overTemperatureEvent"
],
"sdfData":{
"temperatureData": {
"type": "number"
}
},
"sdfProperty": {
"currentTemperature": {
"sdfRef": "#/sdfObject/temperatureWithAlarm/sdfData/temperatureData",
"writable": false
}
},
"sdfEvent": {
"overTemperatureEvent": {
"sdfOutputData": {
"sdfRef": "#/sdfObject/temperatureWithAlarm/sdfData/temperatureData"
}
}
}
}
}
Figure 4: Using sdfRequired
図 4: sdfRequired の使用
In Figure 4, the same sdfRequired can also be represented in short form:
図 4 では、同じ sdfRequired を短い形式で表すこともできます。
"sdfRequired": ["currentTemperature", "overTemperatureEvent"]
Or, for instance, "overTemperatureEvent" could carry:
あるいは、たとえば、「overTemperatureEvent」は次のように伝えることもできます。
"overTemperatureEvent": {
"sdfRequired": [true],
"...": "..."
}
Definitions in SDF share a number of qualities that provide metadata for them. These are listed in Table 3. None of these qualities are required or have default values that are assumed if the quality is absent. If a short textual description is required for an application and no label is given in the SDF model, applications could use the last part (the last reference-token, Section 3 of [RFC6901]) of the JSON Pointer to the definition in its place.
SDF の定義は、メタデータを提供する多くの性質を共有しています。これらは表 3 にリストされています。これらの品質はいずれも必須ではなく、品質が存在しない場合に想定されるデフォルト値もありません。アプリケーションに短いテキストによる説明が必要で、SDF モデルにラベルが指定されていない場合、アプリケーションはその代わりに定義への JSON ポインタの最後の部分 (最後の参照トークン、[RFC6901] のセクション 3) を使用できます。
+=============+==============+=============================+
| Quality | Type | Description |
+=============+==============+=============================+
| description | string | long text (no constraints) |
+-------------+--------------+-----------------------------+
| label | string | short text (no constraints) |
+-------------+--------------+-----------------------------+
| $comment | string | source code comments only, |
| | | no semantics |
+-------------+--------------+-----------------------------+
| sdfRef | sdf-pointer | (see Section 4.4) |
+-------------+--------------+-----------------------------+
| sdfRequired | pointer-list | (see Section 4.5, used in |
| | | affordances or groupings) |
+-------------+--------------+-----------------------------+
Table 3: Common Qualities
表 3: 共通の性質
Data qualities are used in sdfData and sdfProperty definitions, which are named sets of data qualities (abbreviated as named-sdq).
データ品質は sdfData および sdfProperty 定義で使用され、これらはデータ品質の名前付きセット (named-sdq と略されます) です。
These qualities include the common qualities, JSO-inspired qualities (see below), and data qualities defined specifically for the present specification; the latter are shown in Table 4.
これらの品質には、共通品質、JSO に影響を受けた品質 (以下を参照)、および本仕様のために特別に定義されたデータ品質が含まれます。後者を表 4 に示します。
Appendix C lists data qualities inspired by the various proposals at json-schema.org; the intention is that these (information model-level) qualities are compatible with the (data model) semantics from the versions of the json-schema.org proposal they were imported from.
付録 C には、json-schema.org のさまざまな提案に基づいたデータ品質がリストされています。その目的は、これらの (情報モデル レベルの) 品質が、インポート元の json-schema.org プロポーザルのバージョンの (データ モデル) セマンティクスと互換性があることです。
+===============+================+====================+=========+
| Quality | Type | Description | Default |
+===============+================+====================+=========+
| (common) | | Section 4.6 | |
+---------------+----------------+--------------------+---------+
| unit | string | unit name (note 1) | N/A |
+---------------+----------------+--------------------+---------+
| nullable | boolean | indicates a null | true |
| | | value is available | |
| | | for this type | |
+---------------+----------------+--------------------+---------+
| contentFormat | string | content type (IANA | N/A |
| | | media type string | |
| | | plus parameters), | |
| | | encoding (note 2) | |
+---------------+----------------+--------------------+---------+
| sdfType | string | sdfType | N/A |
| | (Section | enumeration | |
| | 4.7.1) | (extensible) | |
+---------------+----------------+--------------------+---------+
| sdfChoice | named set of | named alternatives | N/A |
| | data qualities | | |
| | (Section | | |
| | 4.7.2) | | |
+---------------+----------------+--------------------+---------+
| enum | array of | abbreviation for | N/A |
| | strings | string-valued | |
| | | named alternatives | |
+---------------+----------------+--------------------+---------+
Table 4: SDF-Defined Qualities of sdfData and sdfProperty
表 4: sdfData および sdfProperty の SDF 定義の品質
1. The unit name SHOULD be as per the "SenML Units" registry or the "Secondary Units" registry in [IANA.senml] as specified by Sections 4.5.2 and 12.1 of [RFC8428] and Section 3 of [RFC8798], respectively.
1. ユニット名は、[RFC8428] のセクション 4.5.2 と 12.1、および [RFC8798] のセクション 3 でそれぞれ指定されている [IANA.senml] の "SenML Units" レジストリまたは "Secondary Units" レジストリに従っている必要があります (SHOULD)。
Exceptionally, if a registration in these registries cannot be obtained or would be inappropriate, the unit name can also be a URI that is pointing to a definition of the unit. Note that SDF processors are not expected to, and normally SHOULD NOT, dereference these URIs; the definition pointed to may be useful to humans, though. (See [DEREF-ID-PATTERN] for a more extensive discussion of dereferenceable identifiers).
例外的に、これらのレジストリへの登録を取得できない場合、または登録が不適切な場合は、ユニット名がユニットの定義を指す URI になることもあります。SDF プロセッサはこれらの URI を逆参照することを期待されておらず、通常はすべきではないことに注意してください。ただし、指摘された定義は人間にとって役立つかもしれません。(逆参照可能な識別子の詳細については、[DEREF-ID-PATTERN] を参照してください)。
A URI unit name is distinguished from a registered unit name by the presence of a colon; therefore, any registered unit names that contain a colon (at the time of writing, none) cannot be directly used in SDF.
URI ユニット名は、コロンの存在によって登録されたユニット名と区別されます。したがって、コロンを含む登録されたユニット名 (この記事の執筆時点ではコロンはありません) は、SDF で直接使用できません。
For use by translators into ecosystems that require URIs for unit names, the URN sub-namespace "urn:ietf:params:unit" is provided (Section 7.3). URNs from this sub-namespace MUST NOT be used in a unit quality in favor of simply notating the unit name (such as kg instead of urn:ietf:params:unit:kg) except where the unit name contains a colon and can therefore not be directly used in SDF.
ユニット名に URI を必要とするエコシステムへの翻訳者が使用するために、URN サブ名前空間「urn:ietf:params:unit」が提供されています (セクション 7.3)。このサブ名前空間の URN は、ユニット名にコロンが含まれているため SDF で直接使用できない場合を除き、単にユニット名を表記することを優先して (urn:ietf:params:unit:kg の代わりに kg など) ユニット品質で使用してはなりません (MUST NOT)。
2. The contentFormat quality follows the Content-Format-Spec as defined in Section 6 of [RFC9193], allowing for expressing both numeric and string based Content-Formats.
2. contentFormat の品質は、[RFC9193] のセクション 6 で定義されている Content-Format-Spec に従い、数値ベースと文字列ベースの両方の Content-Format を表現できます。
SDF defines a number of basic types beyond those provided by JSON or JSO. These types are identified by the sdfType quality, which is a text string from a set of type names defined by the "sdfType values" registry in the "Semantic Definition Format (SDF)" registry group (Section 7.5.3). The sdfType name is composed of lowercase ASCII letters, digits, and - (ASCII hyphen/minus) characters, starting with a lowercase ASCII letter (i.e., using a pattern of "[a-z][-a-z0-9]*") and typically employing kebab-case for names constructed out of multiple words [KebabCase].
SDF は、JSON または JSO で提供されるものを超えた多くの基本的な型を定義します。これらの型は、sdfType 品質によって識別されます。これは、「Semantic Definition Format (SDF)」レジストリ グループ (セクション 7.5.3) の「sdfType 値」レジストリによって定義された一連の型名のテキスト文字列です。sdfType 名は、小文字の ASCII 文字、数字、および - (ASCII ハイフン/マイナス) 文字で構成され、小文字の ASCII 文字で始まり (つまり、"[a-z][-a-z0-9]*" のパターンを使用)、通常、複数の単語で構成される名前にはケバブケースが使用されます [KebabCase]。
To aid interworking with JSO implementations, it is RECOMMENDED that sdfType is always used in conjunction with the type quality inherited from [JSO7V] in such a way as to yield a common representation of the type's values in JSON.
JSO 実装との相互作用を支援するために、JSON で型の値の共通表現を生成するような方法で、sdfType を [JSO7V] から継承した型品質と常に組み合わせて使用することが推奨されます。
Values for sdfType that are defined in this specification are shown in Table 5. This table also gives a description of the semantics of the sdfType, the conventional value for type to be used with the sdfType value, and a conventional JSON representation for values of the type. The type and the JSON representation are chosen to be consistent with each other; this MUST be true for additionally registered sdfType values as well.
この仕様で定義されている sdfType の値を表 5 に示します。この表には、sdfType のセマンティクス、sdfType 値とともに使用される型の従来の値、および型の値の従来の JSON 表現についても説明されています。型と JSON 表現は、相互に一貫性があるように選択されます。これは、追加で登録された sdfType 値にも当てはまらなければなりません。
+=============+=============+========+================+============+
| Name | Description | type | JSON | Reference |
| | | | Representation | |
+=============+=============+========+================+============+
| byte-string | A sequence | string | base64url | Section |
| | of zero or | | without | 3.4.5.2 of |
| | more bytes | | padding | RFC 8949 |
| | | | | [STD94] |
+-------------+-------------+--------+----------------+------------+
| unix-time | A point in | number | POSIX time | Section |
| | civil time | | | 3.4.2 of |
| | (note 1) | | | RFC 8949 |
| | | | | [STD94] |
+-------------+-------------+--------+----------------+------------+
Table 5: Values Defined in Base SDF for the sdfType Quality
表 5: Base SDF で定義されている sdfType 品質の値
(1) Note that the definition of unix-time does not imply the capability to represent points in time that fall on leap seconds. More date/time-related sdfTypes are likely to be added in the sdfType value registry.
(1) unix-time の定義は、うるう秒に当たる時点を表す機能を意味するものではないことに注意してください。さらに多くの日付/時刻関連の sdfType が sdfType 値レジストリに追加される可能性があります。
Data can be a choice of named alternatives called sdfChoice. Each alternative is identified by a name (string, key in the outer JSON map used to represent the overall choice) and a set of dataqualities (each in an inner JSON map, the value used to represent the individual alternative in the outer JSON map). Dataqualities that are specified at the same level as the sdfChoice apply to all choices in the sdfChoice except those specific choices where the dataquality is overridden at the choice level.
データは、sdfChoice と呼ばれる名前付き代替の選択肢とすることができます。各代替案は、名前 (文字列、選択全体を表すために使用される外部 JSON マップ内のキー) と一連のデータ品質 (内部 JSON マップ内のそれぞれ、外部 JSON マップ内の個々の代替案を表すために使用される値) によって識別されます。sdfChoice と同じレベルで指定されたデータ品質は、データ品質が選択レベルでオーバーライドされる特定の選択肢を除く、sdfChoice 内のすべての選択肢に適用されます。
sdfChoice merges the functions of two constructs found in [JSO7V]:
sdfChoice は、[JSO7V] にある 2 つの構造の関数をマージします。
* enum
* 列挙型
What could be expressed as:
次のように表現できるもの:
"enum": ["foo", "bar", "baz"]
in JSO, is often best represented as:
JSO では、多くの場合、次のように最もよく表されます。
"sdfChoice": {
"foo": { "description": "This is a foonly"},
"bar": { "description":
"As defined in the second world congress"},
"baz": { "description": "From bigzee foobaz"}
}
This allows the placement of other dataqualities such as description in the example.
これにより、例内の説明などの他のデータ品質を配置できるようになります。
If an enum needs to use a data type different from the text string, what would, for instance, have been:
enum でテキスト文字列とは異なるデータ型を使用する必要がある場合は、たとえば次のようになります。
"type": "number",
"enum": [1, 2, 3]
in JSO, is represented as:
JSO では次のように表されます。
"type": "number",
"sdfChoice": {
"a-better-name-for-alternative-1": { "const": 1 },
"alternative-2": { "const": 2 },
"the-third-alternative": { "const": 3 }
}
where the string names obviously would be chosen in a way that is descriptive for what these numbers actually stand for; sdfChoice also makes it easy to add number ranges into the mix.
ここで、文字列名は明らかに、これらの数字が実際に何を表すかを説明する方法で選択されます。sdfChoice を使用すると、数値範囲を混合に簡単に追加することもできます。
(Note that const can also be used for strings as in the previous example, for instance, if the actual string value is indeed a crucial element for the data model.)
(たとえば、実際の文字列値が実際にデータ モデルにとって重要な要素である場合は、前の例のように const を文字列にも使用できることに注意してください。)
* anyOf
* いずれかの
JSO provides a type union called anyOf, which provides a choice between anonymous alternatives.
JSO は、anyOf と呼ばれる型共用体を提供し、匿名の代替の選択肢を提供します。
What could have been in JSO:
JSO には何が含まれていた可能性があるか:
"anyOf": [
{"type": "array", "minItems": 3, "maxItems": "3",
"items": {"$ref": "#/sdfData/rgbVal"}},
{"type": "array", "minItems": 4, "maxItems": "4",
"items": {"$ref": "#/sdfData/cmykVal"}}
]
can be more descriptively notated in SDF as:
SDF では次のようにより説明的に表記できます。
"sdfChoice": {
"rgb": {"type": "array", "minItems": 3, "maxItems": "3",
"items": {"sdfRef": "#/sdfData/rgbVal"}},
"cmyk": {"type": "array", "minItems": 4, "maxItems": "4",
"items": {"sdfRef": "#/sdfData/cmykVal"}}
}
Note that there is no need in SDF for the type intersection construct allOf or the peculiar type-xor construct oneOf found in [JSO7V].
SDF では、[JSO7V] にある型交差構造 allOf や独特の type-xor 構造 oneOf は必要ないことに注意してください。
As a simplification for users of SDF models who are accustomed to the JSO enum keyword, this is retained, but limited to a choice of text string values, such that:
JSO enum キーワードに慣れている SDF モデルのユーザーを簡略化するために、これは保持されますが、次のようなテキスト文字列値の選択に限定されます。
"enum": ["foo", "bar", "baz"]
is syntactic sugar for:
は次の糖衣構文です。
"sdfChoice": {
"foo": { "const": "foo"},
"bar": { "const": "bar"},
"baz": { "const": "baz"}
}
In a single definition, the keyword enum cannot be used at the same time as the keyword sdfChoice, as the former is just syntactic sugar for the latter.
単一の定義では、キーワード enum をキーワード sdfChoice と同時に使用することはできません。これは、前者が後者にとって単なる構文糖であるためです。
The following SDF keywords are used to create definition groups in the target namespace. All these definitions share some common qualities as discussed in Section 4.6.
次の SDF キーワードは、ターゲット名前空間に定義グループを作成するために使用されます。これらすべての定義には、セクション 4.6 で説明したように、いくつかの共通の性質があります。
The sdfObject keyword denotes a group of zero or more sdfObject definitions. sdfObject definitions may contain or include definitions of named Properties, Actions, and Events declared for the sdfObject, as well as named data types (sdfData group) to be used in this or other sdfObjects.
sdfObject キーワードは、0 個以上の sdfObject 定義のグループを示します。sdfObject 定義には、sdfObject に対して宣言された名前付きプロパティ、アクション、およびイベントの定義、およびこの sdfObject または他の sdfObject で使用される名前付きデータ型 (sdfData グループ) が含まれる場合があります。
The qualities of an sdfObject include the common qualities; additional qualities are shown in Table 6. None of these qualities are required or have default values that are assumed if the quality is absent.
sdfObject の品質には、共通の品質が含まれます。追加の品質を表 6 に示します。これらの品質はいずれも必須ではなく、品質が存在しない場合に想定されるデフォルト値もありません。
+=============+===========+================================+
| Quality | Type | Description |
+=============+===========+================================+
| (common) | | Section 4.6 |
+-------------+-----------+--------------------------------+
| sdfProperty | property | zero or more named property |
| | | definitions for this sdfObject |
+-------------+-----------+--------------------------------+
| sdfAction | action | zero or more named action |
| | | definitions for this sdfObject |
+-------------+-----------+--------------------------------+
| sdfEvent | event | zero or more named event |
| | | definitions for this sdfObject |
+-------------+-----------+--------------------------------+
| sdfData | named-sdq | zero or more named data type |
| | | definitions that might be used |
| | | in the above |
+-------------+-----------+--------------------------------+
| minItems | number | (array) minimum number of |
| | | multiplied affordances in |
| | | array |
+-------------+-----------+--------------------------------+
| maxItems | number | (array) maximum number of |
| | | multiplied affordances in |
| | | array |
+-------------+-----------+--------------------------------+
Table 6: Qualities of sdfObject
表 6: sdfObject の品質
The sdfProperty keyword denotes a group of zero or more Property definitions.
sdfProperty キーワードは、0 個以上のプロパティ定義のグループを示します。
Properties are used to model elements of state.
プロパティは状態の要素をモデル化するために使用されます。
The qualities of a Property definition include the data qualities (and thus the common qualities); see Section 4.7. Additional qualities are shown in Table 7.
プロパティ定義の品質には、データ品質 (したがって共通の品質) が含まれます。セクション 4.7 を参照してください。追加の品質を表 7 に示します。
+============+=========+===============================+=========+
| Quality | Type | Description | Default |
+============+=========+===============================+=========+
| (data) | | Section 4.7 | |
+------------+---------+-------------------------------+---------+
| readable | boolean | Reads are allowed | true |
+------------+---------+-------------------------------+---------+
| writable | boolean | Writes are allowed | true |
+------------+---------+-------------------------------+---------+
| observable | boolean | Flag to indicate asynchronous | true |
| | | notification is available | |
+------------+---------+-------------------------------+---------+
Table 7: Qualities of sdfProperty
表 7: sdfProperty の品質
The sdfAction keyword denotes a group of zero or more Action definitions.
sdfAction キーワードは、0 個以上のアクション定義のグループを示します。
Actions are used to model commands and methods that are invoked. Actions may have parameter data that is supplied upon invocation and output data that is provided as a direct result of the invocation of the action (note that "action objects" may also be created to furnish ongoing information during a long-running action; these would be pointed to by the output data).
アクションは、呼び出されるコマンドとメソッドをモデル化するために使用されます。アクションには、呼び出し時に提供されるパラメータ データと、アクションの呼び出しの直接の結果として提供される出力データが含まれる場合があります (長時間実行されるアクション中に進行中の情報を提供するために「アクション オブジェクト」も作成される場合があることに注意してください。これらは出力データによってポイントされます)。
The qualities of an Action definition include the common qualities. Additional qualities are shown in Table 8. None of these qualities are required or have default values that are assumed if the quality is absent.
アクション定義の品質には、共通の品質が含まれます。追加の品質を表 8 に示します。これらの品質はいずれも必須ではなく、品質が存在しない場合に想定されるデフォルト値もありません。
+===============+===========+============================+
| Quality | Type | Description |
+===============+===========+============================+
| (common) | | Section 4.6 |
+---------------+-----------+----------------------------+
| sdfInputData | map | data qualities of the |
| | | input data for an Action |
+---------------+-----------+----------------------------+
| sdfOutputData | map | data qualities of the |
| | | output data for an Action |
+---------------+-----------+----------------------------+
| sdfData | named-sdq | zero or more named data |
| | | type definitions that |
| | | might be used in the above |
+---------------+-----------+----------------------------+
Table 8: Qualities of sdfAction
表 8: sdfAction の品質
sdfInputData defines the input data of the action. sdfOutputData defines the output data of the action. As discussed in Section 2.2.3, a set of data qualities with type "object" can be used to substructure either data item, with optionality indicated by the data quality required.
sdfInputData はアクションの入力データを定義します。sdfOutputData は、アクションの出力データを定義します。セクション 2.2.3 で説明したように、「オブジェクト」タイプのデータ品質のセットは、必要なデータ品質によって示されるオプションを使用して、いずれかのデータ項目を下位構造化するために使用できます。
The sdfEvent keyword denotes zero or more Event definitions.
sdfEvent キーワードは、0 個以上のイベント定義を示します。
Events are used to model asynchronous occurrences that may be communicated proactively. Events have data elements that are communicated upon the occurrence of the event.
イベントは、プロアクティブに通信できる非同期の発生をモデル化するために使用されます。イベントには、イベントの発生時に通信されるデータ要素があります。
The qualities of sdfEvent include the common qualities. Additional qualities are shown in Table 9. None of these qualities are required or have default values that are assumed if the quality is absent.
sdfEvent の品質には、共通の品質が含まれます。追加の品質を表 9 に示します。これらの品質はいずれも必須ではなく、品質が存在しない場合に想定されるデフォルト値もありません。
+===============+===========+============================+
| Quality | Type | Description |
+===============+===========+============================+
| (common) | | Section 4.6 |
+---------------+-----------+----------------------------+
| sdfOutputData | map | data qualities of the |
| | | output data for an Event |
+---------------+-----------+----------------------------+
| sdfData | named-sdq | zero or more named data |
| | | type definitions that |
| | | might be used in the above |
+---------------+-----------+----------------------------+
Table 9: Qualities of sdfEvent
表 9: sdfEvent の品質
sdfOutputData defines the output data of the action. As discussed in Section 2.2.4, a set of data qualities with type "object" can be used to substructure the output data item, with optionality indicated by the data quality required.
sdfOutputData は、アクションの出力データを定義します。セクション 2.2.4 で説明したように、「オブジェクト」タイプのデータ品質のセットは、必要なデータ品質によって示されるオプションを使用して、出力データ項目を部分構造化するために使用できます。
The sdfData keyword denotes a group of zero or more named data type definitions (named-sdq).
sdfData キーワードは、0 個以上の名前付きデータ型定義 (named-sdq) のグループを示します。
An sdfData definition provides a reusable semantic identifier for a type of data item and describes the constraints on the defined type. sdfData is not itself a declaration, so it does not cause any of these data items to be included in an affordance definition.
sdfData 定義は、データ項目のタイプに再利用可能な意味識別子を提供し、定義されたタイプの制約を記述します。sdfData 自体は宣言ではないため、これらのデータ項目がアフォーダンス定義に含まれることはありません。
The qualities of sdfData include the data qualities (and thus the common qualities); see Section 4.7.
sdfData の品質には、データ品質 (したがって共通の品質) が含まれます。セクション 4.7 を参照してください。
The requirements for high-level composition include the following:
高レベルの構成の要件には次のものが含まれます。
* The ability to represent products, standardized product types, and modular products while maintaining the atomicity of sdfObjects.
* sdfObject の原子性を維持しながら、製品、標準化された製品タイプ、およびモジュール製品を表現する機能。
* The ability to compose a reusable definition block from sdfObjects. Example: a single plug unit of an outlet strip with sdfObjects for on/off control, energy monitor, and optional dimmer, while retaining the atomicity of the individual sdfObjects.
* sdfObject から再利用可能な定義ブロックを構成する機能。例: 個々の sdfObject のアトミック性を維持しながら、オン/オフ制御、エネルギー モニター、およびオプションの調光器用の sdfObject を備えたコンセント ストリップの単一プラグ ユニット。
* The ability to compose sdfObjects and other definition blocks into a higher level sdfThing that represents a product, while retaining the atomicity of sdfObjects.
* sdfObject のアトミック性を維持しながら、sdfObject とその他の定義ブロックを製品を表す高レベルの sdfThing に合成する機能。
* The ability to enrich and refine a base definition to have product-specific qualities and quality values, such as unit, range, and scale settings.
* 基本定義を強化および改良して、単位、範囲、スケール設定などの製品固有の品質と品質値を持たせる機能。
* The ability to reference items in one part of a complex definition from another part of the same definition. Example: summarizing the energy readings from all plugs in an outlet strip.
* 複雑な定義のある部分にある項目を、同じ定義の別の部分から参照する機能。例: コンセント ストリップのすべてのプラグからのエネルギー測定値を要約します。
The model namespace is organized according to terms that are defined in the SDF documents that contribute to the namespace. For example, definitions that originate from an organization or vendor are expected to be in a namespace that is specific to that organization or vendor.
モデル名前空間は、名前空間に寄与する SDF ドキュメントで定義されている用語に従って編成されます。たとえば、組織またはベンダーから作成された定義は、その組織またはベンダーに固有の名前空間に存在することが期待されます。
The structure of a path in a namespace is defined by the JSON Pointers to the definitions in the SDF documents in that namespace. For example, if there is an SDF document defining an sdfObject "Switch" with an action "on", then the reference to the action would be "ns:#/sdfObject/Switch/sdfAction/on", where ns is the namespace prefix (short name for the namespace).
名前空間内のパスの構造は、その名前空間内の SDF ドキュメント内の定義への JSON ポインターによって定義されます。たとえば、アクション「on」を持つ sdfObject「Switch」を定義する SDF ドキュメントがある場合、アクションへの参照は「ns:#/sdfObject/Switch/sdfAction/on」になります。ここで、ns は名前空間プレフィックス (名前空間の短縮名) です。
Modular composition of definitions enables an existing definition (which could be in the same or another SDF document) to become part of a new definition by including a reference to the existing definition within the model namespace.
定義のモジュール構成により、モデル名前空間内の既存の定義への参照を含めることで、既存の定義 (同じまたは別の SDF ドキュメント内にある可能性がある) を新しい定義の一部にすることができます。
An existing definition may be used as a template for a new definition, that is, a new definition is created in the target namespace that uses the defined qualities of some existing definition. This pattern uses the keyword sdfRef as a quality of a new definition with a value consisting of a reference to the existing definition that is to be used as a template.
既存の定義は、新しい定義のテンプレートとして使用できます。つまり、一部の既存の定義の定義された品質を使用する新しい定義がターゲット名前空間に作成されます。このパターンは、テンプレートとして使用される既存の定義への参照で構成される値を持つ新しい定義の品質としてキーワード sdfRef を使用します。
In the definition that uses sdfRef, new qualities may be added and existing qualities from the referenced definition may be overridden. (Note that JSON maps do not have a defined order, so the SDF processor may see these overrides before seeing the sdfRef.)
sdfRef を使用する定義では、新しい品質を追加したり、参照された定義の既存の品質をオーバーライドしたりできます。(JSON マップには定義された順序がないため、SDF プロセッサは sdfRef を確認する前にこれらのオーバーライドを確認する可能性があることに注意してください。)
Note that the definition referenced by sdfRef might contain qualities or definitions that are not valid in the context where the sdfRef is used. In this case, the resulting model, when resolved, may be invalid. Example: an sdfRef adds an sdfThing definition in an sdfObject definition.
sdfRef によって参照される定義には、sdfRef が使用されるコンテキストでは無効な品質または定義が含まれる可能性があることに注意してください。この場合、結果として得られるモデルは、解決されたときに無効になる可能性があります。例: sdfRef は、sdfObject 定義に sdfThing 定義を追加します。
As a convention, overrides are intended to be used only for further restricting the allowable set of data values. Such a usage is shown in Figure 5: any value allowable for a cable-length is also an allowable value for a length, with the additional restriction that the length cannot be smaller than 5 cm. (This is labeled as a convention as it cannot be checked in the general case. A quality of implementation consideration for a tool might be to provide at least some form of checking.) Note that the example provides a description that overrides the description of the referenced definition; as this quality is intended for human consumption, there is no conflict with the intended goal.
慣例として、オーバーライドは、許容されるデータ値のセットをさらに制限するためにのみ使用することを目的としています。このような使用法を図 5 に示します。ケーブル長に許容される値はすべて長さにも許容されますが、長さは 5 cm より小さくすることはできないという追加の制限があります。(一般的なケースではチェックできないため、これは規則としてラベル付けされています。ツールの実装の品質に関する考慮事項は、少なくとも何らかの形式のチェックを提供することかもしれません。) この例では、参照される定義の説明をオーバーライドする説明が提供されていることに注意してください。この品質は人間の消費を目的としているため、意図された目的と矛盾することはありません。
"sdfData":
"length" : {
"type": "number",
"minimum": 0,
"unit": "m"
"description": "There can be no negative lengths."
}
...
"cable-length" : {
"sdfRef": "#/sdfData/length"
"minimum": 5e-2,
"description": "Cables must be at least 5 cm."
}
Figure 5: Using an Override to Further Restrict the Set of Data Values
図 5: オーバーライドを使用してデータ値のセットをさらに制限する
An sdfThing is a set of declarations and qualities that may be part of a more complex model. For example, the sdfObject declarations that make up the definition of a single socket of an outlet strip could be encapsulated in an sdfThing, which itself could be used in a declaration in the sdfThing definition for the outlet strip. (See Figure 7 in Appendix D.1 for parts of an SDF model for this example.)
sdfThing は、より複雑なモデルの一部となる宣言と品質のセットです。たとえば、コンセント ストリップの 1 つのソケットの定義を構成する sdfObject 宣言を sdfThing にカプセル化することができ、それ自体をコンセント ストリップの sdfThing 定義内の宣言で使用できます。(この例の SDF モデルの一部については、付録 D.1 の図 7 を参照してください。)
sdfThing definitions carry semantic meaning, such as a defined refrigerator compartment and a defined freezer compartment, making up a combination refrigerator-freezer product. An sdfThing may be composed of sdfObjects and other sdfThings. It can also contain sdfData definitions, as well as declarations of interaction affordances itself, such as a status (on/off) for the refrigerator-freezer as a whole (see Figure 8 in Appendix D.2 for an example SDF model illustrating these aspects).
sdfThing 定義には、冷蔵庫と冷凍庫の組み合わせ製品を構成する、定義された冷蔵室と定義された冷凍室などの意味論的な意味が含まれています。sdfThing は、sdfObject と他の sdfThing で構成される場合があります。また、sdfData 定義だけでなく、冷蔵庫/冷凍庫全体のステータス (オン/オフ) などのインタラクション アフォーダンス自体の宣言も含めることができます (これらの側面を示す SDF モデルの例については、付録 D.2 の図 8 を参照してください)。
The qualities of sdfThing are shown in Table 10. None of these qualities are required or have default values that are assumed if the quality is absent. Analogous to sdfObject, the presence of one or both of the optional qualities "minItems" and "maxItems" defines the sdfThing as an array.
sdfThing の品質を表 10 に示します。これらの品質はいずれも必須ではなく、品質がない場合に想定されるデフォルト値もありません。sdfObject と同様に、オプションの品質「minItems」と「maxItems」の一方または両方が存在すると、sdfThing が配列として定義されます。
+=============+===========+=============================+
| Quality | Type | Description |
+=============+===========+=============================+
| (common) | | Section 4.6 |
+-------------+-----------+-----------------------------+
| sdfThing | thing | |
+-------------+-----------+-----------------------------+
| sdfObject | object | |
+-------------+-----------+-----------------------------+
| sdfProperty | property | zero or more named property |
| | | definitions for this thing |
+-------------+-----------+-----------------------------+
| sdfAction | action | zero or more named action |
| | | definitions for this thing |
+-------------+-----------+-----------------------------+
| sdfEvent | event | zero or more named event |
| | | definitions for this thing |
+-------------+-----------+-----------------------------+
| sdfData | named-sdq | zero or more named data |
| | | type definitions that might |
| | | be used in the above |
+-------------+-----------+-----------------------------+
| minItems | number | (array) minimum number of |
| | | multiplied affordances in |
| | | array |
+-------------+-----------+-----------------------------+
| maxItems | number | (array) maximum number of |
| | | multiplied affordances in |
| | | array |
+-------------+-----------+-----------------------------+
Table 10: Qualities of sdfThing
表 10: sdfThing の品質
IANA has added the following Media-Type to the "Media Types" registry [IANA.media-types].
IANA は、次のメディア タイプを「メディア タイプ」レジストリ [IANA.media-types] に追加しました。
+==========+======================+=======================+
| Name | Template | Reference |
+==========+======================+=======================+
| sdf+json | application/sdf+json | RFC 9880, Section 7.1 |
+----------+----------------------+-----------------------+
Table 11: Media Type Registration for SDF
表 11: SDF のメディア タイプの登録
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
sdf+json
SDF+JSON
Required parameters:
必須パラメータ:
N/A
該当なし
Optional parameters:
オプションのパラメータ:
N/A
該当なし
Encoding considerations:
エンコーディングに関する考慮事項:
binary (JSON is UTF-8-encoded text)
バイナリ (JSON は UTF-8 でエンコードされたテキスト)
Security considerations:
セキュリティに関する考慮事項:
Section 8 of RFC 9880
RFC 9880 のセクション 8
Interoperability considerations:
相互運用性に関する考慮事項:
none
なし
Published specification:
公開された仕様:
Section 7.1 of RFC 9880
RFC 9880 のセクション 7.1
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Tools for data and interaction modeling in the Internet of Things and related environments.
モノのインターネットおよび関連環境におけるデータおよびインタラクション モデリングのためのツール。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
A JSON Pointer fragment identifier may be used as defined in Section 6 of [RFC6901].
JSON ポインタ フラグメント識別子は、[RFC6901] のセクション 6 で定義されているように使用できます。
Additional information:
追加情報：
Magic number(s):
マジックナンバー:
n/a
該当なし
File extension(s):
ファイル拡張子:
.sdf.json
.sdf.json
Windows Clipboard Name:
Windows クリップボード名:
"Semantic Definition Format (SDF) for Data and Interactions of Things"
「データとモノの相互作用のためのセマンティック定義フォーマット (SDF)」
Macintosh file type code(s):
Macintosh ファイルタイプコード:
n/a
該当なし
Macintosh Universal Type Identifier code:
Macintosh ユニバーサル タイプ識別コード:
org.ietf.sdf-json conforms to public.text
org.ietf.sdf-json は public.text に準拠します
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
ASDF WG mailing list (asdf@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)
ASDF WG メーリング リスト (asdf@ietf.org) または IETF アプリケーションおよびリアルタイム領域 (art@ietf.org)
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
Provisional registration:
仮登録：
no
いいえ
IANA has added the following Content-Format to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.core-parameters].
IANA は、「制約付き RESTful 環境 (CoRE) パラメーター」レジストリ グループ [IANA.core-parameters] 内の「CoAP Content-Formats」レジストリに次の Content-Format を追加しました。
+======================+================+=====+===========+
| Content Type | Content Coding | ID | Reference |
+======================+================+=====+===========+
| application/sdf+json | - | 434 | RFC 9880 |
+----------------------+----------------+-----+-----------+
Table 12: SDF Content-Format Registration
表 12: SDF コンテンツ形式の登録
IANA has registered the following value in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry in [IANA.params], following the template in [BCP73]:
IANA は、[BCP73] のテンプレートに従って、[IANA.params] の「登録されたプロトコル パラメーター識別子の IETF URN サブ名前空間」レジストリに次の値を登録しました。
Registry name:
レジストリ名:
unit
ユニット
Specification:
仕様：
RFC 9880
RFC 9880
Repository:
リポジトリ:
Combining the symbol values from the "SenML Units" registry and the "Secondary Units" registry in the "Sensor Measurement Lists (SenML)" registry group [IANA.senml] as specified by Sections 4.5.2 and 12.1 of [RFC8428] and Section 3 of [RFC8798], respectively (which, by the registration policy, are guaranteed to be non-overlapping).
[RFC8428] のセクション 4.5.2 と 12.1、および [RFC8798] のセクション 3 でそれぞれ指定されているように、「Sensor Measurement Lists (SenML)」レジストリ グループ [IANA.senml] 内の「SenML Units」レジストリと「Secondary Units」レジストリのシンボル値を結合します (これらは、登録ポリシーによって保証されています)。重複しない）。
Index value:
インデックス値:
Percent-encoding (Section 2.1 of RFC 3986 [STD66]) is required of any characters in unit names except for the set "unreserved" (Section 2.3 of RFC 3986 [STD66]), the set "sub-delims" (Section 2.2 of RFC 3986 [STD66]), and ":" or "@" (i.e., the result must match the ABNF rule "pchar" in Section 3.3 of RFC 3986 [STD66]).
パーセントエンコーディング (RFC 3986 [STD66] のセクション 2.1) は、セット "unreserved" (RFC 3986 [STD66] のセクション 2.3)、セット "sub-delims" (RFC 3986 [STD66] のセクション 2.2)、および ":" または "@" (つまり、結果はRFC 3986 [STD66] のセクション 3.3 の ABNF ルール「pchar」に一致します)。
IANA has added the following note to the "Sensor Measurement Lists (SenML)" registry group [IANA.senml]:
IANA は、「Sensor Measurement Lists (SenML)」レジストリ グループ [IANA.senml] に次のメモを追加しました。
In SDF [RFC9880], a URI unit name is distinguished from a registered unit name by the presence of a colon; any registered unit name that contains a colon can therefore not be directly used in SDF.
SDF [RFC9880] では、URI ユニット名はコロンの存在によって登録されたユニット名と区別されます。したがって、コロンを含む登録ユニット名は SDF で直接使用できません。
IANA has created the "Semantic Definition Format (SDF)" registry group with the registries defined in this Section.
IANA は、このセクションで定義されているレジストリを含む「Semantic Definition Format (SDF)」レジストリ グループを作成しました。
IANA has created the "SDF Quality Names" registry in the "Semantic Definition Format (SDF)" registry group with the following template:
IANA は、次のテンプレートを使用して、「Semantic Definition Format (SDF)」レジストリ グループに「SDF Quality Names」レジストリを作成しました。
Name:
名前：
A Quality Name composed of ASCII letters, digits, and dollar signs, starting with a lowercase ASCII letter or a dollar sign (i.e., using a pattern of "[a-z$][A-Za-z$0-9]*").
小文字の ASCII 文字またはドル記号で始まる、ASCII 文字、数字、およびドル記号で構成される品質名 (つまり、「[a-z$][A-Za-z$0-9]*」のパターンを使用)。
Brief Description:
簡単な説明:
A brief description.
簡単な説明。
Reference:
参照：
A pointer to a specification.
仕様へのポインタ。
Change Controller:
コントローラを変更します:
(See Section 2.3 of RFC 8126 [BCP26])
(RFC 8126 [BCP26] のセクション 2.3 を参照)
Quality Names in this registry are intended to be registered in conjunction with RFCs and activities of the IETF.
このレジストリの品質名は、RFC および IETF の活動と関連して登録されることを目的としています。
The registration policy is Specification Required as per Section 4.6 of RFC 8126 [BCP26]. Note that the policy is not "RFC Required" or "IETF Review" (Sections 4.7 and 4.8 of RFC 8126 [BCP26]) so that registrations can be made earlier in the process, even earlier than foreseen in [BCP100].)
登録ポリシーは、RFC 8126 [BCP26] のセクション 4.6 に従って要求される仕様です。このポリシーは「RFC 必須」または「IETF レビュー」(RFC 8126 [BCP26] のセクション 4.7 および 4.8) ではないことに注意してください。そのため、[BCP100] で予想されているよりも早く、プロセスの早い段階で登録を行うことができます。)
The instructions to the Experts are:
専門家への指示は次のとおりです。
* to ascertain that the specification is available in an immutable reference and has achieved a good level of review in conjunction with RFCs or activities of the IETF, and
* 仕様が不変の参照として利用可能であり、RFC または IETF の活動と関連して良好なレベルのレビューを達成していることを確認するため、および
* to be frugal in the allocation of Quality Names that are suggestive of generally applicable semantics, keeping them in reserve for qualities that are likely to enjoy wide use and can make good use of their conciseness.
* 一般に適用可能なセマンティクスを示唆する品質名の割り当てを倹約し、広く使用される可能性が高く、その簡潔さを有効に活用できる品質のために確保しておきます。
The "SDF Quality Names" registry starts out as in Table 13; all references for these initial entries are to RFC 9880 (this document) and all change controllers are "IETF".
「SDF 品質名」レジストリは表 13 のように始まります。これらの初期エントリの参照はすべて RFC 9880 (この文書) であり、すべての変更コントローラは「IETF」です。
+======================+==========================================+
| Name | Brief Description |
+======================+==========================================+
| $comment | source code comments only, no semantics |
+----------------------+------------------------------------------+
| const | constant value |
+----------------------+------------------------------------------+
| contentFormat | content format |
+----------------------+------------------------------------------+
| default | default value |
+----------------------+------------------------------------------+
| description | long description text |
+----------------------+------------------------------------------+
| enum | sdfChoice limited to text strings |
+----------------------+------------------------------------------+
| exclusiveMaximum | exclusive maximum for a number |
+----------------------+------------------------------------------+
| exclusiveMinimum | exclusive minimum for a number |
+----------------------+------------------------------------------+
| format | specific format for a text string |
+----------------------+------------------------------------------+
| items | items of an array |
+----------------------+------------------------------------------+
| label | short text (no constraints); defaults to |
| | key |
+----------------------+------------------------------------------+
| maxItems | maximum number of items in an array |
+----------------------+------------------------------------------+
| maxLength | maximum length for a text string (in |
| | characters, i.e., Unicode scalar values) |
+----------------------+------------------------------------------+
| maximum | maximum for a number |
+----------------------+------------------------------------------+
| minItems | minimum number of items in an array |
+----------------------+------------------------------------------+
| minLength | minimum length for a text string (in |
| | characters, i.e., Unicode scalar values) |
+----------------------+------------------------------------------+
| minimum | minimum for a number |
+----------------------+------------------------------------------+
| multipleOf | step size of number |
+----------------------+------------------------------------------+
| nullable | boolean: can the item be left out? |
+----------------------+------------------------------------------+
| observable | boolean: can the item be observed? |
+----------------------+------------------------------------------+
| pattern | regular expression pattern for a text |
| | string |
+----------------------+------------------------------------------+
| properties | named dataqualities for type="object" |
+----------------------+------------------------------------------+
| readable | boolean: can the item be read? |
+----------------------+------------------------------------------+
| required | which data items are required? |
+----------------------+------------------------------------------+
| sdfChoice | named dataqualities for a choice |
+----------------------+------------------------------------------+
| sdfData | named dataqualities for an independent |
| | data type definition |
+----------------------+------------------------------------------+
| sdfInputData | input data to an action |
+----------------------+------------------------------------------+
| sdfOutputData | output data of an action or event |
| | (sdfRequired applies here) |
+----------------------+------------------------------------------+
| sdfRef | sdf-pointer to definition being |
| | referenced |
+----------------------+------------------------------------------+
| sdfRequired | pointer-list to declarations of required |
| | components |
+----------------------+------------------------------------------+
| sdfRequiredInputData | pointer-list to declarations of required |
| | input data for an action |
+----------------------+------------------------------------------+
| sdfType | more detailed information about the type |
| | of a string |
+----------------------+------------------------------------------+
| type | general category of data type |
+----------------------+------------------------------------------+
| uniqueItems | boolean: do the items of the array need |
| | to be all different? |
+----------------------+------------------------------------------+
| unit | engineering unit and scale (per SenML |
| | registry) |
+----------------------+------------------------------------------+
| writable | boolean: can the item be written to? |
+----------------------+------------------------------------------+
Table 13: Initial Content of the SDF Quality Names Registry
表 13: SDF 品質名レジストリの初期内容
IANA has created the "SDF Quality Name Prefixes" registry in the "Semantic Definition Format (SDF)" registry group with the following template:
IANA は、次のテンプレートを使用して、「Semantic Definition Format (SDF)」レジストリ グループに「SDF Quality Name Prefixes」レジストリを作成しました。
Prefix:
プレフィックス:
A Quality Name prefix composed of lowercase ASCII letters and digits, starting with a lowercase ASCII letter (i.e., using a pattern of "[a-z][a-z0-9]*").
小文字の ASCII 文字で始まる、小文字の ASCII 文字と数字で構成される品質名のプレフィックス (つまり、「[a-z][a-z0-9]*」のパターンを使用)。
Contact:
接触：
A contact point for the organization that assigns Quality Names with this prefix.
このプレフィックスが付いた品質名を割り当てる組織の連絡先。
Reference:
参照：
A pointer to additional information, if available.
追加情報へのポインタ (利用可能な場合)。
Quality Name Prefixes are intended to be registered by organizations that plan to define Quality Names constructed with an organization-specific prefix (Section 2.3.3).
品質名プレフィックスは、組織固有のプレフィックスで構築された品質名を定義することを計画している組織によって登録されることを目的としています (セクション 2.3.3)。
The registration policy is Expert Review as per Section 4.5 of RFC 8126 [BCP26]. The instructions to the Expert are to ascertain that the organization will handle Quality Names constructed using their prefix in a way that roughly achieves the objectives for an IANA registry that supports interoperability of SDF models employing these Quality Names, including:
登録ポリシーは、RFC 8126 [BCP26] のセクション 4.5 に従った専門家レビューです。専門家への指示は、プレフィックスを使用して構築された品質名を、これらの品質名を使用する SDF モデルの相互運用性をサポートする IANA レジストリの目的を大まかに達成する方法で組織が処理することを確認することです。
* Stability, "stable and permanent";
* 安定性、「安定かつ永続的」。
* Transparency, "readily available" and "in sufficient detail" (Section 4.6 of RFC 8126 [BCP26]).
* 透明性、「すぐに利用可能」かつ「十分な詳細」 (RFC 8126 [BCP26] のセクション 4.6)。
The "SDF Quality Name Prefixes" registry is empty at this time.
現時点では、「SDF 品質名プレフィックス」レジストリは空です。
IANA has created the "sdfType Values" registry in the "Semantic Definition Format (SDF)" registry group with the following template:
IANA は、次のテンプレートを使用して、「Semantic Definition Format (SDF)」レジストリ グループに「sdfType Values」レジストリを作成しました。
Name:
名前：
A name composed of lowercase ASCII letters, digits and - (ASCII hyphen/minus) characters, starting with a lowercase ASCII letter (i.e., using a pattern of "[a-z][-a-z0-9]*").
小文字の ASCII 文字、数字、および - (ASCII ハイフン/マイナス) 文字で構成され、小文字の ASCII 文字で始まる名前 (つまり、「[a-z][-a-z0-9]*」のパターンを使用)。
Description:
説明：
A short description of the information model level structure and semantics.
情報モデルのレベル構造とセマンティクスの簡単な説明。
type:
タイプ：
The value of the quality "type" to be used with this sdfType.
この sdfType で使用される品質「タイプ」の値。
JSON Representation:
JSON 表現:
A short description of a JSON representation that can be used for this sdfType. As per Section 4.7.1, this MUST be consistent with the type.
この sdfType に使用できる JSON 表現の短い説明。セクション 4.7.1 に従って、これはタイプと一致していなければなりません (MUST)。
Reference:
参照：
A more detailed specification of meaning and use of sdfType.
sdfType の意味と使用法の詳細な仕様。
sdfType values are intended to be registered to enable modeling additional SDF-specific types (see Section 4.7.1).
sdfType 値は、追加の SDF 固有の型をモデル化できるように登録することを目的としています (セクション 4.7.1 を参照)。
The registration policy is Specification Required as per Section 4.6 of RFC 8126 [BCP26]. The instructions to the Expert are to ascertain that the specification provides enough detail to enable interoperability between implementations of the sdfType being registered, and that names are chosen with enough specificity that ecosystem-specific sdfTypes will not be confused with more generally applicable ones.
登録ポリシーは、RFC 8126 [BCP26] のセクション 4.6 に従って要求される仕様です。専門家への指示は、登録される sdfType の実装間の相互運用性を可能にするのに十分な詳細が仕様に記載されていること、およびエコシステム固有の sdfType がより一般的に適用可能なものと混同されないように十分な特異性を持って名前が選択されていることを確認することです。
The initial set of registrations is described in Table 5.
初期の登録セットを表 5 に示します。
IANA has created the "SDF Feature Names" registry in the "Semantic Definition Format (SDF)" registry group with the following template:
IANA は、次のテンプレートを使用して、「Semantic Definition Format (SDF)」レジストリ グループに「SDF Feature Names」レジストリを作成しました。
Name:
名前：
A feature name composed of ASCII letters, digits, and dollar signs, starting with a lowercase ASCII letter or a dollar sign (i.e., using a pattern of "[a-z$][A-Za-z$0-9]*").
小文字の ASCII 文字またはドル記号で始まる、ASCII 文字、数字、およびドル記号で構成される機能名 (つまり、「[a-z$][A-Za-z$0-9]*」のパターンを使用)。
Brief Description:
簡単な説明:
A brief description.
簡単な説明。
Reference:
参照：
A pointer to a specification.
仕様へのポインタ。
Change Controller:
コントローラを変更します:
(See Section 2.3 of RFC 8126 [BCP26])
(RFC 8126 [BCP26] のセクション 2.3 を参照)
The registration policy is Specification Required as per Section 4.6 of RFC 8126 [BCP26].
登録ポリシーは、RFC 8126 [BCP26] のセクション 4.6 に従って要求される仕様です。
The instructions to the Experts are:
専門家への指示は次のとおりです。
* to ascertain that the specification is available in an immutable reference and has achieved a good level of review, and
* 仕様が不変の参照で利用可能であり、十分なレベルのレビューに達していることを確認するため、および
* to be frugal in the allocation of feature names that are suggestive of generally applicable semantics, keeping them in reserve for features that are likely to enjoy wide use and can make good use of their conciseness.
* 一般に適用可能なセマンティクスを示唆する機能名の割り当ては倹約し、広く使用される可能性が高く、その簡潔さを有効に活用できる機能のために確保しておきます。
The "SDF Feature Names" registry is empty at this time.
現時点では、「SDF 機能名」レジストリは空です。
Some wider security considerations applicable to Things are discussed in [RFC8576].
モノに適用できる広範なセキュリティに関する考慮事項が [RFC8576] で議論されています。
Section 5 of [RFC8610] gives an overview over security considerations that arise when formal description techniques are used to govern interoperability; analogs of these security considerations can apply to SDF.
[RFC8610] のセクション 5 では、相互運用性を管理するために形式的記述技術が使用される場合に生じるセキュリティに関する考慮事項の概要が説明されています。これらのセキュリティ上の考慮事項の類似点は、SDF にも適用できます。
The security considerations of underlying building blocks such as those detailed in Section 10 of RFC 3629 [STD63] apply.
RFC 3629 [STD63] のセクション 10 に詳述されているような、基礎となるビルディング ブロックのセキュリティに関する考慮事項が適用されます。
SDF uses JSON as a representation language. For a number of cases, [STD90] indicates that implementation behavior for certain constructs allowed by the JSON grammar is unpredictable.
SDF は表現言語として JSON を使用します。多くの場合、[STD90] は、JSON 文法で許可されている特定の構造の実装動作が予測できないことを示しています。
Implementations need to be robust against invalid or unpredictable cases on input, preferably by rejecting input that is invalid or that would lead to unpredictable behavior, and avoid generating these cases on output.
実装は、入力時の無効または予測不可能なケースに対して堅牢である必要があります。できれば、無効な入力や予測不可能な動作を引き起こす可能性のある入力を拒否し、出力時にこれらのケースが生成されないようにします。
Implementations of model languages may also exhibit performance-related availability issues when the attacker can control the input, see Section 4.1 of [RFC9535] for a brief discussion and Section 8 of [RFC9485] for considerations specific to the use of pattern.
モデル言語の実装では、攻撃者が入力を制御できる場合、パフォーマンス関連の可用性の問題が発生する可能性があります。簡単な説明については [RFC9535] のセクション 4.1 を、パターンの使用に特有の考慮事項については [RFC9485] のセクション 8 を参照してください。
SDF may be used in two processes that are often security relevant: (1) model-based _validation_ of data that is intended to be described by SDF models, and (2) model-based _augmentation_ of these data with information obtained from the SDF models that apply.
SDF は、多くの場合セキュリティに関連する 2 つのプロセスで使用できます。(1) SDF モデルによって記述されるデータのモデルベースの「検証」、および (2) 適用される SDF モデルから取得した情報によるこれらのデータのモデルベースの「拡張」。
Implementations need to ascertain the provenance (and thus authenticity and integrity) and applicability of the SDF models they employ operationally in such security-relevant ways. Implementations that make use of the composition mechanisms defined in this document need to do this for each of the components they combine into the SDF models they employ. Essentially, this process needs to undergo the same care and scrutiny as any other introduction of source code into a build environment; the possibility of supply-chain attacks on the modules imported needs to be considered.
実装では、セキュリティ関連の方法で運用上使用する SDF モデルの出所 (したがって、信頼性と完全性) と適用可能性を確認する必要があります。このドキュメントで定義されている合成メカニズムを利用する実装では、使用する SDF モデルに結合するコンポーネントごとにこれを行う必要があります。基本的に、このプロセスは、ビルド環境へのソース コードの他の導入と同じ注意と精査を受ける必要があります。輸入されたモジュールに対するサプライチェーン攻撃の可能性を考慮する必要があります。
Specifically, implementations might rely on model-based input validation for enforcing certain characteristics of the data structure ingested (which, if not validated, could lead to malfunctions such as crashes and remote code execution). These implementations need to be particularly careful about the data models they apply, including their provenance and potential changes of these characteristics that upgrades to the referenced modules may (inadvertently or as part of an attack) cause. More generally speaking, implementations should strive to be robust against expected and unexpected limitations of the model-based input validation mechanisms and their implementations.
具体的には、実装は、取り込まれたデータ構造の特定の特性を強制するためにモデルベースの入力検証に依存する可能性があります (検証されていない場合、クラッシュやリモート コード実行などの誤動作につながる可能性があります)。これらの実装では、適用するデータ モデルについて、その来歴や、参照されるモジュールへのアップグレードによって (不注意または攻撃の一部として) 引き起こされる可能性のあるこれらの特性の潜在的な変更を含め、特に注意する必要があります。より一般的に言えば、実装は、モデルベースの入力検証メカニズムとその実装の予想される制限および予期せぬ制限に対して堅牢であるように努める必要があります。
Similarly, implementations that rely on model-based augmentation may generate false data from their inputs; this is an integrity violation in any case, but also can possibly be exploited for further attacks.
同様に、モデルベースの拡張に依存する実装では、入力から誤ったデータが生成される可能性があります。これはいずれの場合も整合性違反ですが、さらなる攻撃に悪用される可能性もあります。
In applications that dynamically acquire models and obtain modules from module references in these models, the security considerations of dereferenceable identifiers apply (see [DEREF-ID-PATTERN] for a more extensive discussion of dereferenceable identifiers).
動的にモデルを取得し、これらのモデル内のモジュール参照からモジュールを取得するアプリケーションでは、逆参照可能な識別子のセキュリティ上の考慮事項が適用されます (逆参照可能な識別子のより詳細な説明については、[DEREF-ID-PATTERN] を参照してください)。
There may be confidentiality requirements on SDF models, both on their content and on the fact that a specific model is used in a particular Thing or environment. The present specification does not discuss model discovery or define an access control model for SDF models, nor does it define a way to obtain selective disclosure where that may be required. It is likely that these definitions require additional context from underlying ecosystems and the characteristics of the protocols employed there; therefore, this is left as future work (e.g., for documents such as [SDF-MAPPING]).
SDF モデルには、その内容と、特定のモデルが特定のモノまたは環境で使用されるという事実の両方に関して、機密性要件が存在する場合があります。本明細書では、モデルの発見については説明せず、SDF モデルのアクセス制御モデルを定義することも、必要な場合に選択的開示を取得する方法も定義することもありません。これらの定義には、基礎となるエコシステムとそこで使用されるプロトコルの特性からの追加のコンテキストが必要になる可能性があります。したがって、これは将来の作業として残されています (たとえば、[SDF-MAPPING] などのドキュメント)。
[BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:
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>.
[BCP73] Best Current Practice 73,
<https://www.rfc-editor.org/info/bcp73>.
At the time of writing, this BCP comprises the following:
Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <https://www.rfc-editor.org/info/rfc3553>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<https://www.iana.org/assignments/core-parameters>.
[IANA.media-types]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[IANA.params]
IANA, "Uniform Resource Name (URN) Namespace for IETF
Use", <https://www.iana.org/assignments/params>.
[IANA.senml]
IANA, "Sensor Measurement Lists (SenML)",
<https://www.iana.org/assignments/senml>.
[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>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901,
DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/info/rfc6901>.
[RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396,
DOI 10.17487/RFC7396, October 2014,
<https://www.rfc-editor.org/info/rfc7396>.
[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>.
[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>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8798] Bormann, C., "Additional Units for Sensor Measurement
Lists (SenML)", RFC 8798, DOI 10.17487/RFC8798, June 2020,
<https://www.rfc-editor.org/info/rfc8798>.
[RFC9165] Bormann, C., "Additional Control Operators for the Concise
Data Definition Language (CDDL)", RFC 9165,
DOI 10.17487/RFC9165, December 2021,
<https://www.rfc-editor.org/info/rfc9165>.
[RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists
(SenML) Fields for Indicating Data Value Content-Format",
RFC 9193, DOI 10.17487/RFC9193, June 2022,
<https://www.rfc-editor.org/info/rfc9193>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
[SPDX] "SPDX License List", <https://spdx.org/licenses/>.
[STD63] Internet Standard 63,
<https://www.rfc-editor.org/info/std63>.
At the time of writing, this STD comprises the following:
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>.
[STD66] Internet Standard 66,
<https://www.rfc-editor.org/info/std66>.
At the time of writing, this STD comprises the following:
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[STD80] Internet Standard 80,
<https://www.rfc-editor.org/info/std80>.
At the time of writing, this STD comprises the following:
Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[STD90] Internet Standard 90,
<https://www.rfc-editor.org/info/std90>.
At the time of writing, this STD comprises the following:
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>.
[STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[W3C.NOTE-curie-20101216]
Birbeck, M., Ed. and S. McCarron, Ed., "CURIE Syntax 1.0",
W3C Working Group Note, 16 December 2010,
<https://www.w3.org/TR/2010/NOTE-curie-20101216/>.
[BCP100] Best Current Practice 100,
<https://www.rfc-editor.org/info/bcp100>.
At the time of writing, this BCP comprises the following:
Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[CamelCase]
"Camel Case", December 2014,
<http://wiki.c2.com/?CamelCase>.
[DEREF-ID-PATTERN]
Bormann, C. and C. Amsüss, "The "dereferenceable
identifier" pattern", Work in Progress, Internet-Draft,
draft-bormann-t2trg-deref-id-06, 30 August 2025,
<https://datatracker.ietf.org/doc/html/draft-bormann-
t2trg-deref-id-06>.
[ECMA-262] Ecma International, "ECMAScript 2025 Language
Specification", 16th Edition, ECMA Standard ECMA-262, June
2025, <https://ecma-international.org/wp-content/uploads/
ECMA-262_16th_edition_june_2025.pdf>.
[JSO4] Galiegue, F., Ed., Zyp, K., Ed., and G. Court, "JSON
Schema: core definitions and terminology", Work in
Progress, Internet-Draft, draft-zyp-json-schema-04, 31
January 2013, <https://datatracker.ietf.org/doc/html/
draft-zyp-json-schema-04>.
[JSO4V] Zyp, K. and G. Court, "JSON Schema: interactive and non
interactive validation", Work in Progress, Internet-Draft,
draft-fge-json-schema-validation-00, 31 January 2013,
<https://datatracker.ietf.org/doc/html/draft-fge-json-
schema-validation-00>.
[JSO7] Wright, A., Ed., Andrews, H., Ed., Hutton, B., Ed., and G.
Dennis, "JSON Schema: A Media Type for Describing JSON
Documents", Work in Progress, Internet-Draft, draft-
handrews-json-schema-02, 17 September 2019,
<https://datatracker.ietf.org/doc/html/draft-handrews-
json-schema-02>.
[JSO7V] Wright, A., Ed., Andrews, H., Ed., and B. Hutton, Ed.,
"JSON Schema Validation: A Vocabulary for Structural
Validation of JSON", Work in Progress, Internet-Draft,
draft-handrews-json-schema-validation-02, 17 September
2019, <https://datatracker.ietf.org/doc/html/draft-
handrews-json-schema-validation-02>.
[KebabCase]
"Kebab Case", August 2014,
<http://wiki.c2.com/?KebabCase>.
[OCF] Open Connectivity Foundation, "OCF Resource Type
Specification", Version 2.2.7, November 2023,
<https://openconnectivity.org/specs/
OCF_Resource_Type_Specification.pdf>.
[OMA] Open Mobile Alliance, "LwM2M OBJECTS",
<https://www.openmobilealliance.org/specifications/
registries/objects>.
[REST-IOT] Keränen, A., Kovatsch, M., and K. Hartke, "Guidance on
RESTful Design for Internet of Things Systems", Work in
Progress, Internet-Draft, draft-irtf-t2trg-rest-iot-17, 20
October 2025, <https://datatracker.ietf.org/doc/html/
draft-irtf-t2trg-rest-iot-17>.
[RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
Things (IoT) Security: State of the Art and Challenges",
RFC 8576, DOI 10.17487/RFC8576, April 2019,
<https://www.rfc-editor.org/info/rfc8576>.
[RFC9485] Bormann, C. and T. Bray, "I-Regexp: An Interoperable
Regular Expression Format", RFC 9485,
DOI 10.17487/RFC9485, October 2023,
<https://www.rfc-editor.org/info/rfc9485>.
[RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,
Ed., "JSONPath: Query Expressions for JSON", RFC 9535,
DOI 10.17487/RFC9535, February 2024,
<https://www.rfc-editor.org/info/rfc9535>.
[SDF-MAPPING]
Bormann, C. and J. Romann, "Semantic Definition Format
(SDF): Mapping files", Work in Progress, Internet-Draft,
draft-ietf-asdf-sdf-mapping-00, 18 December 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-asdf-
sdf-mapping-00>.
[SDFTYPE-LINK]
Bormann, C. and A. Keränen, "An sdfType for Links", Work
in Progress, Internet-Draft, draft-ietf-asdf-sdftype-link-
01, 19 December 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-asdf-
sdftype-link-01>.
[STD97] Internet Standard 97,
<https://www.rfc-editor.org/info/std97>.
At the time of writing, this STD comprises the following:
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[WoT] Kaebisch, S., Ed., McCool, M., Ed., and E. Korkan, Ed.,
"Web of Things (WoT) Thing Description 1.1",
W3C Recommendation, 5 December 2023,
<https://www.w3.org/TR/2023/REC-wot-thing-
description11-20231205/>.
[ZCL] "Chapter 6 - The ZigBee Cluster Library", Zigbee Wireless
Networking, pp. 239-271,
DOI 10.1016/b978-0-7506-8597-9.00006-9,
ISBN 9780750685979, 2008,
<https://doi.org/10.1016/b978-0-7506-8597-9.00006-9>.
This normative appendix describes the syntax of SDF using CDDL [RFC8610].
この規範的な付録では、CDDL [RFC8610] を使用した SDF の構文について説明します。
This appendix shows the framework syntax only, i.e., a syntax with liberal extension points. Since this syntax is nearly useless in finding typos in an SDF specification, a second syntax, the validation syntax, is defined that does not include the extension points. The validation syntax can be generated from the framework syntax by leaving out all lines containing the string EXTENSION-POINT; as this is trivial, the result is not shown here.
この付録では、フレームワーク構文のみ、つまり、自由な拡張ポイントを備えた構文を示します。この構文は SDF 仕様のタイプミスを見つけるのにはほとんど役に立たないため、拡張ポイントを含まない 2 番目の構文である検証構文が定義されています。検証構文は、文字列 EXTENSION-POINT を含むすべての行を省略することで、フレームワーク構文から生成できます。これは簡単なことなので、結果はここには示されていません。
This appendix makes use of CDDL "features" as defined in Section 4 of [RFC9165]. Features whose names end in "-ext" indicate extension points for further evolution.
この付録では、[RFC9165] のセクション 4 で定義されている CDDL の「機能」を利用します。名前が「-ext」で終わる機能は、さらなる進化のための拡張ポイントを示します。
start = sdf-syntax
sdf-syntax = {
; info will be required in most process policies
? info: sdfinfo
? namespace: named<text>
? defaultNamespace: text
; Thing is a composition of objects that work together in some way
? sdfThing: named<thingqualities>
; Object is a set of Properties, Actions, and Events that together
; perform a particular function
? sdfObject: named<objectqualities>
; Includes Properties, Actions, and Events as well as sdfData
paedataqualities
* $$SDF-EXTENSION-TOP
EXTENSION-POINT<"top-ext">
}
sdfinfo = {
? title: text
? description: text
? version: text
? copyright: text
? license: text
? modified: modified-date-time
? features: [
* (any .feature "feature-name") ; EXTENSION-POINT
]
optional-comment
* $$SDF-EXTENSION-INFO
EXTENSION-POINT<"info-ext">
}
; Shortcut for a map that gives names to instances of X
; (has keys of type text and values of type X)
named<X> = { * text => X }
; EXTENSION-POINT is only used in framework syntax
EXTENSION-POINT<f> = ( * (quality-name .feature f) => any )
quality-name = text .regexp "([a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*"
sdf-pointer = global / same-object / true
global = text .regexp ".*[:#].*" ; rough CURIE or JSON Pointer syntax
same-object = referenceable-name
referenceable-name = text .regexp "[^:#]*"
; per se no point in having an empty list, but used for sdfRequired
; in odmobject-multiple_axis_joystick.sdf.json
pointer-list = [* sdf-pointer]
optional-comment = (
? $comment: text ; source code comments only, no semantics
)
commonqualities = (
? description: text ; long text (no constraints)
? label: text ; short text (no constraints); default to key
optional-comment
? sdfRef: sdf-pointer
; applies to qualities of properties, of data:
? sdfRequired: pointer-list
)
arraydefinitionqualities = (
? "minItems" => uint
? "maxItems" => uint
)
paedataqualities = (
; Property represents the state of an instance of an object
? sdfProperty: named<propertyqualities>
; Action invokes an application layer verb associated with an object
? sdfAction: named<actionqualities>
; Event represents an occurrence of event associated with an object
? sdfEvent: named<eventqualities>
; Data represents a piece of information that can be the state of a
; property or a parameter to an action or a signal in an event
? sdfData: named<dataqualities>
)
; for building hierarchy
thingqualities = {
commonqualities
? sdfObject: named<objectqualities>
? sdfThing: named<thingqualities>
paedataqualities
arraydefinitionqualities
* $$SDF-EXTENSION-THING
EXTENSION-POINT<"thing-ext">
}
; for single objects, or for arrays of objects
objectqualities = {
commonqualities
paedataqualities
arraydefinitionqualities
* $$SDF-EXTENSION-OBJECT
EXTENSION-POINT<"object-ext">
}
parameter-list = dataqualities
actionqualities = {
commonqualities
? sdfInputData: parameter-list ; sdfRequiredInputData applies here
? sdfOutputData: parameter-list ; sdfRequired applies here
; zero or more named data type definitions that might be used above
? sdfData: named<dataqualities>
* $$SDF-EXTENSION-ACTION
EXTENSION-POINT<"action-ext">
}
eventqualities = {
commonqualities
? sdfOutputData: parameter-list ; sdfRequired applies here
; zero or more named data type definitions that might be used above
? sdfData: named<dataqualities>
* $$SDF-EXTENSION-EVENT
EXTENSION-POINT<"event-ext">
}
sdftype-name = text .regexp "[a-z][-a-z0-9]*" ; EXTENSION-POINT
dataqualities = {
commonqualities
jsonschema
? "unit" => text
? nullable: bool
? "sdfType" => "byte-string" / "unix-time"
/ $SDF-EXTENSION-SDFTYPE .within sdftype-name
/ (sdftype-name .feature "sdftype-ext") ; EXTENSION-POINT
? contentFormat: text
* $$SDF-EXTENSION-DATA
EXTENSION-POINT<"data-ext">
}
propertyqualities = {
? observable: bool
? readable: bool
? writable: bool
* $$SDF-EXTENSION-PROPERTY
~dataqualities
}
allowed-types = number / text / bool / null
/ [* number] / [* text] / [* bool]
/ {* text => any}
/ $SDF-EXTENSION-ALLOWED
/ (any .feature "allowed-ext") ; EXTENSION-POINT
compound-type = (
"type" => "object"
? required: [+text]
? properties: named<dataqualities>
)
optional-choice = (
? (("sdfChoice" => named<dataqualities>)
// ("enum" => [+ text])) ; limited to text strings
)
jsonschema = (
? (("type" => "number" / "string" / "boolean" / "integer" / "array")
// compound-type
// $$SDF-EXTENSION-TYPE
// (type: text .feature "type-ext") ; EXTENSION-POINT
)
; if present, all other qualities apply to all choices:
optional-choice
; the next three should validate against type:
? const: allowed-types
? default: allowed-types
; number/integer constraints
? minimum: number
? maximum: number
? exclusiveMinimum: number
? exclusiveMaximum: number
? multipleOf: number
; text string constraints
? minLength: uint
? maxLength: uint
? pattern: text ; regexp
? format: "date-time" / "date" / "time"
/ "uri" / "uri-reference" / "uuid"
/ $SDF-EXTENSION-FORMAT .within text
/ (text .feature "format-ext") ; EXTENSION-POINT
; array constraints
? minItems: uint
? maxItems: uint
? uniqueItems: bool
? items: jso-items
)
jso-items = {
? sdfRef: sdf-pointer ; import limited to subset allowed here...
? description: text ; long text (no constraints)
optional-comment
; leave commonqualities out for non-complex data types,
; but need the above three.
; no further nesting: no "array"
? ((type: "number" / "string" / "boolean" / "integer")
// compound-type
// $$SDF-EXTENSION-ITEMTYPE
// (type: text .feature "itemtype-ext") ; EXTENSION-POINT
)
; if present, all other qualities apply to all choices
optional-choice
; jso subset
? minimum: number
? maximum: number
? format: text
? minLength: uint
? maxLength: uint
* $$SDF-EXTENSION-ITEMS
EXTENSION-POINT<"items-ext">
}
modified-date-time = text .abnf modified-dt-abnf
modified-dt-abnf = "modified-dt" .det rfc3339z
; RFC 3339 sans time-numoffset, slightly condensed
rfc3339z = '
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap sec
; rules
time-secfrac = "." 1*DIGIT
DIGIT = %x30-39 ; 0-9
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
modified-dt = full-date ["T" partial-time "Z"]
'
This informative appendix describes the syntax of SDF defined in Appendix A, but uses a version of the description techniques advertised on json-schema.org [JSO7] [JSO7V].
この有益な付録では、付録 A で定義されている SDF の構文について説明しますが、json-schema.org [JSO7] [JSO7V] で宣伝されている記述手法のバージョンを使用します。
The appendix shows both the validation and the framework syntax. Since most of the lines are the same between these two files, those lines are shown only once, with a leading space, in the form of a unified diff. Lines leading with a - are part of the validation syntax and lines leading with a + are part of the framework syntax.
付録では、検証とフレームワークの構文の両方を示します。これら 2 つのファイル間でほとんどの行は同じであるため、これらの行は、統合された diff の形式で、先頭にスペースを付けて 1 回だけ表示されます。- で始まる行は検証構文の一部であり、+ で始まる行はフレームワーク構文の一部です。
{
- "title": "sdf-validation.cddl -- Generated: 2025-10-13T08:43:18Z",
+ "title": "sdf-framework.cddl -- Generated: 2025-10-13T08:43:29Z",
"$schema": "http://json-schema.org/draft-07/schema#",
"$ref": "#/definitions/sdf-syntax",
"definitions": {
"sdf-syntax": {
"type": "object",
"properties": {
"info": {
"$ref": "#/definitions/sdfinfo"
},
"namespace": {
"type": "object",
"additionalProperties": {
"type": "string"
}
},
"defaultNamespace": {
"type": "string"
},
"sdfThing": {
"type": "object",
"additionalProperties": {
"$ref": "#/definitions/thingqualities"
}
},
"sdfObject": {
"type": "object",
"additionalProperties": {
"$ref": "#/definitions/objectqualities"
}
},
"sdfProperty": {
"$ref": "#/definitions/sdfProperty-"
},
"sdfAction": {
"$ref": "#/definitions/sdfAction-"
},
"sdfEvent": {
"$ref": "#/definitions/sdfEvent-"
},
"sdfData": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
}
},
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"additionalProperties": false
},
"sdfinfo": {
"type": "object",
"properties": {
"title": {
"type": "string"
},
"description": {
"type": "string"
},
"version": {
"type": "string"
},
"copyright": {
"type": "string"
},
"license": {
"type": "string"
},
"modified": {
"$ref": "#/definitions/modified-date-time"
},
"features": {
- "type": "array",
- "maxItems": 0
+ "type": "array"
},
"$comment": {
"type": "string"
}
},
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"additionalProperties": false
},
"modified-date-time": {
"type": "string"
},
"thingqualities": {
"type": "object",
"properties": {
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"sdfObject": {
"type": "object",
"additionalProperties": {
"$ref": "#/definitions/objectqualities"
}
},
"sdfThing": {
"type": "object",
"additionalProperties": {
"$ref": "#/definitions/thingqualities"
}
},
"sdfProperty": {
"$ref": "#/definitions/sdfProperty-"
},
"sdfAction": {
"$ref": "#/definitions/sdfAction-"
},
"sdfEvent": {
"$ref": "#/definitions/sdfEvent-"
},
"sdfData": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
}
},
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"additionalProperties": false
},
"sdf-pointer": {
"anyOf": [
{
"$ref": "#/definitions/global"
},
{
"$ref": "#/definitions/same-object"
},
{
"$ref": "#/definitions/true"
}
]
},
"global": {
"type": "string",
"pattern": "^[^\\n\\r]*[:#][^\\n\\r]*$"
},
"same-object": {
"$ref": "#/definitions/referenceable-name"
},
"referenceable-name": {
"type": "string",
"pattern": "^[^:#]*$"
},
"true": {
"type": "boolean",
"const": true
},
"pointer-list": {
"type": "array",
"items": {
"$ref": "#/definitions/sdf-pointer"
}
},
"objectqualities": {
"type": "object",
"properties": {
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"sdfProperty": {
"$ref": "#/definitions/sdfProperty-"
},
"sdfAction": {
"$ref": "#/definitions/sdfAction-"
},
"sdfEvent": {
"$ref": "#/definitions/sdfEvent-"
},
"sdfData": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
}
},
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"additionalProperties": false
},
"propertyqualities": {
"anyOf": [
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"$ref": "#/definitions/type-"
},
"sdfChoice": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"observable": {
"type": "boolean"
},
"readable": {
"type": "boolean"
},
"writable": {
"type": "boolean"
},
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"const": {
"$ref": "#/definitions/allowed-types"
},
"default": {
"$ref": "#/definitions/allowed-types"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"exclusiveMinimum": {
"type": "number"
},
"exclusiveMaximum": {
"type": "number"
},
"multipleOf": {
"type": "number"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
},
"pattern": {
"type": "string"
},
"format": {
"$ref": "#/definitions/format-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
},
"uniqueItems": {
"type": "boolean"
},
"items": {
"$ref": "#/definitions/jso-items"
},
"unit": {
"type": "string"
},
"nullable": {
"type": "boolean"
},
"sdfType": {
"$ref": "#/definitions/sdfType-"
},
"contentFormat": {
"type": "string"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"type": "string",
"const": "object"
},
"required": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"properties": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"sdfChoice": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"observable": {
"type": "boolean"
},
"readable": {
"type": "boolean"
},
"writable": {
"type": "boolean"
},
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"const": {
"$ref": "#/definitions/allowed-types"
},
"default": {
"$ref": "#/definitions/allowed-types"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"exclusiveMinimum": {
"type": "number"
},
"exclusiveMaximum": {
"type": "number"
},
"multipleOf": {
"type": "number"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
},
"pattern": {
"type": "string"
},
"format": {
"$ref": "#/definitions/format-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
},
"uniqueItems": {
"type": "boolean"
},
"items": {
"$ref": "#/definitions/jso-items"
},
"unit": {
"type": "string"
},
"nullable": {
"type": "boolean"
},
"sdfType": {
"$ref": "#/definitions/sdfType-"
},
"contentFormat": {
"type": "string"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
+ "properties": {
+ "type": {
+ "type": "string"
+ },
+ "sdfChoice": {
+ "$ref": "#/definitions/sdfData-sdfChoice-properties-"
+ },
+ "observable": {
+ "type": "boolean"
+ },
+ "readable": {
+ "type": "boolean"
+ },
+ "writable": {
+ "type": "boolean"
+ },
+ "description": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "$comment": {
+ "type": "string"
+ },
+ "sdfRef": {
+ "$ref": "#/definitions/sdf-pointer"
+ },
+ "sdfRequired": {
+ "$ref": "#/definitions/pointer-list"
+ },
+ "const": {
+ "$ref": "#/definitions/allowed-types"
+ },
+ "default": {
+ "$ref": "#/definitions/allowed-types"
+ },
+ "minimum": {
+ "type": "number"
+ },
+ "maximum": {
+ "type": "number"
+ },
+ "exclusiveMinimum": {
+ "type": "number"
+ },
+ "exclusiveMaximum": {
+ "type": "number"
+ },
+ "multipleOf": {
+ "type": "number"
+ },
+ "minLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "pattern": {
+ "type": "string"
+ },
+ "format": {
+ "$ref": "#/definitions/format-"
+ },
+ "minItems": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxItems": {
+ "$ref": "#/definitions/uint"
+ },
+ "uniqueItems": {
+ "type": "boolean"
+ },
+ "items": {
+ "$ref": "#/definitions/jso-items"
+ },
+ "unit": {
+ "type": "string"
+ },
+ "nullable": {
+ "type": "boolean"
+ },
+ "sdfType": {
+ "$ref": "#/definitions/sdfType-"
+ },
+ "contentFormat": {
+ "type": "string"
+ }
+ },
+ "additionalProperties": false
+ },
+ {
+ "type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"$ref": "#/definitions/type-"
},
"enum": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"observable": {
"type": "boolean"
},
"readable": {
"type": "boolean"
},
"writable": {
"type": "boolean"
},
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"const": {
"$ref": "#/definitions/allowed-types"
},
"default": {
"$ref": "#/definitions/allowed-types"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"exclusiveMinimum": {
"type": "number"
},
"exclusiveMaximum": {
"type": "number"
},
"multipleOf": {
"type": "number"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
},
"pattern": {
"type": "string"
},
"format": {
"$ref": "#/definitions/format-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
},
"uniqueItems": {
"type": "boolean"
},
"items": {
"$ref": "#/definitions/jso-items"
},
"unit": {
"type": "string"
},
"nullable": {
"type": "boolean"
},
"sdfType": {
"$ref": "#/definitions/sdfType-"
},
"contentFormat": {
"type": "string"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"type": "string",
"const": "object"
},
"required": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"properties": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"enum": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"observable": {
"type": "boolean"
},
"readable": {
"type": "boolean"
},
"writable": {
"type": "boolean"
},
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"const": {
"$ref": "#/definitions/allowed-types"
},
"default": {
"$ref": "#/definitions/allowed-types"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"exclusiveMinimum": {
"type": "number"
},
"exclusiveMaximum": {
"type": "number"
},
"multipleOf": {
"type": "number"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
},
"pattern": {
"type": "string"
},
"format": {
"$ref": "#/definitions/format-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
},
"uniqueItems": {
"type": "boolean"
},
"items": {
"$ref": "#/definitions/jso-items"
},
"unit": {
"type": "string"
},
"nullable": {
"type": "boolean"
},
"sdfType": {
"$ref": "#/definitions/sdfType-"
},
"contentFormat": {
"type": "string"
}
},
"additionalProperties": false
+ },
+ {
+ "type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
+ "properties": {
+ "type": {
+ "type": "string"
+ },
+ "enum": {
+ "type": "array",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1
+ },
+ "observable": {
+ "type": "boolean"
+ },
+ "readable": {
+ "type": "boolean"
+ },
+ "writable": {
+ "type": "boolean"
+ },
+ "description": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "$comment": {
+ "type": "string"
+ },
+ "sdfRef": {
+ "$ref": "#/definitions/sdf-pointer"
+ },
+ "sdfRequired": {
+ "$ref": "#/definitions/pointer-list"
+ },
+ "const": {
+ "$ref": "#/definitions/allowed-types"
+ },
+ "default": {
+ "$ref": "#/definitions/allowed-types"
+ },
+ "minimum": {
+ "type": "number"
+ },
+ "maximum": {
+ "type": "number"
+ },
+ "exclusiveMinimum": {
+ "type": "number"
+ },
+ "exclusiveMaximum": {
+ "type": "number"
+ },
+ "multipleOf": {
+ "type": "number"
+ },
+ "minLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "pattern": {
+ "type": "string"
+ },
+ "format": {
+ "$ref": "#/definitions/format-"
+ },
+ "minItems": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxItems": {
+ "$ref": "#/definitions/uint"
+ },
+ "uniqueItems": {
+ "type": "boolean"
+ },
+ "items": {
+ "$ref": "#/definitions/jso-items"
+ },
+ "unit": {
+ "type": "string"
+ },
+ "nullable": {
+ "type": "boolean"
+ },
+ "sdfType": {
+ "$ref": "#/definitions/sdfType-"
+ },
+ "contentFormat": {
+ "type": "string"
+ }
+ },
+ "additionalProperties": false
}
]
},
"dataqualities": {
"anyOf": [
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"$ref": "#/definitions/type-"
},
"sdfChoice": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"const": {
"$ref": "#/definitions/allowed-types"
},
"default": {
"$ref": "#/definitions/allowed-types"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"exclusiveMinimum": {
"type": "number"
},
"exclusiveMaximum": {
"type": "number"
},
"multipleOf": {
"type": "number"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
},
"pattern": {
"type": "string"
},
"format": {
"$ref": "#/definitions/format-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
},
"uniqueItems": {
"type": "boolean"
},
"items": {
"$ref": "#/definitions/jso-items"
},
"unit": {
"type": "string"
},
"nullable": {
"type": "boolean"
},
"sdfType": {
"$ref": "#/definitions/sdfType-"
},
"contentFormat": {
"type": "string"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"type": "string",
"const": "object"
},
"required": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"properties": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"sdfChoice": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"const": {
"$ref": "#/definitions/allowed-types"
},
"default": {
"$ref": "#/definitions/allowed-types"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"exclusiveMinimum": {
"type": "number"
},
"exclusiveMaximum": {
"type": "number"
},
"multipleOf": {
"type": "number"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
},
"pattern": {
"type": "string"
},
"format": {
"$ref": "#/definitions/format-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
},
"uniqueItems": {
"type": "boolean"
},
"items": {
"$ref": "#/definitions/jso-items"
},
"unit": {
"type": "string"
},
"nullable": {
"type": "boolean"
},
"sdfType": {
"$ref": "#/definitions/sdfType-"
},
"contentFormat": {
"type": "string"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
+ "properties": {
+ "type": {
+ "type": "string"
+ },
+ "sdfChoice": {
+ "$ref": "#/definitions/sdfData-sdfChoice-properties-"
+ },
+ "description": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "$comment": {
+ "type": "string"
+ },
+ "sdfRef": {
+ "$ref": "#/definitions/sdf-pointer"
+ },
+ "sdfRequired": {
+ "$ref": "#/definitions/pointer-list"
+ },
+ "const": {
+ "$ref": "#/definitions/allowed-types"
+ },
+ "default": {
+ "$ref": "#/definitions/allowed-types"
+ },
+ "minimum": {
+ "type": "number"
+ },
+ "maximum": {
+ "type": "number"
+ },
+ "exclusiveMinimum": {
+ "type": "number"
+ },
+ "exclusiveMaximum": {
+ "type": "number"
+ },
+ "multipleOf": {
+ "type": "number"
+ },
+ "minLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "pattern": {
+ "type": "string"
+ },
+ "format": {
+ "$ref": "#/definitions/format-"
+ },
+ "minItems": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxItems": {
+ "$ref": "#/definitions/uint"
+ },
+ "uniqueItems": {
+ "type": "boolean"
+ },
+ "items": {
+ "$ref": "#/definitions/jso-items"
+ },
+ "unit": {
+ "type": "string"
+ },
+ "nullable": {
+ "type": "boolean"
+ },
+ "sdfType": {
+ "$ref": "#/definitions/sdfType-"
+ },
+ "contentFormat": {
+ "type": "string"
+ }
+ },
+ "additionalProperties": false
+ },
+ {
+ "type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"$ref": "#/definitions/type-"
},
"enum": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"const": {
"$ref": "#/definitions/allowed-types"
},
"default": {
"$ref": "#/definitions/allowed-types"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"exclusiveMinimum": {
"type": "number"
},
"exclusiveMaximum": {
"type": "number"
},
"multipleOf": {
"type": "number"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
},
"pattern": {
"type": "string"
},
"format": {
"$ref": "#/definitions/format-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
},
"uniqueItems": {
"type": "boolean"
},
"items": {
"$ref": "#/definitions/jso-items"
},
"unit": {
"type": "string"
},
"nullable": {
"type": "boolean"
},
"sdfType": {
"$ref": "#/definitions/sdfType-"
},
"contentFormat": {
"type": "string"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"type": "string",
"const": "object"
},
"required": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"properties": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"enum": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"const": {
"$ref": "#/definitions/allowed-types"
},
"default": {
"$ref": "#/definitions/allowed-types"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"exclusiveMinimum": {
"type": "number"
},
"exclusiveMaximum": {
"type": "number"
},
"multipleOf": {
"type": "number"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
},
"pattern": {
"type": "string"
},
"format": {
"$ref": "#/definitions/format-"
},
"minItems": {
"$ref": "#/definitions/uint"
},
"maxItems": {
"$ref": "#/definitions/uint"
},
"uniqueItems": {
"type": "boolean"
},
"items": {
"$ref": "#/definitions/jso-items"
},
"unit": {
"type": "string"
},
"nullable": {
"type": "boolean"
},
"sdfType": {
"$ref": "#/definitions/sdfType-"
},
"contentFormat": {
"type": "string"
}
},
"additionalProperties": false
+ },
+ {
+ "type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
+ "properties": {
+ "type": {
+ "type": "string"
+ },
+ "enum": {
+ "type": "array",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1
+ },
+ "description": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "$comment": {
+ "type": "string"
+ },
+ "sdfRef": {
+ "$ref": "#/definitions/sdf-pointer"
+ },
+ "sdfRequired": {
+ "$ref": "#/definitions/pointer-list"
+ },
+ "const": {
+ "$ref": "#/definitions/allowed-types"
+ },
+ "default": {
+ "$ref": "#/definitions/allowed-types"
+ },
+ "minimum": {
+ "type": "number"
+ },
+ "maximum": {
+ "type": "number"
+ },
+ "exclusiveMinimum": {
+ "type": "number"
+ },
+ "exclusiveMaximum": {
+ "type": "number"
+ },
+ "multipleOf": {
+ "type": "number"
+ },
+ "minLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "pattern": {
+ "type": "string"
+ },
+ "format": {
+ "$ref": "#/definitions/format-"
+ },
+ "minItems": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxItems": {
+ "$ref": "#/definitions/uint"
+ },
+ "uniqueItems": {
+ "type": "boolean"
+ },
+ "items": {
+ "$ref": "#/definitions/jso-items"
+ },
+ "unit": {
+ "type": "string"
+ },
+ "nullable": {
+ "type": "boolean"
+ },
+ "sdfType": {
+ "$ref": "#/definitions/sdfType-"
+ },
+ "contentFormat": {
+ "type": "string"
+ }
+ },
+ "additionalProperties": false
}
]
},
"allowed-types": {
"anyOf": [
{
"type": "number"
},
{
"type": "string"
},
{
"type": "boolean"
},
{
"type": "null"
},
{
"type": "array",
"items": {
"type": "number"
}
},
{
"type": "array",
"items": {
"type": "string"
}
},
{
"type": "array",
"items": {
"type": "boolean"
}
},
{
"type": "object",
"additionalProperties": {}
- }
+ },
+ {}
]
},
"uint": {
"type": "integer",
"minimum": 0
},
"jso-items": {
"anyOf": [
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"type": "string",
"enum": [
"number",
"string",
"boolean",
"integer"
]
},
"sdfChoice": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"description": {
"type": "string"
},
"$comment": {
"type": "string"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"format": {
"type": "string"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"type": "string",
"const": "object"
},
"required": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"properties": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"sdfChoice": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"description": {
"type": "string"
},
"$comment": {
"type": "string"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"format": {
"type": "string"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
+ "properties": {
+ "type": {
+ "type": "string"
+ },
+ "sdfChoice": {
+ "$ref": "#/definitions/sdfData-sdfChoice-properties-"
+ },
+ "sdfRef": {
+ "$ref": "#/definitions/sdf-pointer"
+ },
+ "description": {
+ "type": "string"
+ },
+ "$comment": {
+ "type": "string"
+ },
+ "minimum": {
+ "type": "number"
+ },
+ "maximum": {
+ "type": "number"
+ },
+ "format": {
+ "type": "string"
+ },
+ "minLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxLength": {
+ "$ref": "#/definitions/uint"
+ }
+ },
+ "additionalProperties": false
+ },
+ {
+ "type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"type": "string",
"enum": [
"number",
"string",
"boolean",
"integer"
]
},
"enum": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"description": {
"type": "string"
},
"$comment": {
"type": "string"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"format": {
"type": "string"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
}
},
"additionalProperties": false
},
{
"type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"properties": {
"type": {
"type": "string",
"const": "object"
},
"required": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"properties": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
},
"enum": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"description": {
"type": "string"
},
"$comment": {
"type": "string"
},
"minimum": {
"type": "number"
},
"maximum": {
"type": "number"
},
"format": {
"type": "string"
},
"minLength": {
"$ref": "#/definitions/uint"
},
"maxLength": {
"$ref": "#/definitions/uint"
}
},
"additionalProperties": false
+ },
+ {
+ "type": "object",
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
+ "properties": {
+ "type": {
+ "type": "string"
+ },
+ "enum": {
+ "type": "array",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1
+ },
+ "sdfRef": {
+ "$ref": "#/definitions/sdf-pointer"
+ },
+ "description": {
+ "type": "string"
+ },
+ "$comment": {
+ "type": "string"
+ },
+ "minimum": {
+ "type": "number"
+ },
+ "maximum": {
+ "type": "number"
+ },
+ "format": {
+ "type": "string"
+ },
+ "minLength": {
+ "$ref": "#/definitions/uint"
+ },
+ "maxLength": {
+ "$ref": "#/definitions/uint"
+ }
+ },
+ "additionalProperties": false
}
]
},
+ "sdftype-name": {
+ "type": "string",
+ "pattern": "^[a-z][\\-a-z0-9]*$"
+ },
"actionqualities": {
"type": "object",
"properties": {
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"sdfInputData": {
"$ref": "#/definitions/parameter-list"
},
"sdfOutputData": {
"$ref": "#/definitions/parameter-list"
},
"sdfData": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
}
},
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"additionalProperties": false
},
"parameter-list": {
"$ref": "#/definitions/dataqualities"
},
"eventqualities": {
"type": "object",
"properties": {
"description": {
"type": "string"
},
"label": {
"type": "string"
},
"$comment": {
"type": "string"
},
"sdfRef": {
"$ref": "#/definitions/sdf-pointer"
},
"sdfRequired": {
"$ref": "#/definitions/pointer-list"
},
"sdfOutputData": {
"$ref": "#/definitions/parameter-list"
},
"sdfData": {
"$ref": "#/definitions/sdfData-sdfChoice-properties-"
}
},
+ "patternProperties": {
+ "^(?:[a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*$": {}
+ },
"additionalProperties": false
},
"format-": {
- "type": "string",
- "enum": [
- "date-time",
- "date",
- "time",
- "uri",
- "uri-reference",
- "uuid"
+ "anyOf": [
+ {
+ "type": "string",
+ "const": "date-time"
+ },
+ {
+ "type": "string",
+ "const": "date"
+ },
+ {
+ "type": "string",
+ "const": "time"
+ },
+ {
+ "type": "string",
+ "const": "uri"
+ },
+ {
+ "type": "string",
+ "const": "uri-reference"
+ },
+ {
+ "type": "string",
+ "const": "uuid"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ "sdfType-": {
+ "anyOf": [
+ {
+ "type": "string",
+ "const": "byte-string"
+ },
+ {
+ "type": "string",
+ "const": "unix-time"
+ },
+ {
+ "$ref": "#/definitions/sdftype-name"
+ }
]
},
"sdfData-sdfChoice-properties-": {
"type": "object",
"additionalProperties": {
"$ref": "#/definitions/dataqualities"
}
},
"type-": {
"type": "string",
"enum": [
"number",
"string",
"boolean",
"integer",
"array"
]
},
- "sdfEvent-": {
+ "sdfProperty-": {
"type": "object",
"additionalProperties": {
- "$ref": "#/definitions/eventqualities"
+ "$ref": "#/definitions/propertyqualities"
}
},
"sdfAction-": {
"type": "object",
"additionalProperties": {
"$ref": "#/definitions/actionqualities"
}
},
- "sdfProperty-": {
+ "sdfEvent-": {
"type": "object",
"additionalProperties": {
- "$ref": "#/definitions/propertyqualities"
+ "$ref": "#/definitions/eventqualities"
}
- },
- "sdfType-": {
- "type": "string",
- "enum": [
- "byte-string",
- "unix-time"
- ]
}
}
}
This appendix is normative.
この付録は規範的なものです。
Data qualities define data used in SDF affordances at an information model level. A popular way to describe JSON data at a data model level is proposed by a number of drafts on json-schema.org (which collectively are abbreviated JSO here); for reference to a popular version, this appendix points to [JSO7] and [JSO7V]. As the vocabulary used by JSO is familiar to many JSON modelers, the present specification borrows some of the terms and ports their semantics to the information model level needed for SDF.
データ品質は、SDF アフォーダンスで使用されるデータを情報モデル レベルで定義します。JSON データをデータ モデル レベルで記述する一般的な方法は、json-schema.org (ここではまとめて JSO と略します) の多数のドラフトによって提案されています。一般的なバージョンを参照するために、この付録では [JSO7] および [JSO7V] を参照します。JSO で使用される語彙は多くの JSON モデラーに馴染みがあるため、本仕様では用語の一部を借用し、そのセマンティクスを SDF に必要な情報モデル レベルに移植します。
The main data quality imported is the "type". In SDF, this can take one of six (text string) values, which are discussed in the following subsections (note that the JSO type "null" is not supported as a value of this data quality in SDF).
インポートされる主なデータ品質は「タイプ」です。SDF では、これは 6 つの (テキスト文字列) 値のうちの 1 つを取ることができます。これについては、次のサブセクションで説明します (JSO タイプ「null」は、SDF ではこのデータ品質の値としてサポートされていないことに注意してください)。
The additional quality "const" restricts the data to one specific value (given as the value of the const quality).
追加の品質「const」は、データを 1 つの特定の値 (const 品質の値として指定) に制限します。
Similarly, the additional quality "default" provides data that can be used in the absence of the data (given as the value of the default quality); this is mainly documentary and not very well-defined for SDF as no process is defined that would add default values to an instance of some interaction data.
同様に、追加の品質「デフォルト」は、データ (デフォルト品質の値として指定) がない場合に使用できるデータを提供します。これは主にドキュメンタリーであり、一部のインタラクション データのインスタンスにデフォルト値を追加するプロセスが定義されていないため、SDF についてはあまり明確に定義されていません。
Other qualities that are inspired by JSO are "$comment" and "description", both of which are also available in the information block.
JSO からインスピレーションを得た他の品質としては、「$comment」と「description」があり、どちらも情報ブロックで利用できます。
The types "number" and "integer" are associated with floating point and integer numbers, as they are available in JSON. A type value of integer means that only integer values of JSON numbers can be used (note that 10.0 is an integer value, even if it is in a notation that would also allow non-zero decimal fractions).
「数値」および「整数」型は、JSON で使用できるため、浮動小数点および整数に関連付けられています。type 値が integer は、JSON 数値の整数値のみを使用できることを意味します (10.0 は、ゼロ以外の小数も許可される表記であっても整数値であることに注意してください)。
The additional data qualities "minimum", "maximum", "exclusiveMinimum", and "exclusiveMaximum" provide number values that serve as inclusive/exclusive lower/upper bounds for the number. (Note that the Boolean form of "exclusiveMinimum"/"exclusiveMaximum" found in earlier JSO drafts [JSO4V] is not used.)
追加のデータ品質「minimum」、「maximum」、「exclusiveMinimum」、および「exclusiveMinimum」は、数値の包括的/排他的な下限/上限として機能する数値を提供します。(以前の JSO ドラフト [JSO4V] にある「exclusiveMinimum」/「exclusiveMinimum」のブール形式は使用されていないことに注意してください。)
The data quality "multipleOf" gives a positive number that constrains the data value to be an integer multiple of the number given. (Type "integer" can also be expressed as a "multipleOf" quality of value 1, unless another "multipleOf" quality is present.)
データ品質「multipleOf」は、データ値が指定された数値の整数倍になるように制約する正の数を与えます。(別の「multipleOf」品質が存在しない限り、型「integer」は値 1 の「multipleOf」品質として表現することもできます。)
The type "string" is associated with Unicode text string values, as they can be represented in JSON.
「文字列」タイプは、JSON で表現できるため、Unicode テキスト文字列値に関連付けられます。
The length (as measured in characters, specifically Unicode scalar values) can be constrained by the additional data qualities "minLength" and "maxLength", which are inclusive bounds.
長さ (文字、具体的には Unicode スカラー値で測定) は、包含境界である追加のデータ品質「minLength」および「maxLength」によって制限できます。
(More specifically, Unicode text strings as defined in this specification are sequences of Unicode scalar values, the number of which is taken as the length of such a text string.
(より具体的には、この仕様で定義されている Unicode テキスト文字列は、Unicode スカラー値のシーケンスであり、その数はそのようなテキスト文字列の長さとみなされます。
The data quality "pattern" takes a string value that is interpreted as an [ECMA-262] regular expression in Unicode mode that constrains the string (note that these are not anchored by default, so unless ^ and $ anchors are employed, ECMA-262 regular expressions match any string that _contains_ a match). The JSO proposals acknowledge that regular expression support is rather diverse in various platforms, so the suggestion is to limit them to:
データ品質の「パターン」は、文字列を制約する Unicode モードの [ECMA-262] 正規表現として解釈される文字列値を受け取ります (これらはデフォルトではアンカーされていないため、^ アンカーと $ アンカーが使用されない限り、ECMA-262 正規表現は一致を「含む」文字列と一致することに注意してください)。JSO の提案では、正規表現のサポートがさまざまなプラットフォームでかなり多様であることを認めているため、提案では次のように制限します。
* characters;
* キャラクター。
* character classes in square brackets, including ranges; their complements;
* 角括弧内の文字クラス (範囲を含む)。それらの補完物。
* simple quantifiers *, +, ?, and range quantifiers {n}, {n,m}, and {n,};
* 単純な量指定子 *、+、?、および範囲量指定子 {n}、{n,m}、および {n,}。
* grouping parentheses;
* 括弧をグループ化します。
* the choice operator |;
* 選択演算子 |;
* and anchors (beginning-of-input ^ and end-of-input $).
* およびアンカー (入力の始まり ^ と入力の終わり $)。
Note that this subset is somewhat similar to the subset introduced by I-Regexps [RFC9485], which are anchored regular expressions and include certain backslash escapes for characters and character classes.
このサブセットは、I-Regexps [RFC9485] によって導入されたサブセットにいくらか似ていることに注意してください。I-Regexps [RFC9485] は、アンカー正規表現であり、文字および文字クラスに特定のバックスラッシュ エスケープを含みます。
The additional data quality "format" can take one of the following values. Note that, at an information model level, the presence of this data quality changes the type from being a simple text string to the abstract meaning of the format given (i.e., the format "date-time" is less about the specific syntax employed in [RFC3339] than about the usage as an absolute point in civil time).
追加のデータ品質の「形式」は、次のいずれかの値を取ることができます。情報モデルレベルでは、このデータ品質の存在により、型が単純なテキスト文字列から、指定された形式の抽象的な意味に変化することに注意してください(つまり、「日付-時刻」形式は、[RFC3339]で採用されている特定の構文に関するものではなく、常用時間の絶対点としての使用方法に関するものです)。
* "date-time", "date", "time": A date-time, full-date, or full-time as defined in [RFC3339], respectively.
* "date-time"、"date"、"time": [RFC3339] で定義されている、それぞれ日付/時刻、完全な日付、または完全な時刻。
* "uri", "uri-reference": A URI or URI Reference as defined in [STD66], respectively.
* "uri"、"uri-reference": それぞれ [STD66] で定義されている URI または URI 参照。
* "uuid": A Universally Unique Identifier (UUID) as defined in [RFC9562]).
* 「uuid」: [RFC9562] で定義されている汎用一意識別子 (UUID))。
The type "boolean" can take the values "true" or "false".
「boolean」型は、「true」または「false」の値を取ることができます。
The type "array" is associated with arrays, as they are available in JSON.
「配列」タイプは、JSON で使用できるため、配列に関連付けられます。
The additional quality "items" gives the type that each of the elements of the array must match.
追加の品質「項目」は、配列の各要素が一致する必要がある型を与えます。
The number of elements in the array can be constrained by the additional data qualities "minItems" and "maxItems", which are inclusive bounds.
配列内の要素の数は、包含境界である追加のデータ品質「minItems」および「maxItems」によって制限できます。
The additional data quality "uniqueItems" gives a Boolean value that, if true, requires the elements to be all different.
追加のデータ品質「uniqueItems」は、true の場合、要素がすべて異なることを要求するブール値を与えます。
The type "object" is associated with maps, from strings to values, as they are available in JSON.
「オブジェクト」タイプは、JSON で使用できるため、文字列から値までのマップに関連付けられます。
The additional quality "properties" is a map the entries of which describe entries in the specified JSON map: the key gives an allowable map key for the specified JSON map and the value is a map with a named set of data qualities giving the type for the corresponding value in the specified JSON map.
追加の品質「プロパティ」は、そのエントリが指定された JSON マップ内のエントリを説明するマップです。キーは、指定された JSON マップの許容されるマップ キーを与え、値は、指定された JSON マップ内の対応する値の型を与えるデータ品質の名前付きセットを持つマップです。
All entries specified in this way are optional unless they are listed in the value of the additional quality "required", which is an array of string values that give the key names of required entries.
この方法で指定されたすべてのエントリは、追加の品質「required」の値にリストされていない限り、オプションです。これは、必須エントリのキー名を与える文字列値の配列です。
Note that the term "properties" as an additional quality for defining map entries is unrelated to sdfProperty.
マップ エントリを定義するための追加の品質としての「プロパティ」という用語は、sdfProperty とは無関係であることに注意してください。
For example, to include information about the type of the event in the "overTemperatureEvent" of Figure 4, the sdfOutputData there could be defined as follows:
たとえば、図 4 の「overTemperatureEvent」にイベントのタイプに関する情報を含めるには、そこにある sdfOutputData を次のように定義できます。
"sdfOutputData": {
"type": "object",
"properties": {
"alarmType": {
"sdfRef": "cap:#/sdfData/alarmTypes/quantityAlarms",
"const": "OverTemperatureAlarm"
},
"temperature": {
"sdfRef": "#/sdfObject/temperatureWithAlarm/sdfData/temperatureData"
}
}
}
Figure 6: Using Object Type with sdfOutputData
図 6: sdfOutputData でのオブジェクト タイプの使用
JSO-based keywords are also used in the specification techniques of a number of ecosystems, but some adjustments may be required.
JSO ベースのキーワードは、多くのエコシステムの仕様手法でも使用されますが、いくつかの調整が必要な場合があります。
For instance, [OCF] is based on Swagger 2.0, which appears to be based on "draft-4" [JSO4] [JSO4V] (also called draft-5, but semantically intended to be equivalent to draft-4). The "exclusiveMinimum" and "exclusiveMaximum" keywords use the Boolean form there, so on import to SDF, their values have to be replaced by the values of the respective "minimum"/"maximum" keyword, which are then removed; the reverse transformation applies on export.
たとえば、[OCF] は Swagger 2.0 に基づいており、これは「draft-4」[JSO4] [JSO4V] (draft-5 とも呼ばれますが、意味的にはdraft-4 と同等であることが意図されています) に基づいているようです。「exclusiveMinimum」および「exclusiveMinimum」キーワードはそこでブール形式を使用するため、SDF にインポートするときに、それらの値をそれぞれの「minimum」/「maximum」キーワードの値で置き換える必要があり、その後削除されます。逆変換はエクスポート時に適用されます。
This informative appendix contains two examples illustrating different composition approaches using the sdfThing quality.
この有益な付録には、sdfThing 品質を使用したさまざまな合成アプローチを示す 2 つの例が含まれています。
{
"sdfThing": {
"outlet-strip": {
"label": "Outlet strip",
"description": "Contains a number of Sockets",
"sdfObject": {
"socket": {
"description": "An array of sockets in the outlet strip",
"minItems": 2,
"maxItems": 10
}
}
}
}
}
Figure 7: Outlet Strip Example
図 7: コンセント ストリップの例
{
"sdfThing": {
"refrigerator-freezer": {
"description": "A refrigerator combined with a freezer",
"sdfProperty": {
"status": {
"type": "boolean",
"description":
"Indicates if the refrigerator-freezer is powered"
}
},
"sdfObject": {
"refrigerator": {
"description": "A refrigerator compartment",
"sdfProperty": {
"temperature": {
"sdfRef": "#/sdfProperty/temperature",
"maximum": 8
}
}
},
"freezer": {
"label": "A freezer compartment",
"sdfProperty": {
"temperature": {
"sdfRef": "#/sdfProperty/temperature",
"maximum": -6
}
}
}
}
}
},
"sdfProperty": {
"temperature": {
"description": "The temperature for this compartment",
"type": "number",
"unit": "Cel"
}
}
}
Figure 8: Refrigerator-Freezer Example
図 8: 冷蔵庫/冷凍庫の例
This appendix is informative.
この付録は有益です。
The present document provides the base SDF definition. Previous revisions of SDF, as defined in earlier drafts of this specification, have been in use for several years; both significant collections of older SDF models and older SDF conversion tools are available today. This appendix provides a brief checklist that can aid in upgrading these to the standard.
このドキュメントは、基本的な SDF 定義を提供します。この仕様の以前の草案で定義されている SDF の以前のリビジョンは、数年間使用されてきました。古い SDF モデルの重要なコレクションと古い SDF 変換ツールの両方が現在入手可能です。この付録では、これらを標準にアップグレードする際に役立つ簡単なチェックリストを提供します。
* The quality unit was previously called units.
* 品質単位は以前は単位と呼ばれていました。
* sdfType was developed out of a concept previously called subtype.
* sdfType は、以前はサブタイプと呼ばれていた概念に基づいて開発されました。
* sdfChoice is the preferred way to represent JSO enum (only a limited form of which is retained) and also the way to represent JSO anyOf.
* sdfChoice は、JSO enum (限られた形式のみが保持されます) を表すための推奨される方法であり、JSO anyOf を表す方法でもあります。
* The length of text strings (as used with minLength/maxLength constraints) was previously defined in bytes. It now is defined as the number of characters (Unicode scalar values, to be exact); a length in bytes is not meaningful unless bound to a specific encoding, which might differ from UTF-8 in some ecosystem mappings and protocol bindings.
* テキスト文字列の長さ (minLength/maxLength 制約で使用されるもの) は、以前はバイト単位で定義されていました。現在は文字数 (正確には Unicode スカラー値) として定義されています。バイト単位の長さは、特定のエンコーディングにバインドされていない限り意味がありません。エンコーディングは、一部のエコシステム マッピングやプロトコル バインディングにおいて UTF-8 とは異なる場合があります。
Figure 1:
図1:
A Simple Example of an SDF Document
SDF 文書の簡単な例
Figure 2:
図2:
Main Classes Used in SDF Models
SDF モデルで使用される主なクラス
Figure 3:
図3:
Example sdfObject Definition
sdfObject 定義の例
Figure 4:
図4:
Using sdfRequired
sdfの使用必須
Figure 5:
図5:
Using an Override to Further Restrict the Set of Data Values
オーバーライドを使用してデータ値のセットをさらに制限する
Figure 6:
図6:
Using Object Type with sdfOutputData
sdfOutputData でのオブジェクト タイプの使用
Figure 7:
図 7:
Outlet Strip Example
アウトレットストリップの例
Figure 8:
図 8:
Refrigerator-Freezer Example
冷蔵庫・冷凍庫の例
Table 1:
表 1:
Qualities of the Information Block
情報ブロックの品質
Table 2:
表 2:
Namespaces Block
名前空間ブロック
Table 3:
表 3:
Common Qualities
共通の特質
Table 4:
表 4:
SDF-Defined Qualities of sdfData and sdfProperty
sdfData および sdfProperty の SDF 定義の品質
Table 5:
表 5:
Values Defined in Base SDF for the sdfType Quality
Base SDF で定義された sdfType 品質の値
Table 6:
表6:
Qualities of sdfObject
sdfObject の品質
Table 7:
表 7:
Qualities of sdfProperty
sdfPropertyの品質
Table 8:
表 8:
Qualities of sdfAction
sdfAction の品質
Table 9:
表 9:
Qualities of sdfEvent
sdfEvent の品質
Table 10:
表 10:
Qualities of sdfThing
SDFThingの性質
Table 11:
表 11:
Media Type Registration for SDF
SDF のメディア タイプの登録
Table 12:
表 12:
SDF Content-Format Registration
SDF コンテンツ形式の登録
Table 13:
表 13:
Initial Content of the SDF Quality Names Registry
SDF 品質名レジストリの初期コンテンツ
This specification is based on work by the One Data Model group.
この仕様は、One Data Model グループによる作業に基づいています。
Jan Romann
Universität Bremen
Germany
Email: jan.romann@uni-bremen.de
Wouter van der Beek
Cascoda Ltd.
Threefield House
Threefield Lane
Southampton
United Kingdom
Email: w.vanderbeek@cascoda.com
Michael Koster (editor)
KTC Control AB
29415 Alderpoint Road
Blocksburg, CA 95514
United States of America
Phone: +1-707-502-5136
Email: michaeljohnkoster@gmail.com
Carsten Bormann (editor)
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Ari Keränen
Ericsson
FI-02420 Jorvas
Finland
Email: ari.keranen@ericsson.com