rfc9880.original   rfc9880.txt 
ASDF M. Koster, Ed. Internet Engineering Task Force (IETF) M. Koster, Ed.
Internet-Draft KTC Control AB Request for Comments: 9880 KTC Control AB
Intended status: Standards Track C. Bormann, Ed. Category: Standards Track C. Bormann, Ed.
Expires: 28 January 2026 Universität Bremen TZI ISSN: 2070-1721 Universität Bremen TZI
A. Keränen A. Keränen
Ericsson Ericsson
27 July 2025 October 2025
Semantic Definition Format (SDF) for Data and Interactions of Things Semantic Definition Format (SDF) for Data and Interactions of Things
draft-ietf-asdf-sdf-24
Abstract Abstract
The Semantic Definition Format (SDF) is concerned with Things, namely The Semantic Definition Format (SDF) is concerned with Things, namely
physical objects that are available for interaction over a network. physical objects that are available for interaction over a network.
SDF is a format for domain experts to use in the creation and SDF is a format for domain experts to use in the creation and
maintenance of data and interaction models that describe Things. An maintenance of data and interaction models that describe Things. An
SDF specification describes definitions of SDF Objects/SDF Things and SDF specification describes definitions of SDF Objects/SDF Things and
their associated interactions (Events, Actions, Properties), as well their associated interactions (Events, Actions, and Properties), as
as the Data types for the information exchanged in those well as the Data types for the information exchanged in those
interactions. Tools convert this format to database formats and interactions. Tools convert this format to database formats and
other serializations as needed. other serializations as needed.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf/.
Discussion of this document takes place on the A Semantic Definition
Format for Data and Interactions of Things (ASDF) Working Group
mailing list (mailto:asdf@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/asdf/. Subscribe at
https://www.ietf.org/mailman/listinfo/asdf/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-asdf/SDF.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 28 January 2026. 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.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
1.1. Structure of This Document . . . . . . . . . . . . . . . 4 1.1. Structure of This Document
1.2. Terminology and Conventions . . . . . . . . . . . . . . . 5 1.2. Terminology and Conventions
Programming Platform Terms . . . . . . . . . . . . . . . . . 5 Programming Platform Terms
Conceptual Terms . . . . . . . . . . . . . . . . . . . . . . 6 Conceptual Terms
Specification Language Terms . . . . . . . . . . . . . . . . 6 Specification Language Terms
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 Conventions
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Overview
2.1. Example Definition . . . . . . . . . . . . . . . . . . . 9 2.1. Example Definition
2.2. Elements of an SDF model . . . . . . . . . . . . . . . . 11 2.2. Elements of an SDF Model
2.2.1. sdfObject . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1. sdfObject
2.2.2. sdfProperty . . . . . . . . . . . . . . . . . . . . . 13 2.2.2. sdfProperty
2.2.3. sdfAction . . . . . . . . . . . . . . . . . . . . . . 14 2.2.3. sdfAction
2.2.4. sdfEvent . . . . . . . . . . . . . . . . . . . . . . 15 2.2.4. sdfEvent
2.2.5. sdfData . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.5. sdfData
2.2.6. sdfThing . . . . . . . . . . . . . . . . . . . . . . 16 2.2.6. sdfThing
2.3. Member names: Given Names and Quality Names . . . . . . . 16 2.3. Member Names: Given Names and Quality Names
2.3.1. Given Names and Quality Names . . . . . . . . . . . . 16 2.3.1. Given Names and Quality Names
2.3.2. Hierarchical Names . . . . . . . . . . . . . . . . . 17 2.3.2. Hierarchical Names
2.3.3. Extensibility of Given Names and Quality Names . . . 18 2.3.3. Extensibility of Given Names and Quality Names
3. SDF Structure
3. SDF structure . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. Information Block
3.1. Information block . . . . . . . . . . . . . . . . . . . . 19 3.2. Namespaces Block
3.2. Namespaces block . . . . . . . . . . . . . . . . . . . . 21 3.3. Definitions Block
3.3. Definitions block . . . . . . . . . . . . . . . . . . . . 22 3.4. Top-Level Affordances and sdfData
3.4. Top-level Affordances and sdfData . . . . . . . . . . . . 23 4. Names and Namespaces
4. Names and namespaces . . . . . . . . . . . . . . . . . . . . 23 4.1. Structure
4.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2. Contributing Global Names
4.2. Contributing global names . . . . . . . . . . . . . . . . 24 4.3. Referencing Global Names
4.3. Referencing global names . . . . . . . . . . . . . . . . 25 4.4. sdfRef
4.4. sdfRef . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4.1. Resolved Models
4.4.1. Resolved models . . . . . . . . . . . . . . . . . . . 28 4.5. sdfRequired
4.5. sdfRequired . . . . . . . . . . . . . . . . . . . . . . . 29 4.6. Common Qualities
4.6. Common Qualities . . . . . . . . . . . . . . . . . . . . 32 4.7. Data Qualities
4.7. Data Qualities . . . . . . . . . . . . . . . . . . . . . 32 4.7.1. sdfType
4.7.1. sdfType . . . . . . . . . . . . . . . . . . . . . . . 34 4.7.2. sdfChoice
4.7.2. sdfChoice . . . . . . . . . . . . . . . . . . . . . . 35 5. Keywords for Definition Groups
5. Keywords for definition groups . . . . . . . . . . . . . . . 37 5.1. sdfObject
5.1. sdfObject . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2. sdfProperty
5.2. sdfProperty . . . . . . . . . . . . . . . . . . . . . . . 38 5.3. sdfAction
5.3. sdfAction . . . . . . . . . . . . . . . . . . . . . . . . 39 5.4. sdfEvent
5.4. sdfEvent . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5. sdfData
5.5. sdfData . . . . . . . . . . . . . . . . . . . . . . . . . 40 6. High-Level Composition
6. High Level Composition . . . . . . . . . . . . . . . . . . . 40 6.1. Paths in the Model Namespaces
6.1. Paths in the model namespaces . . . . . . . . . . . . . . 41 6.2. Modular Composition
6.2. Modular Composition . . . . . . . . . . . . . . . . . . . 41 6.2.1. Use of the "sdfRef" Keyword to Reuse a Definition
6.2.1. Use of the "sdfRef" keyword to re-use a definition . 41 6.3. sdfThing
6.3. sdfThing . . . . . . . . . . . . . . . . . . . . . . . . 42 7. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7.1. Media Type
7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 43 7.2. Content-Format
7.2. Content-Format . . . . . . . . . . . . . . . . . . . . . 44 7.3. IETF URN Sub-Namespace for Unit Names
7.3. IETF URN Sub-namespace for Unit Names (urn:ietf:params:unit)
(urn:ietf:params:unit) . . . . . . . . . . . . . . . . . 45 7.4. SenML Registry Group
7.4. SenML registry group . . . . . . . . . . . . . . . . . . 45 7.5. Registries
7.5. Registries . . . . . . . . . . . . . . . . . . . . . . . 46 7.5.1. SDF Quality Names
7.5.1. Quality Names . . . . . . . . . . . . . . . . . . . . 46 7.5.2. SDF Quality Name Prefixes
7.5.2. Quality Name Prefixes . . . . . . . . . . . . . . . . 48 7.5.3. sdfType Values
7.5.3. sdfType Values . . . . . . . . . . . . . . . . . . . 49 7.5.4. SDF Feature Names
7.5.4. Feature Names . . . . . . . . . . . . . . . . . . . . 49 8. Security Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 9. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 9.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 51 9.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 54 Appendix A. Formal Syntax of SDF
Appendix A. Formal Syntax of SDF . . . . . . . . . . . . . . . . 57 Appendix B. json-schema.org Rendition of SDF Syntax
Appendix B. json-schema.org Rendition of SDF Syntax . . . . . . 62 Appendix C. Data Qualities Inspired by json-schema.org
Appendix C. Data Qualities inspired by json-schema.org . . . . . 104 C.1. type "number", type "integer"
C.1. type "number", type "integer" . . . . . . . . . . . . . . 105 C.2. type "string"
C.2. type "string" . . . . . . . . . . . . . . . . . . . . . . 105 C.3. type "boolean"
C.3. type "boolean" . . . . . . . . . . . . . . . . . . . . . 106 C.4. type "array"
C.4. type "array" . . . . . . . . . . . . . . . . . . . . . . 106 C.5. type "object"
C.5. type "object" . . . . . . . . . . . . . . . . . . . . . . 106 C.6. Implementation Notes
C.6. Implementation notes . . . . . . . . . . . . . . . . . . 107 Appendix D. Composition Examples
Appendix D. Composition Examples . . . . . . . . . . . . . . . . 108 D.1. Outlet Strip Example
D.1. Outlet Strip Example . . . . . . . . . . . . . . . . . . 108 D.2. Refrigerator-Freezer Example
D.2. Refrigerator-Freezer Example . . . . . . . . . . . . . . 108 Appendix E. Some Changes From Earlier Drafts
Appendix E. Some Changes From Earlier Drafts . . . . . . . . . . 109 List of Figures
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . 110 List of Tables
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . 110 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 111 Contributors
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111
1. Introduction 1. Introduction
The Semantic Definition Format (SDF) is concerned with Things, namely The Semantic Definition Format (SDF) is concerned with Things, namely
physical objects that are available for interaction over a network. physical objects that are available for interaction over a network.
SDF is a format for domain experts to use in the creation and SDF is a format for domain experts to use in the creation and
maintenance of data and interaction models that describe Things. An maintenance of data and interaction models that describe Things. An
SDF specification describes definitions of SDF Objects/SDF Things and SDF specification describes definitions of SDF Objects/SDF Things and
their associated interactions (Events, Actions, Properties), as well their associated interactions (Events, Actions, and Properties), as
as the Data types for the information exchanged in those well as the Data types for the information exchanged in those
interactions. Tools convert this format to database formats and interactions. Tools convert this format to database formats and
other serializations as needed. other serializations as needed.
SDF is designed to be an extensible format. The present document SDF is designed to be an extensible format. The present document
constitutes the base specification for SDF: "base SDF" for short. In constitutes the base specification for SDF, "base SDF" for short. In
addition, SDF extensions can be defined, some of which may make use addition, SDF extensions can be defined, some of which may make use
of extension points specifically defined for this in base SDF. One of extension points specifically defined for this in base SDF. One
area for such extensions would be refinements of SDF's abstract area for such extensions would be refinements of SDF's abstract
interaction models into protocol bindings for specific ecosystems interaction models into protocol bindings for specific ecosystems
(e.g., [I-D.bormann-asdf-sdf-mapping]). For the use of certain other (e.g., [SDF-MAPPING]). For the use of certain other extensions, it
extensions, it may be necessary to indicate in the SDF document using may be necessary to indicate in the SDF document using them that a
them that a specific extension is in effect; see Section 3.1 for specific extension is in effect; see Section 3.1 for details of the
details of the features quality that can be used for such features quality that can be used for such indications. With
indications. With extension points and feature indications extension points and feature indications available, base SDF does not
available, base SDF does not define a "version" concept for the SDF define a "version" concept for the SDF format itself (as opposed to
format itself (as opposed to version indications within SDF documents version indications within SDF documents indicating their own
indicating their own evolution, see Section 3.1). evolution; see Section 3.1).
1.1. Structure of This Document 1.1. Structure of This Document
After introductory material and an overview (Section 2) over the After introductory material and an overview (Section 2) over the
elements of the model and over the different kinds of names used, elements of the model and the different kinds of names used,
Section 3 introduces the main components of an SDF model. Section 4 Section 3 introduces the main components of an SDF model. Section 4
revisits names and structures them into namespaces. Section 5 revisits names and structures them into namespaces. Section 5
discusses the inner structure of the Objects defined by SDF, the discusses the inner structure of the Objects defined by SDF, the
sdfObjects, in further detail. Section 6 discusses how SDF supports sdfObjects, in further detail. Section 6 discusses how SDF supports
composition. Conventional Sections (IANA Considerations, Security composition. Conventional Sections (IANA Considerations, Security
Considerations, Normative References, and Informative References) Considerations, Normative References, and Informative References)
follow. The normative Appendix A defines the syntax of SDF in terms follow. The normative Appendix A defines the syntax of SDF in terms
of its JSON structures, employing the Concise Data Definition of its JSON structures, employing the Concise Data Definition
Language (CDDL) [RFC8610]. This is followed by the informative Language (CDDL) [RFC8610]. This is followed by the informative
Appendix B, a rendition of the SDF syntax in a "JSON Schema" format Appendix B, a rendition of the SDF syntax in a "JSON Schema" format
skipping to change at page 5, line 21 skipping to change at line 188
The normative Appendix C defines certain terms ("data qualities") The normative Appendix C defines certain terms ("data qualities")
used at the SDF data model level that were inspired by JSO. The used at the SDF data model level that were inspired by JSO. The
informative Appendix D provides a few examples for the use of informative Appendix D provides a few examples for the use of
composition in SDF. Finally, Appendix E provides some historical composition in SDF. Finally, Appendix E provides some historical
information that can be useful in upgrading earlier, pre-standard SDF information that can be useful in upgrading earlier, pre-standard SDF
models and implementations to SDF base. models and implementations to SDF base.
1.2. Terminology and Conventions 1.2. Terminology and Conventions
Terms introduced in this section are capitalized when used in this Terms introduced in this section are capitalized when used in this
section; to maintain readability, capitalization is only done when section. To maintain readability, capitalization is only used when
needed where they are used in the body of this document. needed where they are used in the body of this document.
Programming Platform Terms Programming Platform Terms
The following definitions mention terms that are used with specific The following definitions mention terms that are used with specific
meanings in various programming platforms, but often have an meanings in various programming platforms, but often have an
independent definition for this document, which can be found further independent definition for this document, which can be found further
below in this section. below in this section.
Element: A generic term used here in its English sense. Element: A generic term used here in its English sense.
Exceptionally, in Appendix C, used explicitly in accordance with Exceptionally, in Appendix C, the term is used explicitly in
its meaning in the JSON ecosystem, i.e., the elements of JSON accordance with its meaning in the JSON ecosystem, i.e., the
arrays. elements of JSON arrays.
Entry: A key-value pair in a map. (In JSON maps, sometimes also Entry: A key-value pair in a map. (In JSON maps, sometimes also
called "member".) called "member".)
Map: A collection of entries (key-value pairs), where there are no Map: A collection of entries (key-value pairs) where there are no
two entries with equivalent keys. (Also known as associative two entries with equivalent keys. (Also known as associative
array, dictionary, or symbol table.) array, dictionary, or symbol table.)
Object: An otherwise very generic term that JavaScript (and thus Object: An otherwise very generic term that JavaScript (and thus
JSON) uses for the kind of maps that were part of the original JSON) uses for the kind of maps that were part of the original
languages from the outset. In this document, Object is used languages from the outset. In this document, Object is used
exclusively in its general English meaning or as the colloquial exclusively in its general English meaning or as the colloquial
shorthand for sdfObject, even if the type name "object" is shorthand for sdfObject, even if the type name "object" is
imported with JSON-related semantics from a data definition imported with JSON-related semantics from a data definition
language. language.
skipping to change at page 7, line 11 skipping to change at line 270
nested maps. nested maps.
SDF Model: Definitions and declarations that model the digital SDF Model: Definitions and declarations that model the digital
interaction opportunities offered by one or more kinds of Things, interaction opportunities offered by one or more kinds of Things,
represented by Groupings (sdfObjects and sdfThings). An SDF Model represented by Groupings (sdfObjects and sdfThings). An SDF Model
can be fully contained in a single SDF Document, or it can be can be fully contained in a single SDF Document, or it can be
built from an SDF Document that references definitions and built from an SDF Document that references definitions and
declarations from additional SDF documents. declarations from additional SDF documents.
Block: One or more entries in a JSON map that is part of an 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 specification. These entries can be described as a Block to
emphasize that they together serve a specific function. emphasize that they serve a specific function together.
Group: An entry in the main JSON map that represents the SDF Group: An entry in the main JSON map that represents the SDF
document, and in certain nested definitions. A group has a Class document, and in certain nested definitions. A group has a Class
Name Keyword as its key and a map of named definition entries Name Keyword as its key and a map of named definition entries
(Definition Group) as a value. (Definition Group) as a value.
Class Name Keyword: One of sdfThing, sdfObject, sdfProperty, Class Name Keyword: One of sdfThing, sdfObject, sdfProperty,
sdfAction, sdfEvent, or sdfData; the Classes for these type sdfAction, sdfEvent, or sdfData. The Classes for these type
keywords are capitalized and prefixed with sdf. keywords are capitalized and prefixed with sdf.
Class: Abstract term for the information that is contained in groups Class: Abstract term for the information that is contained in groups
identified by a Class Name Keyword. identified by a Class Name Keyword.
Quality: A metadata item in a definition or declaration which says Quality: A metadata item in a definition or declaration that says
something about that definition or declaration. A quality is something about that definition or declaration. A quality is
represented in SDF as an entry in a JSON map (JSON object) that represented in SDF as an entry in a JSON map (JSON object) that
serves as a definition or declaration. (The term "Quality" is serves as a definition or declaration. (The term "Quality" is
used because another popular term, "Property", already has a used because another popular term, "Property", already has a
different meaning.) different meaning.)
Definition: An entry in a Definition Group. The entry creates a new 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 semantic term for use in SDF models and associates it with a set
of qualities. Unless the Class Name Keyword of the Group also of qualities. Unless the Class Name Keyword of the Group also
makes it a Declaration (see Section 3.3), a definition just makes it a Declaration (see Section 3.3), a definition just
defines a term, it does not create a component item within the defines a term and it does not create a component item within the
enclosing definition. enclosing definition.
Declaration: A definition within an enclosing definition that is Declaration: A definition within an enclosing definition that is
intended to create a component item within that enclosing intended to create a component item within that enclosing
definition. Every declaration can also be used as a definition definition. Every declaration can also be used as a definition
for reference elsewhere. for reference elsewhere.
Grouping: An sdfThing or sdfObject, i.e., (directly or indirectly) a Grouping: An sdfThing or sdfObject, i.e., (directly or indirectly) a
description for a combination of Affordances. description for a combination of Affordances.
Object, sdfObject: A Grouping that contains Affordance declarations Object, sdfObject: A Grouping that contains Affordance declarations
(Property, Action, and Event declarations) only. It serves as the (Property, Action, and Event declarations) only. It serves as the
main "atom" of reusable semantics for model construction, main "atom" of reusable semantics for model construction,
representing the interaction model for a Thing that is simple representing the interaction model for a Thing that is simple
enough to not require nested structure. sdfObjects are therefore enough to not require a nested structure. Therefore, sdfObjects
similar to sdfThings but do not allow nesting, i.e., they cannot are similar to sdfThings, but do not allow nesting, i.e., they
contain other Groupings (sdfObjects or sdfThings). cannot contain other Groupings (sdfObjects or sdfThings).
sdfThing: A Grouping that can contain nested Groupings (sdfThings sdfThing: A Grouping that can contain nested Groupings (sdfThings
and sdfObjects). Like sdfObject, it can also contain Affordance and sdfObjects). Like sdfObject, it can also contain Affordance
declarations (Property, Action, and Event declarations). (Note declarations (Property, Action, and Event declarations). (Note
that "Thing" has a different meaning from sdfThing and therefore that "Thing" has a different meaning from sdfThing and is
is not available as a colloquial shorthand of sdfThing.) therefore not available as a colloquial shorthand of sdfThing.)
Augmentation Mechanism: A companion document to a base SDF Model Augmentation Mechanism: A companion document to a base SDF Model
that provides additional information ("augments" the base that provides additional information ("augments" the base
specification). The information may be for use in a specific specification). The information may be for use in a specific
ecosystem or with a specific protocol ("Protocol Binding"). No ecosystem or with a specific protocol ("Protocol Binding"). No
specific Augmentation Mechanisms are defined in base SDF. A specific Augmentation Mechanisms are defined in base SDF. A
simple mechanism for such augmentations has been discussed as a simple mechanism for such augmentations has been discussed as a
"mapping file" [I-D.bormann-asdf-sdf-mapping]. "mapping file" [SDF-MAPPING].
Protocol Binding: A companion document to an SDF Model that defines Protocol Binding: A companion document to an SDF Model that defines
how to map the abstract concepts in the model into the protocols how to map the abstract concepts in the model into the protocols
in use in a specific ecosystem. The Protocol Binding might supply that are in use in a specific ecosystem. The Protocol Binding
URL components, numeric IDs, and similar details. Protocol might supply URL components, numeric IDs, and similar details.
Bindings are one case of an Augmentation Mechanism. Protocol Bindings are one case of an Augmentation Mechanism.
Conventions Conventions
Regular expressions that are used in the text as a "pattern" for some Regular expressions that are used in the text as a "pattern" for some
string are interpreted as per [RFC9485]. (Note that a form of string are interpreted as per [RFC9485]. (Note that a form of
regular expressions is also used as values of the quality pattern; regular expressions is also used as values of the quality pattern;
see Appendix C.2.) see Appendix C.2.)
The term "URI" in this document always refers to "full" URIs ("URI" The term "URI" in this document always refers to "full" URIs ("URI"
in Section 3 of RFC 3986 [STD66]), never to relative URI references 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 ("relative-ref" in Section 4.1 of RFC 3986 [STD66]), so the term
"URI" does _NOT_ serve as the colloquial abbreviation of "URI- "URI" does _NOT_ serve as the colloquial abbreviation of "URI-
Reference" it is often used for. Therefore, the "reference Reference" it is often used for. Therefore, the "reference
resolution" process defined in Section 5 of RFC 3986 [STD66] is _NOT_ resolution" process defined in Section 5 of RFC 3986 [STD66] is _NOT_
used in this specification. Where necessary, full URIs are assembled used in this specification. Where necessary, full URIs are assembled
out of substrings by simple concatenation, e.g. when CURIEs are 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 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 namespace absolute-URI (Section 5 of RFC 3986 [STD66]) and a fragment
identifier part (Section 4.1). Note also that URIs are not only used 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 to construct the SDF models, they are also the _subject_ of SDF
models where they are used as data in actual interactions (and could models where they are used as data in actual interactions (and could
even be represented as relative references there); these two usages even be represented as relative references there); these two usages
are entirely separate. are entirely separate.
The singular form is chosen as the preferred one for the keywords The singular form is chosen as the preferred one for the keywords
defined in this specification. defined in this specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview 2. Overview
2.1. Example Definition 2.1. Example Definition
The overview starts with an example for the SDF definition of a The overview starts with an example for the SDF definition of a
simple sdfObject called "Switch" (Figure 1). simple sdfObject called "Switch" (Figure 1).
{ {
skipping to change at page 10, line 43 skipping to change at line 412
}, },
"toggle": { "toggle": {
"description": "description":
"Toggle the switch; equivalent to setting value to its complement." "Toggle the switch; equivalent to setting value to its complement."
} }
} }
} }
} }
} }
Figure 1: A simple example of an SDF document Figure 1: A Simple Example of an SDF Document
This is a model of a switch. The state value declared in the This is a model of a switch. The state value declared in the
sdfProperty group, represented by a Boolean, will be true for "on" 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 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 sdfAction group are redundant with setting the value and are in the
example to illustrate that there are often different ways of example to illustrate that there are often different ways of
achieving the same effect. The action toggle will invert the value achieving the same effect. The action toggle will invert the value
of the sdfProperty value, so that 2-way switches can be created; of the sdfProperty value so that 2-way switches can be created;
having such action will avoid the need for first retrieving the having such action will avoid the need for retrieving the current
current value and then applying/setting the inverted value. value first and then applying/setting the inverted value.
The sdfObject group lists the affordances of Things modeled by this The sdfObject group lists the affordances of Things modeled by this
sdfObject. The sdfProperty group lists the property affordances sdfObject. The sdfProperty group lists the property affordances
described by the model; these represent various perspectives on the described by the model; these represent various perspectives on the
state of the sdfObject. Properties can have additional qualities to state of the sdfObject. Properties can have additional qualities to
describe the state more precisely. Properties can be annotated to be describe the state more precisely. Properties can be annotated to be
read, write or read/write; how this is actually done by the read, write, or read/write; how this is actually done by the
underlying transfer protocols is not described in the SDF model but underlying transfer protocols is not described in the SDF model but
left to companion protocol bindings. Properties are often used with left to companion protocol bindings. Properties are often used with
RESTful paradigms [I-D.irtf-t2trg-rest-iot], describing state. The RESTful paradigms [REST-IOT] describing state. The sdfAction group
sdfAction group is the mechanism to describe other interactions in is the mechanism to describe other interactions in terms of their
terms of their names, input, and output data (no data are used in the names, input, and output data (no data are used in the example), as
example), as in a POST method in REST or in a remote procedure call. in a POST method in REST or in a remote procedure call. The example
The example toggle is an Action that changes the state based on the toggle is an Action that changes the state based on the current state
current state of the Property named value. (The third type of of the Property named value. (The third type of affordance is
affordance is Events, which are not described in this example.) Events, which are not described in this example.)
In the JSON representation, the info group is an exception in that 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 this group's map has keys taken from the SDF vocabulary. All other
groups (such as namespace, sdfObject) have maps with keys that are groups (such as namespace and sdfObject) have maps with keys that are
freely defined by the model writer (Switch, value, on, etc.); these freely defined by the model writer (Switch, value, on, etc.). These
map keys are therefore called _given names_. The groups made up of map keys are therefore called _given names_. The groups made up of
entries with given names as keys usually use the named<> production entries with given names as keys usually use the named<> production
in the formal syntax of SDF (Appendix A). Where the values of these 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, entries are maps, these again use SDF vocabulary keys, and so on,
generally alternating in further nesting. The SDF-defined vocabulary generally alternating in further nesting. The SDF-defined vocabulary
items used in the hierarchy of such groups are often, but not always, items used in the hierarchy of such groups are often, but not always,
called _quality names_ or _qualities_. See Section 2.3 for more called _quality names_ or _qualities_. See Section 2.3 for more
information about naming in SDF. information about naming in SDF.
2.2. Elements of an SDF model 2.2. Elements of an SDF Model
The SDF language uses six predefined Class Name Keywords for modeling The SDF language uses six predefined Class Name Keywords for modeling
connected Things which are illustrated in Figure 2 (limited rendition connected Things, which are illustrated in Figure 2 (limited
in the plaintext form of this document, please use typographic forms rendition in the plaintext form of this document, please use
for full information). typographic forms for full information).
,--------. ,--------.
|sdfThing|------. |sdfThing|------.
,--------------|--------| | hasThing ,--------------|--------| | hasThing
| |--------|<-----' | |--------|<-----'
| `--------' | `--------'
| | | | | | | |
| hasObject | | \ | hasObject | | \
| v | \ | v | \
| ,---------. | \ | ,---------. | \
skipping to change at page 12, line 34 skipping to change at line 489
`-----------' `---------' `--------' `-----------' `---------' `--------'
| hasInput| |hasOutput | | hasInput| |hasOutput |
| Data| |Data | | Data| |Data |
| v v | | v v |
| ,-------. | | ,-------. |
| isInst |sdfData| hasOutp | | isInst |sdfData| hasOutp |
`----------->|-------|<----------' `----------->|-------|<----------'
anceOf |-------| utData anceOf |-------| utData
`-------' `-------'
Figure 2: Main classes used in SDF models Figure 2: Main Classes Used in SDF Models
The six main Class Name Keywords are discussed below. The six main Class Name Keywords are discussed below.
2.2.1. sdfObject 2.2.1. sdfObject
sdfObjects, the items listed in an sdfObject definition group, are sdfObjects, the items listed in an sdfObject definition group, are
the main "atom" of reusable semantics for model construction. The the main "atom" of reusable semantics for model construction. The
concept aligns in scope with common definition items from many IoT concept aligns in scope with common definition items from many IoT
modeling systems, for example ZigBee Clusters [ZCL], OMA SpecWorks modeling systems, e.g., ZigBee Clusters [ZCL], OMA SpecWorks LwM2M
LwM2M Objects [OMA], OCF Resource Types [OCF], and W3C Web of Things Objects [OMA], OCF Resource Types [OCF], and W3C Web of Things [WoT].
[WoT].
An sdfObject definition contains a set of sdfProperty, sdfAction, and An sdfObject definition contains a set of sdfProperty, sdfAction, and
sdfEvent definitions that describe the interaction affordances sdfEvent definitions that describe the interaction affordances
associated with some scope of functionality. associated with some scope of functionality.
For the granularity of definition, sdfObject definitions are meant to For the granularity of definition, sdfObject definitions are meant to
be kept narrow enough in scope to enable broad reuse and be kept narrow enough in scope to enable broad reuse and
interoperability. For example, defining a light bulb using separate interoperability. For example, defining a light bulb using separate
sdfObject definitions for on/off control, dimming, and color control sdfObject definitions for on/off control, dimming, and color control
affordances will enable interoperable functionality to be configured affordances will enable interoperable functionality to be configured
skipping to change at page 13, line 34 skipping to change at line 534
by the enclosing grouping. by the enclosing grouping.
A named definition entry in an sdfProperty may be associated with A named definition entry in an sdfProperty may be associated with
some protocol affordance to enable the application to obtain the some protocol affordance to enable the application to obtain the
state variable and, optionally, modify the state variable. state variable and, optionally, modify the state variable.
Additionally, some protocols provide for in-time reporting of state Additionally, some protocols provide for in-time reporting of state
changes. (These three aspects are described by the qualities changes. (These three aspects are described by the qualities
readable, writable, and observable defined for an sdfProperty.) readable, writable, and observable defined for an sdfProperty.)
Definitions in sdfProperty groups look like the definitions in Definitions in sdfProperty groups look like the definitions in
sdfData groups. However, they actually also declare that a Property sdfData groups. However, they actually declare that a Property with
with the given qualities potentially is present in the containing the given qualities potentially is present in the containing
sdfObject. sdfObject.
For definitions in sdfProperty and sdfData, SDF provides qualities For definitions in sdfProperty and sdfData, SDF provides qualities
that can constrain the structure and values of data allowed in the that can constrain the structure and values of data allowed in the
interactions modeled by them. It also provides qualities that interactions modeled by them. It also provides qualities that
associate semantics to these data, such as engineering units and unit associate semantics to this data, such as engineering units and unit
scaling information. scaling information.
For the data definition within sdfProperty or sdfData, SDF borrows For the data definition within sdfProperty or sdfData, SDF borrows
some vocabulary proposed for the drafts 4 [JSO4] [JSO4V] and 7 [JSO7] some vocabulary proposed for drafts 4 [JSO4] [JSO4V] and 7 [JSO7]
[JSO7V] of the json-schema.org "JSON Schema" format (collectively [JSO7V] of the json-schema.org "JSON Schema" format (collectively
called JSO here), enhanced by qualities that are specific to SDF. called JSO here), enhanced by qualities that are specific to SDF.
Details about the JSO-inspired vocabulary are in Appendix C. For Details about the JSO-inspired vocabulary are in Appendix C. For
base SDF, data are constrained to be of simple types (number, string, base SDF, data are constrained to be of simple types (number, string,
Boolean), JSON maps composed of named data, and arrays of these Boolean), JSON maps composed of named data, and arrays of these
types. Syntax extension points are provided that can be used to types. Syntax extension points are provided that can be used to
provide richer types in a future extension of this specification provide richer types in a future extension of this specification
(possibly more of which can be borrowed from json-schema.org). (possibly more of which can be borrowed from json-schema.org).
Note that sdfProperty definitions (and sdfData definitions in Note that sdfProperty definitions (and sdfData definitions in
skipping to change at page 14, line 31 skipping to change at line 570
2.2.3. sdfAction 2.2.3. sdfAction
The sdfAction group contains declarations of Actions, which model The sdfAction group contains declarations of Actions, which model
affordances that, when triggered, have an effect that can go beyond affordances that, when triggered, have an effect that can go beyond
just reading, updating, or observing Thing state. Actions often just reading, updating, or observing Thing state. Actions often
result in some outward physical effect (which, itself, cannot be result in some outward physical effect (which, itself, cannot be
modeled in SDF). From a programmer's perspective, they might be modeled in SDF). From a programmer's perspective, they might be
considered to be roughly analogous to method calls. considered to be roughly analogous to method calls.
Actions may have data parameters: these are modeled as a single item Actions may have data parameters; these are each modeled as a single
of input data and output data, each. Where multiple parameters need item of input data and output data. Where multiple parameters need
to be modeled, an "object" type can be used to combine these 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. parameters into one; for an example, see Figure 6 in Appendix C.5.
Actions may be long-running, that is to say that the effects may not 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 take place immediately as would be expected for an update to an
sdfProperty; the effects may play out over time and emit action sdfProperty; the effects may play out over time and emit action
results. Actions may also not always complete and may result in results. Actions may also not always complete and may result in
application errors, such as an item blocking the closing of an application errors, such as an item blocking the closing of an
automatic door. automatic door.
One idiom for giving an action initiator status and control about the One idiom for giving an action initiator status and control about the
ongoing action is to provide a URI for an ephemeral "action resource" ongoing action is to provide a URI for an ephemeral "action resource"
in the sdfAction output data, allowing the action to deliver in the sdfAction output data, allowing the action to deliver
immediate feedback (including errors that prevent the action from immediate feedback (including errors that prevent the action from
starting) and the action initiator to use the action resource for starting) and the action initiator to use the action resource for
further observation or modification of the ongoing action (including further observation or modification of the ongoing action (including
canceling it). Base SDF does not provide any tailored support for canceling it). Base SDF does not provide any tailored support for
describing such action resources; an extension for modeling links in describing such action resources; an extension for modeling links in
more detail (for instance, [I-D.bormann-asdf-sdftype-link]) may be more detail (for instance, [SDFTYPE-LINK]) may be all that is needed
all that is needed to fully enable modeling them. to fully enable modeling them.
Actions may have (or lack) the characteristics of idempotence and Actions may have (or lack) the characteristics of idempotence and
side-effect safety (see Section 9.2 of RFC 9110 [STD97] for more on side-effect safety (see Section 9.2 of RFC 9110 [STD97] for more on
these terms). these terms).
Base SDF only provides data constraint modeling and semantics for the Base SDF only provides data constraint modeling and semantics for the
input and output data of definitions in sdfAction groups. Again, input and output data of definitions in sdfAction groups. Again,
data definitions for payloads of protocol messages, and detailed data definitions for payloads of protocol messages, and detailed
protocol settings for invoking the action, are expected to be part of protocol settings for invoking the action, are expected to be part of
the protocol binding. the protocol binding.
2.2.4. sdfEvent 2.2.4. sdfEvent
The sdfEvent group contains declarations of Events, which model The sdfEvent group contains declarations of Events, which model
affordances that inform about "happenings" associated with a Thing affordances that inform about "happenings" associated with a Thing
modeled by the enclosing sdfObject; these may result in a signal modeled by the enclosing sdfObject; these may result in a signal
being stored or emitted as a result. being stored or emitted as a result.
Note that there is a trivial overlap with sdfProperty state changes, Note that there is a trivial overlap with sdfProperty state changes,
which may also be defined as events but are not generally required to which may also be defined as Events but are not generally required to
be defined as such. However, Events may exhibit certain ordering, be defined as such. However, Events may exhibit certain ordering,
consistency, and reliability requirements that are expected to be consistency, and reliability requirements that are expected to be
supported in various implementations of sdfEvent that do distinguish supported in various implementations of sdfEvent that do distinguish
sdfEvent from sdfProperty. For instance, while a state change may sdfEvent from sdfProperty. For instance, while a state change may
simply be superseded by another state change, some events are simply be superseded by another state change, some Events are
"precious" and need to be preserved even if further events follow. "precious" and need to be preserved even if further Events follow.
Base SDF only provides data constraint modeling and semantics for the Base SDF only provides data constraint modeling and semantics for the
output data of Event affordances. Again, data definitions for output data of Event affordances. Again, data definitions for
payloads of protocol messages, and detailed protocol settings for payloads of protocol messages, and detailed protocol settings for
soliciting the event, are expected to be part of the protocol soliciting the event, are expected to be part of the protocol
binding. binding.
2.2.5. sdfData 2.2.5. sdfData
Definitions in sdfData groups do not themselves specify affordances. Definitions in sdfData groups do not themselves specify affordances.
skipping to change at page 16, line 8 skipping to change at line 639
groups to enable common modeling patterns, data constraints, and groups to enable common modeling patterns, data constraints, and
semantic anchor concepts to be factored out for data items that make semantic anchor concepts to be factored out for data items that make
up sdfProperty items and serve as input and output data for sdfAction up sdfProperty items and serve as input and output data for sdfAction
and sdfEvent items. The data types defined in sdfData definitions and sdfEvent items. The data types defined in sdfData definitions
only spring to life by being referenced in one of these contexts only spring to life by being referenced in one of these contexts
(directly or indirectly via some other sdfData definitions). (directly or indirectly via some other sdfData definitions).
It is a common use case for such a data definition to be shared 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 between an sdfProperty item and input or output parameters of an
sdfAction or output data provided by an sdfEvent. sdfData definitions sdfAction or output data provided by an sdfEvent. sdfData definitions
also enable factoring out extended application data types such as also enable factoring out extended application data types, such as
mode and machine state enumerations to be reused across multiple mode and machine state enumerations to be reused across multiple
definitions that have similar basic characteristics and requirements. definitions that have similar basic characteristics and requirements.
2.2.6. sdfThing 2.2.6. sdfThing
Back at the top level, the sdfThing group enables definition of Back at the top level, the sdfThing group enables definition of
models for complex devices that will use one or more sdfObject models for complex devices that will use one or more sdfObject
definitions. Like sdfObject, sdfThing groups allow for the inclusion definitions. Like sdfObject, sdfThing groups allow for the inclusion
of interaction affordances, sdfData, as well as "minItems" and of interaction affordances, sdfData, as well as "minItems" and
"maxItems" qualities. Therefore, they can be seen as a superset of "maxItems" qualities. Therefore, they can be seen as a superset of
sdfObject groups, additionally allowing for composition. sdfObject groups, additionally allowing for composition.
As a result, an sdfThing directly or indirectly contains a set of As a result, an sdfThing directly or indirectly contains a set of
sdfProperty, sdfAction, and sdfEvent definitions that describe the sdfProperty, sdfAction, and sdfEvent definitions that describe the
interaction affordances associated with some scope of functionality. interaction affordances associated with some scope of functionality.
A definition in an sdfThing group can refine the metadata of the A definition in an sdfThing group can refine the metadata of the
definitions it is composed of: other definitions in sdfThing groups definitions it is composed of: other definitions in sdfThing groups
or definitions in sdfObject groups. or definitions in sdfObject groups.
2.3. Member names: Given Names and Quality Names 2.3. Member Names: Given Names and Quality Names
SDF documents are JSON maps that mostly employ JSON maps as member SDF documents are JSON maps that mostly employ JSON maps as member
values, which in turn mostly employ JSON maps as their member values, 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 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. 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 (In certain cases, where member names are not needed, JSON arrays may
be interspersed in this tree.) be interspersed in this tree.)
2.3.1. Given Names and Quality Names 2.3.1. Given Names and Quality Names
For any particular JSON map in an SDF document, the set of member For any particular JSON map in an SDF document, the set of member
names that are used is either of: names that are used is either:
* A set of "_Quality Names_", where the entries in the map are * A set of "_Quality Names_", where the entries in the map are
Qualities. Quality Names are defined by the present specification Qualities. Quality Names are defined by the present specification
and its extensions, together with specific semantics to be and its extensions, together with specific semantics to be
associated with the member value given with a certain Quality associated with the member value given with a certain Quality
Name. Name.
* A set of "_Given Names_", where the entries in the map are * A set of "_Given Names_", where the entries in the map are
separate entities (definitions, declarations, etc.) that each have separate entities (definitions, declarations, etc.) that each have
names that are chosen by the SDF document author in order that names that are chosen by the SDF document author in order that
skipping to change at page 17, line 32 skipping to change at line 712
From the outside of a specification, Given Names are usually used as From the outside of a specification, Given Names are usually used as
part of a hierarchical name that looks like a JSON pointer [RFC6901], part of a hierarchical name that looks like a JSON pointer [RFC6901],
itself generally rooted in (used as the fragment identifier in) an itself generally rooted in (used as the fragment identifier in) an
outer namespace that looks like an https:// URL (see Section 4). outer namespace that looks like an https:// URL (see Section 4).
As Quality Names and Given Names roughly alternate in a path into the As Quality Names and Given Names roughly alternate in a path into the
model, the JSON pointer part of the hierarchical name also alternates model, the JSON pointer part of the hierarchical name also alternates
between Quality Names and Given Names. between Quality Names and Given Names.
Note that the actual Given Names may need to be encoded when Note that the actual Given Names may need to be encoded when
specified via the JSON pointer fragment identifier syntax, and that specified via the JSON pointer fragment identifier syntax. There are
there are two layers of such encoding: tilde encoding of ~ and / as two layers of such encoding: tilde encoding of ~ and / as per
per Section 3 of [RFC6901], and then percent encoding of the tilde- 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]. encoded name into a valid URI fragment as per Section 6 of [RFC6901].
For example, when a model is using the Given Name For example, when a model is using the Given Name
warning/danger alarm warning/danger alarm
(with an embedded slash and a space) for an sdfObject, that sdfObject (with an embedded slash and a space) for an sdfObject, that sdfObject
may need to be referenced as may need to be referenced as
#/sdfObject/warning~1danger%20alarm #/sdfObject/warning~1danger%20alarm
To sidestep potential interoperability problems, it is probably wise To sidestep potential interoperability problems, it is probably wise
to avoid characters in Given Names that need such encoding (Quality to avoid characters in Given Names that need such encoding (Quality
Names are already defined in such a way that they never do). Names are already defined in such a way that they never do).
2.3.3. Extensibility of Given Names and Quality Names 2.3.3. Extensibility of Given Names and Quality Names
In SDF, both Quality Names and Given Names are _extension points_. In SDF, both Quality Names and Given Names are _extension points_.
This is more obvious for Quality Names: Extending SDF is mostly done This is more obvious for Quality Names. Extending SDF is mostly done
by defining additional qualities. To enable non-conflicting third by defining additional qualities. To enable non-conflicting third
party extensions to SDF, qualified names (names with an embedded party extensions to SDF, qualified names (names with an embedded
colon) can be used as Quality Names. colon) can be used as Quality Names.
A nonqualified Quality Name is composed of ASCII letters, digits, and A nonqualified Quality Name is composed of ASCII letters, digits, and
$ signs, starting with a lower case letter or a $ sign (i.e., using a $ signs, starting with a lower case letter or a $ sign (i.e., using a
pattern of "[a-z$][A-Za-z$0-9]*"). Names with $ signs are intended 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 to be used for functions separate from most other names; for
instance, in this specification $comment is used for the comment instance, $comment is used for the comment quality in this
quality (the presence or absence of a $comment quality does not specification (the presence or absence of a $comment quality does not
change the meaning of the SDF model). Names that are composed of change the meaning of the SDF model). Names that are composed of
multiple English words can use the "lowerCamelCase" convention multiple English words can use the "lowerCamelCase" convention
[CamelCase] for indicating the word boundaries; no other use is [CamelCase] for indicating the word boundaries; no other use is
intended for upper case letters in quality names. intended for upper case letters in quality names.
A qualified Quality Name is composed of a Quality Name Prefix, a : A qualified Quality Name is composed of a Quality Name Prefix, a :
(colon) character, and a nonqualified Quality Name. Quality Name (colon) character, and a nonqualified Quality Name. Quality Name
Prefixes are registered in the "Quality Name Prefixes" registry in Prefixes are registered in the "Quality Name Prefixes" registry in
the "Semantic Definition Format (SDF)" registry group the "Semantic Definition Format (SDF)" registry group
(Section 7.5.2). They are composed of lower case ASCII letters and (Section 7.5.2). They are composed of lower case ASCII letters and
digits, starting with a lower case ASCII letter (i.e., using a digits, starting with a lowercase ASCII letter (i.e., using a pattern
pattern of "[a-z][a-z0-9]*"). of "_[a-z][a-z0-9]*").
Given Names are not restricted by the formal SDF syntax. To enable Given Names are not restricted by the formal SDF syntax. To enable
non-surprising name translations in tools, combinations of ASCII non-surprising name translations in tools, combinations of ASCII
alphanumeric characters and - (ASCII hyphen/minus) are preferred, alphanumeric characters and - (ASCII hyphen/minus) are preferred,
typically employing kebab-case for names constructed out of multiple typically employing kebab-case for names constructed out of multiple
words [KebabCase]. ASCII hyphen/minus can then unambiguously be words [KebabCase]. ASCII hyphen/minus can then unambiguously be
translated to an ASCII _ underscore character and back depending on translated to an ASCII _ underscore character and back depending on
the programming environment. Some styles also allow a dot (".") in the programming environment. Some styles also allow a dot (".") in
given names. Given Names are often sufficiently self-explanatory given names. Given Names are often sufficiently self-explanatory
that they can be used in place of the label quality if that is not that they can be used in place of the label quality if that is not
skipping to change at page 19, line 7 skipping to change at line 780
extension point are label and description). extension point are label and description).
Further, to enable Given Names to have a more powerful role in Further, to enable Given Names to have a more powerful role in
building global hierarchical names, an extension is planned that building global hierarchical names, an extension is planned that
makes use of qualified names for Given Names. So, until that makes use of qualified names for Given Names. So, until that
extension is defined, Given Names with one or more embedded colons extension is defined, Given Names with one or more embedded colons
are reserved and MUST NOT be used in an SDF document. are reserved and MUST NOT be used in an SDF document.
All names in SDF are case-sensitive. All names in SDF are case-sensitive.
3. SDF structure 3. SDF Structure
SDF definitions are contained in SDF documents, together with data SDF definitions are contained in SDF documents together with data
about the SDF document itself (information block). Definitions and about the SDF document itself (information block). Definitions and
declarations from additional SDF documents can be referenced; declarations from additional SDF documents can be referenced;
together with the definitions and declarations in the referencing SDF together with the definitions and declarations in the referencing SDF
document they build the SDF model expressed by that SDF document. document, they build the SDF model expressed by that SDF document.
Each SDF document is represented as a single JSON map. This map can Each SDF document is represented as a single JSON map. This map can
be thought of as having three blocks: the information block, the be thought of as having three blocks: the information block, the
namespaces block, and the definitions block. These blocks contain namespaces block, and the definitions block. These blocks contain
zero or more JSON name/value pairs, the names of which are quality 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 names and the values of which mostly are (nested) maps (the exception
defined in SDF base is the defaultNamespace quality, the value of defined in SDF base is the defaultNamespace quality, the value of
which is a text string). An empty nested map of this kind is which is a text string). An empty nested map of this kind is
equivalent to not having the quality included at all. equivalent to not having the quality included at all.
3.1. Information block 3.1. Information Block
The information block contains generic metadata for the SDF document The information block contains generic metadata for the SDF document
itself and all included definitions. To enable tool integration, the itself and all included definitions. To enable tool integration, the
information block is optional in the grammar of SDF; most processes information block is optional in the grammar of SDF; most processes
for working with SDF documents will have policies that only SDF for working with SDF documents will have policies that only SDF
documents with an info block can be processed. It is therefore documents with an info block can be processed. It is therefore
RECOMMENDED that SDF validator tools emit a warning when no RECOMMENDED that SDF validator tools emit a warning when no
information block is found. information block is found.
The keyword (map key) that defines an information block is "info". The keyword (map key) that defines an information block is "info".
Its value is a JSON map in turn, with a set of entries that represent Its value is a JSON map in turn, with a set of entries that represent
qualities that apply to the included definition. qualities that apply to the included definition.
Qualities of this map are shown in Table 1. None of these qualities 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 are required or have default values that are assumed if the quality
is absent. is absent.
+-------------+----------+---------------------------------+ +=============+==========+=================================+
| Quality | Type | Description | | Quality | Type | Description |
+-------------+----------+---------------------------------+ +=============+==========+=================================+
| title | string | A short summary to be displayed | | title | string | A short summary to be displayed |
| | | in search results, etc. | | | | in search results, etc. |
+-------------+----------+---------------------------------+
| description | string | Long-form text description (no | | description | string | Long-form text description (no |
| | | constraints) | | | | constraints) |
+-------------+----------+---------------------------------+
| version | string | The incremental version of the | | version | string | The incremental version of the |
| | | definition | | | | definition |
+-------------+----------+---------------------------------+
| modified | string | Time of the latest modification | | modified | string | Time of the latest modification |
+-------------+----------+---------------------------------+
| copyright | string | Link to text or embedded text | | copyright | string | Link to text or embedded text |
| | | containing a copyright notice | | | | containing a copyright notice |
+-------------+----------+---------------------------------+
| license | string | Link to text or embedded text | | license | string | Link to text or embedded text |
| | | containing license terms | | | | containing license terms |
+-------------+----------+---------------------------------+
| features | array of | List of extension features used | | features | array of | List of extension features used |
| | strings | | | | strings | |
+-------------+----------+---------------------------------+
| $comment | string | Source code comments only, no | | $comment | string | Source code comments only, no |
| | | semantics | | | | semantics |
+-------------+----------+---------------------------------+ +-------------+----------+---------------------------------+
Table 1: Qualities of the Information Block Table 1: Qualities of the Information Block
The version quality is used to indicate version information about the The version quality is used to indicate version information about the
set of definitions in the SDF document. The version is RECOMMENDED set of definitions in the SDF document. The version is RECOMMENDED
to be lexicographically increasing over the life of a model: a newer to be lexicographically increasing over the life of a model; a newer
model always has a version string that string-compares higher than model always has a version string that string-compares higher than
all previous versions. This is easily achieved by following the all previous versions. This is easily achieved by following the
convention to start the version with an [RFC3339] date-time or, if convention to start the version with a date-time as defined in
new versions are generated less frequently than once a day, just the [RFC3339] or, if new versions are generated less frequently than once
full-date (i.e., YYYY-MM-DD); in many cases, that will be all that is a day, just the full-date (i.e., YYYY-MM-DD); in many cases, that
needed (see Figure 1 for an example). This specification does not will be all that is needed (see Figure 1 for an example). This
give a strict definition for the format of the version string but specification does not give a strict definition for the format of the
each using system or organization should define internal structure version string but each using system or organization should define
and semantics to the level needed for their use. If no further internal structure and semantics to the level needed for their use.
details are provided, a date-time or full-date in this field can be If no further details are provided, a date-time or full-date in this
assumed to indicate the latest update time of the definitions in the field can be assumed to indicate the latest update time of the
SDF document. definitions in the SDF document.
The modified quality can be used with a value using [RFC3339] date- The modified quality can be used with a value using date-time as
time (with Z for time-zone) or full-date format to express time of defined in [RFC3339] (with Z for time-zone) or full-date format to
the latest revision of the definitions. express time of the latest revision of the definitions.
The license string is preferably either a URI that points to a web The license string is preferably either a URI that points to a web
page with an unambiguous definition of the license, or an [SPDX] page with an unambiguous definition of the license or an [SPDX]
license identifier. (As an example, for models to be handled by the license identifier. (As an example, for models to be handled by the
One Data Model liaison group, this license identifier will typically One Data Model liaison group, this license identifier will typically
be "BSD-3-Clause".) be "BSD-3-Clause".)
The features quality can be used to list names of critical (i.e., The features quality can be used to list names of critical (i.e.,
cannot be safely ignored) SDF extension features that need to be cannot be safely ignored) SDF extension features that need to be
understood for the definitions to be properly processed. Extension understood for the definitions to be properly processed. Extension
feature names will be specified in extension documents. They can feature names will be specified in extension documents. They can
either be registered (see Section 7.5.4 for specifics, which make 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 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 URI (which always contain a colon). Note that SDF processors are not
expected to, and normally SHOULD NOT, dereference URIs used as expected to, and normally SHOULD NOT, dereference URIs used as
feature names; any representation retrievable under such a URI could feature names; any representation retrievable under such a URI could
be useful to humans, though. (See [I-D.bormann-t2trg-deref-id] for a be useful to humans, though. (See [DEREF-ID-PATTERN] for a more
more extensive discussion of dereferenceable identifiers). extensive discussion of dereferenceable identifiers).
3.2. Namespaces block 3.2. Namespaces Block
The namespaces block contains the namespace map and the The namespaces block contains the namespace map and the
defaultNamespace setting; none of these qualities are required or defaultNamespace setting; none of these qualities are required or
have default values that are assumed if the quality is absent. have default values that are assumed if the quality is absent.
The namespace map is a map from short names for URIs to the namespace The namespace map is a map from short names for URIs to the namespace
URIs themselves. URIs themselves.
The defaultNamespace setting selects one of the entries in the The defaultNamespace setting selects one of the entries in the
namespace map by giving its short name. The associated URI (value of namespace map by giving its short name. The associated URI (value of
this entry) becomes the default namespace for the SDF document. this entry) becomes the default namespace for the SDF document.
+------------------+--------+-----------------------------------+ +==================+========+===================================+
| Quality | Type | Description | | Quality | Type | Description |
+------------------+--------+-----------------------------------+ +==================+========+===================================+
| namespace | map | Defines short names mapped to | | namespace | map | Defines short names mapped to |
| | | namespace URIs, to be used as | | | | namespace URIs, to be used as |
| | | identifier prefixes | | | | identifier prefixes |
+------------------+--------+-----------------------------------+
| defaultNamespace | string | Identifies one of the prefixes in | | defaultNamespace | string | Identifies one of the prefixes in |
| | | the namespace map to be used as a | | | | the namespace map to be used as a |
| | | default in resolving identifiers | | | | default in resolving identifiers |
+------------------+--------+-----------------------------------+ +------------------+--------+-----------------------------------+
Table 2: Namespaces Block Table 2: Namespaces Block
The following example declares a set of namespaces and defines cap as The following example declares a set of namespaces and defines cap as
the default namespace. By convention, the values in the namespace the default namespace. By convention, the values in the namespace
map contain full URIs without a fragment identifier, and the fragment map contain full URIs without a fragment identifier and the fragment
identifier is then added, if needed, where the namespace entry is identifier is then added, if needed, where the namespace entry is
used. used.
"namespace": { "namespace": {
"cap": "https://example.com/capability/cap", "cap": "https://example.com/capability/cap",
"zcl": "https://zcl.example.com/sdf" "zcl": "https://zcl.example.com/sdf"
}, },
"defaultNamespace": "cap" "defaultNamespace": "cap"
Multiple SDF documents can contribute to the same namespace by using Multiple SDF documents can contribute to the same namespace by using
skipping to change at page 22, line 23 skipping to change at line 933
documents. documents.
If no defaultNamespace setting is given, the SDF document does not If no defaultNamespace setting is given, the SDF document does not
contribute to a global namespace (all definitions remain local to the contribute to a global namespace (all definitions remain local to the
model and are not accessible for re-use by other models). As the model and are not accessible for re-use by other models). As the
defaultNamespace is set by supplying a namespace short name, its defaultNamespace is set by supplying a namespace short name, its
presence requires a namespace map that contains a mapping for that presence requires a namespace map that contains a mapping for that
namespace short name. namespace short name.
If no namespace map is given, no short names for namespace URIs are If no namespace map is given, no short names for namespace URIs are
set up, and no defaultNamespace can be given. set up and no defaultNamespace can be given.
3.3. Definitions block 3.3. Definitions Block
The Definitions block contains one or more groups, each identified by The Definitions block contains one or more groups, each identified by
a Class Name Keyword such as sdfObject or sdfProperty. There can a Class Name Keyword such as sdfObject or sdfProperty. There can
only be one group per keyword at this level; putting all the only be one group per keyword at this level; putting all the
individual definitions in the group under that keyword is just a individual definitions in the group under that keyword is just a
shortcut for identifying the class name keyword that applies to each shortcut for identifying the class name keyword that applies to each
of them, without repeating it for each definition. of them without repeating it for each definition.
The value of each group is a JSON map, the keys of which serve for The value of each group is a JSON map, the keys of which serve for
naming the individual definitions in this group, and the naming the individual definitions in this group, and the
corresponding values provide a set of qualities (name-value pairs) corresponding values provide a set of qualities (name-value pairs)
for the individual definition. (In short, these map entries are also for the individual definition. (In short, these map entries are also
termed "named sets of qualities".) termed "named sets of qualities".)
Each group may contain zero or more definitions. Each identifier Each group may contain zero or more definitions. Each identifier
defined creates a new type and term in the target namespace. defined creates a new type and term in the target namespace.
Declarations have a scope of the definition block they are directly Declarations have a scope of the definition block they are directly
contained in. contained in.
A definition may in turn contain other definitions. Each definition In turn, a definition may contain other definitions. Each definition
is a named set of qualities, i.e., it consists of the newly defined 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 identifier and a set of key-value pairs that represent the defined
qualities and contained definitions. qualities and contained definitions.
An example for an sdfObject definition is given in Figure 3: An example for an sdfObject definition is given in Figure 3:
"sdfObject": { "sdfObject": {
"foo": { "foo": {
"sdfProperty": { "sdfProperty": {
"bar": { "bar": {
"type": "boolean" "type": "boolean"
} }
} }
} }
} }
Figure 3: Example sdfObject definition Figure 3: Example sdfObject Definition
This example defines an sdfObject "foo" that is defined in the This example defines an sdfObject "foo" that is defined in the
default namespace (full address: #/sdfObject/foo), containing a default namespace (full address: #/sdfObject/foo), containing a
property that can be addressed as #/sdfObject/foo/sdfProperty/bar, property that can be addressed as #/sdfObject/foo/sdfProperty/bar,
with data of type boolean. with data of type boolean.
Often, definitions are also declarations: the definition of the entry Often, definitions are also declarations. The definition of the
"bar" in the property "foo" means that data corresponding to the entry "bar" in the property "foo" means that data corresponding to
"foo" property in a property interaction offered by Thing can have the "foo" property in a property interaction offered by Thing can
zero or one components modeled by "bar". Entries within sdfProperty, have zero or one components modeled by "bar". Entries within
sdfAction, and sdfEvent that are in turn within sdfObject or sdfThing sdfProperty, sdfAction, and sdfEvent that are in turn within
entries, are also declarations; entries within sdfData are not. sdfObject or sdfThing entries, are also declarations; entries within
Similarly, sdfObject or sdfThing entries within an sdfThing sdfData are not. Similarly, sdfObject or sdfThing entries within an
definition specify that the interactions offered by a Thing modeled sdfThing definition specify that the interactions offered by a Thing
by this sdfThing include the interactions modeled by the nested modeled by this sdfThing include the interactions modeled by the
sdfObject or sdfThing. nested sdfObject or sdfThing.
3.4. Top-level Affordances and sdfData 3.4. Top-Level Affordances and sdfData
Besides their placement within an sdfObject or sdfThing, affordances Besides their placement within an sdfObject or sdfThing, affordances
(i.e., sdfProperty, sdfAction, and sdfEvent) as well as sdfData can (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 also be placed at the top level of an SDF document. Since they are
not associated with an sdfObject or sdfThing, these kinds of not associated with an sdfObject or sdfThing, these kinds of
definitions are intended to be re-used via the sdfRef mechanism (see definitions are intended to be reused via the sdfRef mechanism (see
Section 4.4). Section 4.4).
4. Names and namespaces 4. Names and Namespaces
SDF documents may contribute to a global namespace, and may reference SDF documents may contribute to a global namespace and may reference
elements from that global namespace. (An SDF document that does not elements from that global namespace. (An SDF document that does not
set a defaultNamespace does not contribute to a global namespace.) set a defaultNamespace does not contribute to a global namespace.)
4.1. Structure 4.1. Structure
Global names look exactly like https:// URIs with attached fragment Global names look exactly like https:// URIs with attached fragment
identifiers. identifiers.
There is no intention to require that these URIs can be dereferenced. There is no intention to require that these URIs can be dereferenced.
(However, as future extensions of SDF might find a use for (However, as future extensions of SDF might find a use for
dereferencing global names, the URI should be chosen in such a way dereferencing global names, the URI should be chosen in such a way
that this may become possible in the future. See also that this may become possible in the future. See also
[I-D.bormann-t2trg-deref-id] for a discussion of dereferenceable [DEREF-ID-PATTERN] for a discussion of dereferenceable identifiers.)
identifiers.)
The absolute-URI of a global name should be a URI as per Section 3 of 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 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 [STD66]). For base SDF, the query part should not be used (it might
be used in extensions). be used in extensions).
The fragment identifier is constructed as per Section 6 of [RFC6901]. The fragment identifier is constructed as per Section 6 of [RFC6901].
4.2. Contributing global names 4.2. Contributing Global Names
The fragment identifier part of a global name defined in an SDF The fragment identifier part of a global name defined in an SDF
document is constructed from a JSON pointer that selects the element document is constructed from a JSON pointer that selects the element
defined for this name in the SDF document. The absolute-URI part is defined for this name in the SDF document. The absolute-URI part is
a copy of the default namespace. a copy of the default namespace.
As a result, the default namespace is always the target namespace for As a result, the default namespace is always the target namespace for
a name for which a definition is contributed. In order to emphasize a name for which a definition is contributed. In order to emphasize
that name definitions are contributed to the default namespace, this that name definitions are contributed to the default namespace, this
namespace is also termed the "target namespace" of the SDF document. namespace is also termed the "target namespace" of the SDF document.
skipping to change at page 25, line 5 skipping to change at line 1051
value 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
Note the #, which separates the absolute-URI part (Section 4.3 of RFC Note the #, which separates the absolute-URI part (Section 4.3 of RFC
3986 [STD66]) from the fragment identifier part (including the #, a 3986 [STD66]) from the fragment identifier part (including the #, a
JSON Pointer as in Section 6 of [RFC6901]). JSON Pointer as in Section 6 of [RFC6901]).
4.3. Referencing global names 4.3. Referencing Global Names
A name reference takes the form of the production curie in Section 3 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 of [W3C.NOTE-curie-20101216], but limiting the IRIs involved in that
grammar to URIs as per [STD66] and the prefixes to ASCII characters grammar to URIs as per [STD66] and the prefixes to ASCII characters
[STD80]. (Note that this definition does not make use of the [STD80]. (Note that this definition does not make use of the
production safe-curie in [W3C.NOTE-curie-20101216].) production safe-curie in [W3C.NOTE-curie-20101216].)
A name that is contributed by the current SDF document can be 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 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 3986 [STD66]. As there is little point in referencing the entire SDF
skipping to change at page 25, line 30 skipping to change at line 1076
Name references that point outside the current SDF document need to Name references that point outside the current SDF document need to
contain curie prefixes. These then reference namespace declarations contain curie prefixes. These then reference namespace declarations
in the namespaces block. in the namespaces block.
For example, if a namespace prefix is defined: For example, if a namespace prefix is defined:
"namespace": { "namespace": {
"foo": "https://example.com/" "foo": "https://example.com/"
} }
Then this reference to that namespace: then this reference to that namespace:
"sdfRef": "foo:#/sdfData/temperatureData" "sdfRef": "foo:#/sdfData/temperatureData"
references the global name: references the global name:
"https://example.com/#/sdfData/temperatureData" "https://example.com/#/sdfData/temperatureData"
Note that there is no way to provide a URI scheme name in a curie, so 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 all references to outside of the document need to go through the
namespace map. namespace map.
skipping to change at page 26, line 27 skipping to change at line 1116
For example, this reference: For example, this reference:
"temperatureProperty": { "temperatureProperty": {
"sdfRef": "#/sdfData/temperatureData" "sdfRef": "#/sdfData/temperatureData"
} }
creates a new definition "temperatureProperty" that contains all of creates a new definition "temperatureProperty" that contains all of
the qualities defined in the definition at /sdfData/temperatureData. the qualities defined in the definition at /sdfData/temperatureData.
The sdfRef member need not be the only member of a map. Additional The sdfRef member need not be the only member of a map. Additional
members may be present with the intention to override parts of the members may be present with the intention of overriding parts of the
referenced map or to add new qualities or definitions. referenced map or adding new qualities or definitions.
When processing sdfRef, if the target definition contains also sdfRef When processing sdfRef, if the target definition contains also sdfRef
(i.e., is based on yet another definition), that MUST be processed as (i.e., is based on yet another definition), that MUST be processed as
well. well.
More formally, for a JSON map that contains an sdfRef member, the More formally, for a JSON map that contains an sdfRef member, the
semantics is defined to be as if the following steps were performed: semantics are defined to be as if the following steps were performed:
1. The JSON map that contains the sdfRef member is copied into a 1. The JSON map that contains the sdfRef member is copied into a
variable named "patch". variable named "patch".
2. The sdfRef member of the copy in "patch" is removed. 2. The sdfRef member of the copy in "patch" is removed.
3. the JSON pointer that is the value of the sdfRef member is 3. The JSON pointer that is the value of the sdfRef member is
dereferenced and the result is copied into a variable named dereferenced and the result is copied into a variable named
"original". "original".
4. The JSON Merge Patch algorithm [RFC7396] is applied to patch the 4. The JSON Merge Patch algorithm [RFC7396] is applied to patch the
contents of "original" with the contents of "patch". contents of "original" with the contents of "patch".
5. The result of the Merge Patch is used in place of the value of 5. The result of the Merge Patch is used in place of the value of
the original JSON map. the original JSON map.
Note that the formal syntaxes given in Appendices A and B generally Note that the formal syntaxes given in Appendices A and B generally
describe the _result_ of applying a merge-patch: the notations are describe the _result_ of applying a merge-patch. The notations are
not powerful enough to describe, for instance, how the merge-patch not powerful enough to describe, for instance, how the merge-patch
algorithm causes null values within the sdfRef to remove members of algorithm causes null values within the sdfRef to remove members of
JSON maps from the referenced target. Nonetheless, the syntaxes also JSON maps from the referenced target. Nonetheless, the syntaxes also
give the syntax of the sdfRef itself, which vanishes during the give the syntax of the sdfRef itself, which vanishes during the
resolution; in many cases therefore even merge-patch inputs will resolution; therefore, in many cases, even merge-patch inputs will
validate with these formal syntaxes. validate with these formal syntaxes.
Given the example (Figure 1), and the following definition: Given the example (Figure 1) and the following definition:
{ {
"info": { "info": {
"title": "Example light switch using sdfRef" "title": "Example light switch using sdfRef"
}, },
"namespace": { "namespace": {
"cap": "https://example.com/capability/cap" "cap": "https://example.com/capability/cap"
}, },
"defaultNamespace": "cap", "defaultNamespace": "cap",
"sdfObject": { "sdfObject": {
"BasicSwitch": { "BasicSwitch": {
"sdfRef": "cap:#/sdfObject/Switch", "sdfRef": "cap:#/sdfObject/Switch",
"sdfAction": { "sdfAction": {
"toggle": null "toggle": null
} }
} }
} }
} }
The resulting definition of the "BasicSwitch" sdfObject would be The resulting definition of the "BasicSwitch" sdfObject would be
identical to the definition of the "Switch" sdfObject except it would identical to the definition of the "Switch" sdfObject, except it
not contain the "toggle" Action. would not contain the "toggle" Action.
{ {
"info": { "info": {
"title": "Example light switch using sdfRef" "title": "Example light switch using sdfRef"
}, },
"namespace": { "namespace": {
"cap": "https://example.com/capability/cap" "cap": "https://example.com/capability/cap"
}, },
"defaultNamespace": "cap", "defaultNamespace": "cap",
"sdfObject": { "sdfObject": {
skipping to change at page 28, line 36 skipping to change at line 1205
}, },
"off": { "off": {
"description": "description":
"Turn the switch off; equivalent to setting value to false." "Turn the switch off; equivalent to setting value to false."
} }
} }
} }
} }
} }
4.4.1. Resolved models 4.4.1. Resolved Models
A model where all sdfRef references are processed as described in A model where all sdfRef references are processed as described in
Section 4.4 is called a resolved model. Section 4.4 is called a resolved model.
For example, given the following sdfData definitions: For example, given the following sdfData definitions:
"sdfData": { "sdfData": {
"Coordinate" : { "Coordinate" : {
"type": "number", "unit": "m" "type": "number", "unit": "m"
}, },
skipping to change at page 29, line 20 skipping to change at line 1227
"sdfRef" : "#/sdfData/Coordinate", "sdfRef" : "#/sdfData/Coordinate",
"description": "description":
"Distance from the base of the Thing along the X axis." "Distance from the base of the Thing along the X axis."
}, },
"Non-neg-X-Coordinate" : { "Non-neg-X-Coordinate" : {
"sdfRef": "#/sdfData/X-Coordinate", "sdfRef": "#/sdfData/X-Coordinate",
"minimum": 0 "minimum": 0
} }
} }
After resolving the definitions would look as follows: the definitions would look as follows after being resolved:
"sdfData": { "sdfData": {
"Coordinate" : { "Coordinate" : {
"type": "number", "unit": "m" "type": "number", "unit": "m"
}, },
"X-Coordinate" : { "X-Coordinate" : {
"description": "description":
"Distance from the base of the Thing along the X axis.", "Distance from the base of the Thing along the X axis.",
"type": "number", "unit": "m" "type": "number", "unit": "m"
}, },
skipping to change at page 29, line 48 skipping to change at line 1255
4.5. sdfRequired 4.5. sdfRequired
The keyword sdfRequired is provided to apply a constraint that The keyword sdfRequired is provided to apply a constraint that
defines for which declarations the corresponding data are mandatory defines for which declarations the corresponding data are mandatory
in a grouping (sdfThing or sdfObject) modeled by the current in a grouping (sdfThing or sdfObject) modeled by the current
definition. definition.
The value of sdfRequired is an array of references, each indicating The value of sdfRequired is an array of references, each indicating
one or more declarations that are mandatory to be represented. one or more declarations that are mandatory to be represented.
References in this array can be SDF names (JSON Pointers), or one of References in this array can be SDF names (JSON Pointers) or one of
two abbreviated reference formats: two abbreviated reference formats:
* a text string with a "referenceable-name", namely an affordance * A text string with a "referenceable-name", namely an affordance
name or a grouping name: name or a grouping name:
- All affordance declarations that are directly in the same - All affordance declarations that are directly in the same
grouping (i.e., not nested further in another grouping) and grouping (i.e., not nested further in another grouping) and
that carry this name are declared to be mandatory to be that carry this name are declared to be mandatory to be
represented. Note that there can be multiple such affordance represented. Note that there can be multiple such affordance
declarations, one per affordance type. declarations, one per affordance type.
- The same applies to groupings made mandatory within groupings - The same applies to groupings made mandatory within groupings
containing them. containing them.
* the Boolean value true. The affordance or grouping itself that * The Boolean value true. The affordance or grouping itself that
carries the sdfRequired keyword is declared to be mandatory to be carries the sdfRequired keyword is declared to be mandatory to be
represented. represented.
Note that referenceable-names are not subject to the encoding JSON Note that referenceable-names are not subject to the encoding JSON
pointers require as discussed in Section 2.3.2. To ensure that pointers require as discussed in Section 2.3.2. To ensure that
referenceable-names are reliably distinguished from JSON pointers, referenceable-names are reliably distinguished from JSON pointers,
they are defined such that they cannot contain ":" or "#" characters they are defined such that they cannot contain ":" or "#" characters
(see rule referenceable-name in Appendix A). (If these characters (see rule referenceable-name in Appendix A). (If these characters
are indeed contained in a Given Name, a JSON pointer needs to be are indeed contained in a Given Name, a JSON pointer needs to be
formed instead in order to reference it in "sdfRequired", potentially formed instead in order to reference it in "sdfRequired", potentially
skipping to change at page 31, line 39 skipping to change at line 1327
} }
} }
Figure 4: Using sdfRequired Figure 4: Using sdfRequired
In Figure 4, the same sdfRequired can also be represented in short In Figure 4, the same sdfRequired can also be represented in short
form: form:
"sdfRequired": ["currentTemperature", "overTemperatureEvent"] "sdfRequired": ["currentTemperature", "overTemperatureEvent"]
Or, for instance "overTemperatureEvent" could carry Or, for instance, "overTemperatureEvent" could carry:
"overTemperatureEvent": { "overTemperatureEvent": {
"sdfRequired": [true], "sdfRequired": [true],
"...": "..." "...": "..."
} }
4.6. Common Qualities 4.6. Common Qualities
Definitions in SDF share a number of qualities that provide metadata Definitions in SDF share a number of qualities that provide metadata
for them. These are listed in Table 3. None of these qualities are 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 required or have default values that are assumed if the quality is
absent. If a short textual description is required for an absent. If a short textual description is required for an
application and no label is given in the SDF model, in its place application and no label is given in the SDF model, applications
applications could use the last part (the last reference-token, could use the last part (the last reference-token, Section 3 of
Section 3 of [RFC6901]) of the JSON pointer to the definition. [RFC6901]) of the JSON pointer to the definition in its place.
+-------------+--------------+-----------------------------+ +=============+==============+=============================+
| Quality | Type | Description | | Quality | Type | Description |
+-------------+--------------+-----------------------------+ +=============+==============+=============================+
| description | string | long text (no constraints) | | description | string | long text (no constraints) |
+-------------+--------------+-----------------------------+
| label | string | short text (no constraints) | | label | string | short text (no constraints) |
+-------------+--------------+-----------------------------+
| $comment | string | source code comments only, | | $comment | string | source code comments only, |
| | | no semantics | | | | no semantics |
+-------------+--------------+-----------------------------+
| sdfRef | sdf-pointer | (see Section 4.4) | | sdfRef | sdf-pointer | (see Section 4.4) |
+-------------+--------------+-----------------------------+
| sdfRequired | pointer-list | (see Section 4.5, used in | | sdfRequired | pointer-list | (see Section 4.5, used in |
| | | affordances or groupings) | | | | affordances or groupings) |
+-------------+--------------+-----------------------------+ +-------------+--------------+-----------------------------+
Table 3: Common Qualities Table 3: Common Qualities
4.7. Data Qualities 4.7. Data Qualities
Data qualities are used in sdfData and sdfProperty definitions, which Data qualities are used in sdfData and sdfProperty definitions, which
are named sets of data qualities (abbreviated as named-sdq). are named sets of data qualities (abbreviated as named-sdq).
These qualities include the common qualities, JSO-inspired qualities These qualities include the common qualities, JSO-inspired qualities
(see below), and data qualities defined specifically for the present (see below), and data qualities defined specifically for the present
specification; the latter are shown in Table 4. None of these specification; the latter are shown in Table 4. None of these
qualities are required or have default values that are assumed if the qualities are required or have default values that are assumed if the
quality is absent. quality is absent.
Appendix C lists data qualities inspired by the various proposals at Appendix C lists data qualities inspired by the various proposals at
json-schema.org; the intention is that these (information model json-schema.org; the intention is that these (information model-
level) qualities are compatible with the (data model) semantics from level) qualities are compatible with the (data model) semantics from
the versions of the json-schema.org proposal they were imported from. the versions of the json-schema.org proposal they were imported from.
+---------------+----------------+--------------------+---------+ +===============+================+====================+=========+
| Quality | Type | Description | Default | | Quality | Type | Description | Default |
+---------------+----------------+--------------------+---------+ +===============+================+====================+=========+
| (common) | | Section 4.6 | | | (common) | | Section 4.6 | |
+---------------+----------------+--------------------+---------+
| unit | string | unit name (note 1) | N/A | | unit | string | unit name (note 1) | N/A |
+---------------+----------------+--------------------+---------+
| nullable | boolean | indicates a null | true | | nullable | boolean | indicates a null | true |
| | | value is available | | | | | value is available | |
| | | for this type | | | | | for this type | |
+---------------+----------------+--------------------+---------+
| contentFormat | string | content type (IANA | N/A | | contentFormat | string | content type (IANA | N/A |
| | | media type string | | | | | media type string | |
| | | plus parameters), | | | | | plus parameters), | |
| | | encoding (note 2) | | | | | encoding (note 2) | |
+---------------+----------------+--------------------+---------+
| sdfType | string | sdfType | N/A | | sdfType | string | sdfType | N/A |
| | (Section | enumeration | | | | (Section | enumeration | |
| | 4.7.1) | (extensible) | | | | 4.7.1) | (extensible) | |
+---------------+----------------+--------------------+---------+
| sdfChoice | named set of | named alternatives | N/A | | sdfChoice | named set of | named alternatives | N/A |
| | data qualities | | | | | data qualities | | |
| | (Section | | | | | (Section | | |
| | 4.7.2) | | | | | 4.7.2) | | |
+---------------+----------------+--------------------+---------+
| enum | array of | abbreviation for | N/A | | enum | array of | abbreviation for | N/A |
| | strings | string-valued | | | | strings | string-valued | |
| | | named alternatives | | | | | named alternatives | |
+---------------+----------------+--------------------+---------+ +---------------+----------------+--------------------+---------+
Table 4: SDF-defined Qualities of sdfData and sdfProperty Table 4: SDF-Defined Qualities of sdfData and sdfProperty
1. The unit name SHOULD be as per the SenML Units registry or the 1. The unit name SHOULD be as per the SenML Units registry or the
Secondary Units registry in [IANA.senml] as specified by Sections Secondary Units registry in [IANA.senml] as specified by Sections
4.5.1 and 12.1 of [RFC8428] and Section 3 of [RFC8798], 4.5.2 and 12.1 of [RFC8428] and Section 3 of [RFC8798],
respectively. respectively.
Exceptionally, if a registration in these registries cannot be Exceptionally, if a registration in these registries cannot be
obtained or would be inappropriate, the unit name can also be a 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 URI that is pointing to a definition of the unit. Note that SDF
processors are not expected to, and normally SHOULD NOT, processors are not expected to, and normally SHOULD NOT,
dereference these URIs; the definition pointed to may be useful dereference these URIs; the definition pointed to may be useful
to humans, though. (See [I-D.bormann-t2trg-deref-id] for a more to humans, though. (See [DEREF-ID-PATTERN] for a more extensive
extensive discussion of dereferenceable identifiers). discussion of dereferenceable identifiers).
A URI unit name is distinguished from a registered unit name by A URI unit name is distinguished from a registered unit name by
the presence of a colon; any registered unit names that contain a the presence of a colon; therefore, any registered unit names
colon (at the time of writing, none) can therefore not be that contain a colon (at the time of writing, none) cannot be
directly used in SDF. directly used in SDF.
For use by translators into ecosystems that require URIs for unit For use by translators into ecosystems that require URIs for unit
names, the URN sub-namespace "urn:ietf:params:unit" is provided names, the URN sub-namespace "urn:ietf:params:unit" is provided
(Section 7.3). URNs from this sub-namespace MUST NOT be used in (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 a unit quality in favor of simply notating the unit name (such as
as kg instead of urn:ietf:params:unit:kg), except where the unit kg instead of urn:ietf:params:unit:kg) except where the unit name
name contains a colon and can therefore not be directly used in contains a colon and can therefore not be directly used in SDF.
SDF.
2. The contentFormat quality follows the Content-Format-Spec as 2. The contentFormat quality follows the Content-Format-Spec as
defined in Section 6 of [RFC9193], allowing for expressing both defined in Section 6 of [RFC9193], allowing for expressing both
numeric and string based Content-Formats. numeric and string based Content-Formats.
4.7.1. sdfType 4.7.1. sdfType
SDF defines a number of basic types beyond those provided by JSON or 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 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" text string from a set of type names defined by the "sdfType values"
registry in the "Semantic Definition Format (SDF)" registry group registry in the "Semantic Definition Format (SDF)" registry group
(Section 7.5.3). The sdfType name is composed of lower case ASCII (Section 7.5.3). The sdfType name is composed of lowercase ASCII
letters, digits, and - (ASCII hyphen/minus) characters, starting with letters, digits, and - (ASCII hyphen/minus) characters, starting with
a lower case ASCII letter (i.e., using a pattern of a lowercase ASCII letter (i.e., using a pattern of "[a-z][-a-z0-9]*")
"[a-z][-a-z0-9]*"), typically employing kebab-case for names and typically employing kebab-case for names constructed out of
constructed out of multiple words [KebabCase]. multiple words [KebabCase].
To aid interworking with JSO implementations, it is RECOMMENDED that To aid interworking with JSO implementations, it is RECOMMENDED that
sdfType is always used in conjunction with the type quality inherited sdfType is always used in conjunction with the type quality inherited
from [JSO7V], in such a way as to yield a common representation of from [JSO7V] in such a way as to yield a common representation of the
the type's values in JSON. type's values in JSON.
Values for sdfType that are defined in this specification are shown Values for sdfType that are defined in this specification are shown
in Table 5. This table also gives a description of the semantics of 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 the sdfType, the conventional value for type to be used with the
sdfType value, and a conventional JSON representation for values of sdfType value, and a conventional JSON representation for values of
the type. The type and the JSON representation are chosen to be the type. The type and the JSON representation are chosen to be
consistent with each other; this MUST be true for additionally consistent with each other; this MUST be true for additionally
registered sdfType values as well. registered sdfType values as well.
+-------------+-------------+--------+----------------+------------+ +=============+=============+========+================+============+
| Name | Description | type | JSON | Reference | | Name | Description | type | JSON | Reference |
| | | | Representation | | | | | | Representation | |
+-------------+-------------+--------+----------------+------------+ +=============+=============+========+================+============+
| byte-string | A sequence | string | base64url | Section | | byte-string | A sequence | string | base64url | Section |
| | of zero or | | without | 3.4.5.2 of | | | of zero or | | without | 3.4.5.2 of |
| | more bytes | | padding | RFC 8949 | | | more bytes | | padding | RFC 8949 |
| | | | | [STD94] | | | | | | [STD94] |
+-------------+-------------+--------+----------------+------------+
| unix-time | A point in | number | POSIX time | Section | | unix-time | A point in | number | POSIX time | Section |
| | civil time | | | 3.4.2 of | | | civil time | | | 3.4.2 of |
| | (note 1) | | | RFC 8949 | | | (note 1) | | | RFC 8949 |
| | | | | [STD94] | | | | | | [STD94] |
+-------------+-------------+--------+----------------+------------+ +-------------+-------------+--------+----------------+------------+
Table 5: Values Defined in Base SDF for the sdfType Quality Table 5: Values Defined in Base SDF for the sdfType Quality
(1) Note that the definition of unix-time does not imply the (1) Note that the definition of unix-time does not imply the
capability to represent points in time that fall on leap seconds. capability to represent points in time that fall on leap seconds.
More date/time-related sdfTypes are likely to be added in the sdfType More date/time-related sdfTypes are likely to be added in the sdfType
value registry. value registry.
4.7.2. sdfChoice 4.7.2. sdfChoice
Data can be a choice of named alternatives, called sdfChoice. Each Data can be a choice of named alternatives called sdfChoice. Each
alternative is identified by a name (string, key in the outer JSON alternative is identified by a name (string, key in the outer JSON
map used to represent the overall choice) and a set of dataqualities map used to represent the overall choice) and a set of dataqualities
(each in an inner JSON map, the value used to represent the (each in an inner JSON map, the value used to represent the
individual alternative in the outer JSON map). Dataqualities that individual alternative in the outer JSON map). Dataqualities that
are specified at the same level as the sdfChoice apply to all choices are specified at the same level as the sdfChoice apply to all choices
in the sdfChoice, except those specific choices where the dataquality in the sdfChoice except those specific choices where the dataquality
is overridden at the choice level. is overridden at the choice level.
sdfChoice merges the functions of two constructs found in [JSO7V]: sdfChoice merges the functions of two constructs found in [JSO7V]:
* enum * enum
What could be expressed as What could be expressed as:
"enum": ["foo", "bar", "baz"] "enum": ["foo", "bar", "baz"]
in JSO, is often best represented as: in JSO, is often best represented as:
"sdfChoice": { "sdfChoice": {
"foo": { "description": "This is a foonly"}, "foo": { "description": "This is a foonly"},
"bar": { "description": "bar": { "description":
"As defined in the second world congress"}, "As defined in the second world congress"},
"baz": { "description": "From bigzee foobaz"} "baz": { "description": "From bigzee foobaz"}
} }
This allows the placement of other dataqualities such as This allows the placement of other dataqualities such as
description in the example. description in the example.
If an enum needs to use a data type different from text string, If an enum needs to use a data type different from the text
what would for instance have been: string, what would, for instance, have been:
"type": "number", "type": "number",
"enum": [1, 2, 3] "enum": [1, 2, 3]
in JSO, is represented as: in JSO, is represented as:
"type": "number", "type": "number",
"sdfChoice": { "sdfChoice": {
"a-better-name-for-alternative-1": { "const": 1 }, "a-better-name-for-alternative-1": { "const": 1 },
"alternative-2": { "const": 2 }, "alternative-2": { "const": 2 },
skipping to change at page 36, line 48 skipping to change at line 1568
"items": {"sdfRef": "#/sdfData/rgbVal"}}, "items": {"sdfRef": "#/sdfData/rgbVal"}},
"cmyk": {"type": "array", "minItems": 4, "maxItems": "4", "cmyk": {"type": "array", "minItems": 4, "maxItems": "4",
"items": {"sdfRef": "#/sdfData/cmykVal"}} "items": {"sdfRef": "#/sdfData/cmykVal"}}
} }
Note that there is no need in SDF for the type intersection construct Note that there is no need in SDF for the type intersection construct
allOf or the peculiar type-xor construct oneOf found in [JSO7V]. allOf or the peculiar type-xor construct oneOf found in [JSO7V].
As a simplification for users of SDF models who are accustomed to the 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 JSO enum keyword, this is retained, but limited to a choice of text
string values, such that string values, such that:
"enum": ["foo", "bar", "baz"] "enum": ["foo", "bar", "baz"]
is syntactic sugar for is syntactic sugar for:
"sdfChoice": { "sdfChoice": {
"foo": { "const": "foo"}, "foo": { "const": "foo"},
"bar": { "const": "bar"}, "bar": { "const": "bar"},
"baz": { "const": "baz"} "baz": { "const": "baz"}
} }
In a single definition, the keyword enum cannot be used at the same 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 time as the keyword sdfChoice, as the former is just syntactic sugar
for the latter. for the latter.
5. Keywords for definition groups 5. Keywords for Definition Groups
The following SDF keywords are used to create definition groups in The following SDF keywords are used to create definition groups in
the target namespace. All these definitions share some common the target namespace. All these definitions share some common
qualities as discussed in Section 4.6. qualities as discussed in Section 4.6.
5.1. sdfObject 5.1. sdfObject
The sdfObject keyword denotes a group of zero or more sdfObject The sdfObject keyword denotes a group of zero or more sdfObject
definitions. sdfObject definitions may contain or include definitions definitions. sdfObject definitions may contain or include definitions
of named Properties, Actions, Events declared for the sdfObject, as of named Properties, Actions, and Events declared for the sdfObject,
well as named data types (sdfData group) to be used in this or other as well as named data types (sdfData group) to be used in this or
sdfObjects. other sdfObjects.
The qualities of an sdfObject include the common qualities; The qualities of an sdfObject include the common qualities;
additional qualities are shown in Table 6. None of these qualities additional qualities are shown in Table 6. None of these qualities
are required or have default values that are assumed if the quality are required or have default values that are assumed if the quality
is absent. is absent.
+-------------+-----------+--------------------------------+ +=============+===========+================================+
| Quality | Type | Description | | Quality | Type | Description |
+-------------+-----------+--------------------------------+ +=============+===========+================================+
| (common) | | Section 4.6 | | (common) | | Section 4.6 |
+-------------+-----------+--------------------------------+
| sdfProperty | property | zero or more named property | | sdfProperty | property | zero or more named property |
| | | definitions for this sdfObject | | | | definitions for this sdfObject |
+-------------+-----------+--------------------------------+
| sdfAction | action | zero or more named action | | sdfAction | action | zero or more named action |
| | | definitions for this sdfObject | | | | definitions for this sdfObject |
+-------------+-----------+--------------------------------+
| sdfEvent | event | zero or more named event | | sdfEvent | event | zero or more named event |
| | | definitions for this sdfObject | | | | definitions for this sdfObject |
+-------------+-----------+--------------------------------+
| sdfData | named-sdq | zero or more named data type | | sdfData | named-sdq | zero or more named data type |
| | | definitions that might be used | | | | definitions that might be used |
| | | in the above | | | | in the above |
| minItems | number | (array) Minimum number of | +-------------+-----------+--------------------------------+
| minItems | number | (array) minimum number of |
| | | multiplied affordances in | | | | multiplied affordances in |
| | | array | | | | array |
| maxItems | number | (array) Maximum number of | +-------------+-----------+--------------------------------+
| maxItems | number | (array) maximum number of |
| | | multiplied affordances in | | | | multiplied affordances in |
| | | array | | | | array |
+-------------+-----------+--------------------------------+ +-------------+-----------+--------------------------------+
Table 6: Qualities of sdfObject Table 6: Qualities of sdfObject
5.2. sdfProperty 5.2. sdfProperty
The sdfProperty keyword denotes a group of zero or more Property The sdfProperty keyword denotes a group of zero or more Property
definitions. definitions.
Properties are used to model elements of state. Properties are used to model elements of state.
The qualities of a Property definition include the data qualities The qualities of a Property definition include the data qualities
(and thus the common qualities), see Section 4.7, additional (and thus the common qualities); see Section 4.7. Additional
qualities are shown in Table 7. qualities are shown in Table 7.
+------------+---------+-------------------------------+---------+ +============+=========+===============================+=========+
| Quality | Type | Description | Default | | Quality | Type | Description | Default |
+------------+---------+-------------------------------+---------+ +============+=========+===============================+=========+
| (data) | | Section 4.7 | | | (data) | | Section 4.7 | |
+------------+---------+-------------------------------+---------+
| readable | boolean | Reads are allowed | true | | readable | boolean | Reads are allowed | true |
+------------+---------+-------------------------------+---------+
| writable | boolean | Writes are allowed | true | | writable | boolean | Writes are allowed | true |
| observable | boolean | flag to indicate asynchronous | true | +------------+---------+-------------------------------+---------+
| observable | boolean | Flag to indicate asynchronous | true |
| | | notification is available | | | | | notification is available | |
+------------+---------+-------------------------------+---------+ +------------+---------+-------------------------------+---------+
Table 7: Qualities of sdfProperty Table 7: Qualities of sdfProperty
5.3. sdfAction 5.3. sdfAction
The sdfAction keyword denotes a group of zero or more Action The sdfAction keyword denotes a group of zero or more Action
definitions. definitions.
Actions are used to model commands and methods which are invoked. Actions are used to model commands and methods that are invoked.
Actions may have parameter data that are supplied upon invocation and Actions may have parameter data that is supplied upon invocation and
output data that is provided as a direct result of the invocation of 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 the action (note that "action objects" may also be created to furnish
ongoing information during a long-running action; these would be ongoing information during a long-running action; these would be
pointed to by the output data). pointed to by the output data).
The qualities of an Action definition include the common qualities, The qualities of an Action definition include the common qualities.
additional qualities are shown in Table 8. Additional qualities are shown in Table 8.
+---------------+-----------+----------------------------+ +===============+===========+============================+
| Quality | Type | Description | | Quality | Type | Description |
+---------------+-----------+----------------------------+ +===============+===========+============================+
| (common) | | Section 4.6 | | (common) | | Section 4.6 |
+---------------+-----------+----------------------------+
| sdfInputData | map | data qualities of the | | sdfInputData | map | data qualities of the |
| | | input data for an Action | | | | input data for an Action |
+---------------+-----------+----------------------------+
| sdfOutputData | map | data qualities of the | | sdfOutputData | map | data qualities of the |
| | | output data for an Action | | | | output data for an Action |
+---------------+-----------+----------------------------+
| sdfData | named-sdq | zero or more named data | | sdfData | named-sdq | zero or more named data |
| | | type definitions that | | | | type definitions that |
| | | might be used in the above | | | | might be used in the above |
+---------------+-----------+----------------------------+ +---------------+-----------+----------------------------+
Table 8: Qualities of sdfAction Table 8: Qualities of sdfAction
sdfInputData defines the input data of the action. sdfOutputData sdfInputData defines the input data of the action. sdfOutputData
defines the output data of the action. As discussed in 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 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 to substructure either data item, with optionality indicated by the
data quality required. data quality required.
5.4. sdfEvent 5.4. sdfEvent
The sdfEvent keyword denotes zero or more Event definitions. The sdfEvent keyword denotes zero or more Event definitions.
Events are used to model asynchronous occurrences that may be Events are used to model asynchronous occurrences that may be
communicated proactively. Events have data elements which are communicated proactively. Events have data elements that are
communicated upon the occurrence of the event. communicated upon the occurrence of the event.
The qualities of sdfEvent include the common qualities, additional The qualities of sdfEvent include the common qualities. Additional
qualities are shown in Table 9. qualities are shown in Table 9.
+---------------+-----------+----------------------------+ +===============+===========+============================+
| Quality | Type | Description | | Quality | Type | Description |
+---------------+-----------+----------------------------+ +===============+===========+============================+
| (common) | | Section 4.6 | | (common) | | Section 4.6 |
+---------------+-----------+----------------------------+
| sdfOutputData | map | data qualities of the | | sdfOutputData | map | data qualities of the |
| | | output data for an Event | | | | output data for an Event |
+---------------+-----------+----------------------------+
| sdfData | named-sdq | zero or more named data | | sdfData | named-sdq | zero or more named data |
| | | type definitions that | | | | type definitions that |
| | | might be used in the above | | | | might be used in the above |
+---------------+-----------+----------------------------+ +---------------+-----------+----------------------------+
Table 9: Qualities of sdfEvent Table 9: Qualities of sdfEvent
sdfOutputData defines the output data of the action. As discussed in 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 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 to substructure the output data item, with optionality indicated by
skipping to change at page 40, line 34 skipping to change at line 1739
The sdfData keyword denotes a group of zero or more named data type The sdfData keyword denotes a group of zero or more named data type
definitions (named-sdq). definitions (named-sdq).
An sdfData definition provides a reusable semantic identifier for a An sdfData definition provides a reusable semantic identifier for a
type of data item and describes the constraints on the defined type. 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 sdfData is not itself a declaration, so it does not cause any of
these data items to be included in an affordance definition. these data items to be included in an affordance definition.
The qualities of sdfData include the data qualities (and thus the The qualities of sdfData include the data qualities (and thus the
common qualities), see Section 4.7. common qualities); see Section 4.7.
6. High Level Composition 6. High-Level Composition
The requirements for high level composition include the following: The requirements for high-level composition include the following:
* The ability to represent products, standardized product types, and * The ability to represent products, standardized product types, and
modular products while maintaining the atomicity of sdfObjects. modular products while maintaining the atomicity of sdfObjects.
* The ability to compose a reusable definition block from * The ability to compose a reusable definition block from
sdfObjects. Example: a single plug unit of an outlet strip with sdfObjects. Example: a single plug unit of an outlet strip with
sdfObjects for on/off control, energy monitor, and optional sdfObjects for on/off control, energy monitor, and optional
dimmer, while retaining the atomicity of the individual dimmer, while retaining the atomicity of the individual
sdfObjects. sdfObjects.
skipping to change at page 41, line 13 skipping to change at line 1766
the atomicity of sdfObjects. the atomicity of sdfObjects.
* The ability to enrich and refine a base definition to have * The ability to enrich and refine a base definition to have
product-specific qualities and quality values, such as unit, product-specific qualities and quality values, such as unit,
range, and scale settings. range, and scale settings.
* The ability to reference items in one part of a complex definition * The ability to reference items in one part of a complex definition
from another part of the same definition. Example: summarizing from another part of the same definition. Example: summarizing
the energy readings from all plugs in an outlet strip. the energy readings from all plugs in an outlet strip.
6.1. Paths in the model namespaces 6.1. Paths in the Model Namespaces
The model namespace is organized according to terms that are defined The model namespace is organized according to terms that are defined
in the SDF documents that contribute to the namespace. For example, in the SDF documents that contribute to the namespace. For example,
definitions that originate from an organization or vendor are definitions that originate from an organization or vendor are
expected to be in a namespace that is specific to that organization expected to be in a namespace that is specific to that organization
or vendor. or vendor.
The structure of a path in a namespace is defined by the JSON The structure of a path in a namespace is defined by the JSON
Pointers to the definitions in the SDF documents in that namespace. Pointers to the definitions in the SDF documents in that namespace.
For example, if there is an SDF document defining an sdfObject For example, if there is an SDF document defining an sdfObject
"Switch" with an action "on", then the reference to the action would "Switch" with an action "on", then the reference to the action would
be "ns:#/sdfObject/Switch/sdfAction/on" where ns is the namespace be "ns:#/sdfObject/Switch/sdfAction/on", where ns is the namespace
prefix (short name for the namespace). prefix (short name for the namespace).
6.2. Modular Composition 6.2. Modular Composition
Modular composition of definitions enables an existing definition Modular composition of definitions enables an existing definition
(could be in the same or another SDF document) to become part of a (which could be in the same or another SDF document) to become part
new definition by including a reference to the existing definition of a new definition by including a reference to the existing
within the model namespace. definition within the model namespace.
6.2.1. Use of the "sdfRef" keyword to re-use a definition 6.2.1. Use of the "sdfRef" Keyword to Reuse a Definition
An existing definition may be used as a template for a new An existing definition may be used as a template for a new
definition, that is, a new definition is created in the target definition, that is, a new definition is created in the target
namespace which uses the defined qualities of some existing namespace which uses the defined qualities of some existing
definition. This pattern uses the keyword sdfRef as a quality of a definition. This pattern uses the keyword sdfRef as a quality of a
new definition with a value consisting of a reference to the existing new definition with a value consisting of a reference to the existing
definition that is to be used as a template. definition that is to be used as a template.
In the definition that uses sdfRef, new qualities may be added and In the definition that uses sdfRef, new qualities may be added and
existing qualities from the referenced definition may be overridden. existing qualities from the referenced definition may be overridden.
skipping to change at page 42, line 4 skipping to change at line 1801
definition, that is, a new definition is created in the target definition, that is, a new definition is created in the target
namespace which uses the defined qualities of some existing namespace which uses the defined qualities of some existing
definition. This pattern uses the keyword sdfRef as a quality of a definition. This pattern uses the keyword sdfRef as a quality of a
new definition with a value consisting of a reference to the existing new definition with a value consisting of a reference to the existing
definition that is to be used as a template. definition that is to be used as a template.
In the definition that uses sdfRef, new qualities may be added and In the definition that uses sdfRef, new qualities may be added and
existing qualities from the referenced definition may be overridden. existing qualities from the referenced definition may be overridden.
(Note that JSON maps do not have a defined order, so the SDF (Note that JSON maps do not have a defined order, so the SDF
processor may see these overrides before seeing the sdfRef.) processor may see these overrides before seeing the sdfRef.)
Note that the definition referenced by sdfRef might contain qualities Note that the definition referenced by sdfRef might contain qualities
or definitions that are not valid in the context where the sdfRef is or definitions that are not valid in the context where the sdfRef is
used. In this case, the resulting model, when resolved, may be used. In this case, the resulting model, when resolved, may be
invalid. Example: an sdfRef adds an sdfThing definition in an invalid. Example: an sdfRef adds an sdfThing definition in an
sdfObject definition. sdfObject definition.
As a convention, overrides are intended to be used only for further As a convention, overrides are intended to be used only for further
restricting the allowable set of data values. Such a usage is shown restricting the allowable set of data values. Such a usage is shown
in Figure 5: any value allowable for a cable-length also is an in Figure 5: any value allowable for a cable-length is also an
allowable value for a length, with the additional restriction that allowable value for a length, with the additional restriction that
the length cannot be smaller than 5 cm. (This is labeled as a 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 convention as it cannot be checked in the general case. A quality of
implementation consideration for a tool might be to provide at least implementation consideration for a tool might be to provide at least
some form of checking.) Note that the example provides a description some form of checking.) Note that the example provides a description
that overrides the description of the referenced definition; as this that overrides the description of the referenced definition; as this
quality is intended for human consumption there is no conflict with quality is intended for human consumption, there is no conflict with
the intended goal. the intended goal.
"sdfData": "sdfData":
"length" : { "length" : {
"type": "number", "type": "number",
"minimum": 0, "minimum": 0,
"unit": "m" "unit": "m"
"description": "There can be no negative lengths." "description": "There can be no negative lengths."
} }
... ...
skipping to change at page 43, line 13 skipping to change at line 1859
composed of sdfObjects and other sdfThings. It can also contain composed of sdfObjects and other sdfThings. It can also contain
sdfData definitions, as well as declarations of interaction sdfData definitions, as well as declarations of interaction
affordances itself, such as a status (on/off) for the refrigerator- 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 freezer as a whole (see Figure 8 in Appendix D.2 for an example SDF
model illustrating these aspects). model illustrating these aspects).
The qualities of sdfThing are shown in Table 10. Analogous to The qualities of sdfThing are shown in Table 10. Analogous to
sdfObject, the presence of one or both of the optional qualities sdfObject, the presence of one or both of the optional qualities
"minItems" and "maxItems" defines the sdfThing as an array. "minItems" and "maxItems" defines the sdfThing as an array.
+-------------+-----------+-----------------------------+ +=============+===========+=============================+
| Quality | Type | Description | | Quality | Type | Description |
+-------------+-----------+-----------------------------+ +=============+===========+=============================+
| (common) | | Section 4.6 | | (common) | | Section 4.6 |
+-------------+-----------+-----------------------------+
| sdfThing | thing | | | sdfThing | thing | |
+-------------+-----------+-----------------------------+
| sdfObject | object | | | sdfObject | object | |
+-------------+-----------+-----------------------------+
| sdfProperty | property | zero or more named property | | sdfProperty | property | zero or more named property |
| | | definitions for this thing | | | | definitions for this thing |
+-------------+-----------+-----------------------------+
| sdfAction | action | zero or more named action | | sdfAction | action | zero or more named action |
| | | definitions for this thing | | | | definitions for this thing |
+-------------+-----------+-----------------------------+
| sdfEvent | event | zero or more named event | | sdfEvent | event | zero or more named event |
| | | definitions for this thing | | | | definitions for this thing |
+-------------+-----------+-----------------------------+
| sdfData | named-sdq | zero or more named data | | sdfData | named-sdq | zero or more named data |
| | | type definitions that might | | | | type definitions that might |
| | | be used in the above | | | | be used in the above |
| minItems | number | (array) Minimum number of | +-------------+-----------+-----------------------------+
| minItems | number | (array) minimum number of |
| | | multiplied affordances in | | | | multiplied affordances in |
| | | array | | | | array |
| maxItems | number | (array) Maximum number of | +-------------+-----------+-----------------------------+
| maxItems | number | (array) maximum number of |
| | | multiplied affordances in | | | | multiplied affordances in |
| | | array | | | | array |
+-------------+-----------+-----------------------------+ +-------------+-----------+-----------------------------+
Table 10: Qualities of sdfThing Table 10: Qualities of sdfThing
7. IANA Considerations 7. IANA Considerations
// RFC Ed.: throughout this section, please replace RFC XXXX with
// this RFC number, and remove this note.
7.1. Media Type 7.1. Media Type
IANA is requested to add the following Media-Type to the "Media IANA has added the following Media-Type to the "Media Types" registry
Types" registry [IANA.media-types]. [IANA.media-types].
+----------+----------------------+-----------------------+ +==========+======================+=======================+
| Name | Template | Reference | | Name | Template | Reference |
+----------+----------------------+-----------------------+ +==========+======================+=======================+
| sdf+json | application/sdf+json | RFC XXXX, Section 7.1 | | sdf+json | application/sdf+json | RFC 9880, Section 7.1 |
+----------+----------------------+-----------------------+ +----------+----------------------+-----------------------+
Table 11: Media Type Registration for SDF Table 11: Media Type Registration for SDF
Type name: application Type name: application
Subtype name: sdf+json Subtype name: sdf+json
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary (JSON is UTF-8-encoded text) Encoding considerations: binary (JSON is UTF-8-encoded text)
Security considerations: Section 8 of RFC XXXX
Security considerations: Section 8 of RFC 9880
Interoperability considerations: none Interoperability considerations: none
Published specification: Section 7.1 of RFC XXXX
Published specification: Section 7.1 of RFC 9880
Applications that use this media type: Tools for data and Applications that use this media type: Tools for data and
interaction modeling in the Internet of Things and related interaction modeling in the Internet of Things and related
environments environments.
Fragment identifier considerations: A JSON Pointer fragment
identifier may be used, as defined in Section 6 of [RFC6901].
Additional information: Magic number(s): n/a
File extension(s): .sdf.json
Windows Clipboard Name: "Semantic Fragment identifier considerations: A JSON Pointer fragment
Definition Format (SDF) for Data and Interactions of Things" identifier may be used as defined in Section 6 of [RFC6901].
Macintosh file type code(s): n/a Additional information:
Macintosh Universal Type Identifier code: o Magic number(s): n/a
rg.ietf.sdf-json File extension(s): .sdf.json
Windows Clipboard Name: "Semantic Definition Format (SDF) for
Data and Interactions of Things"
Macintosh file type code(s): n/a
Macintosh Universal Type Identifier code: org.ietf.sdf-json
conforms to public.text conforms to public.text
Person & email address to contact for further information: ASDF WG Person & email address to contact for further information: ASDF WG
mailing list (asdf@ietf.org), or IETF Applications and Real-Time mailing list (asdf@ietf.org) or IETF Applications and Real-Time
Area (art@ietf.org) Area (art@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: no Provisional registration: no
7.2. Content-Format 7.2. Content-Format
This document adds the following Content-Format to the "CoAP Content- IANA has added the following Content-Format to the "CoAP Content-
Formats" registry, within the "Constrained RESTful Environments Formats" registry within the "Constrained RESTful Environments (CoRE)
(CoRE) Parameters" registry group [IANA.core-parameters], where 434 Parameters" registry group [IANA.core-parameters].
comes from the "IETF Review" 256-999 range.
+----------------------+----------------+-----+-----------+ +======================+================+=====+===========+
| Content Type | Content Coding | ID | Reference | | Content Type | Content Coding | ID | Reference |
+----------------------+----------------+-----+-----------+ +======================+================+=====+===========+
| application/sdf+json | - | 434 | RFC XXXX | | application/sdf+json | - | 434 | RFC 9880 |
+----------------------+----------------+-----+-----------+ +----------------------+----------------+-----+-----------+
Table 12: SDF Content-format Registration Table 12: SDF Content-Format Registration
// RFC Ed.: 434 was earmarked in
https://mailarchive.ietf.org/arch/msg/core-parameters/
iLDsdxk80YO9IsLMXMAgcx5S8Ak/ (https://mailarchive.ietf.org/arch/msg/
core-parameters/iLDsdxk80YO9IsLMXMAgcx5S8Ak/); please replace 434
with the assigned ID, remove the requested range, and remove this
note.
// RFC Ed.: please replace RFC XXXX with this RFC number and remove
this note.
7.3. IETF URN Sub-namespace for Unit Names (urn:ietf:params:unit) 7.3. IETF URN Sub-Namespace for Unit Names (urn:ietf:params:unit)
IANA is requested to register the following value in the "IETF URN IANA has registered the following value in the "IETF URN Sub-
Sub-namespace for Registered Protocol Parameter Identifiers" registry namespace for Registered Protocol Parameter Identifiers" registry in
in [IANA.params], following the template in [BCP73]: [IANA.params], following the template in [BCP73]:
Registry name: unit Registry name: unit
Specification: RFC XXXX Specification: RFC 9880
Repository: combining the symbol values from the SenML Units Repository: Combining the symbol values from the "SenML Units"
registry and the Secondary Units registry in [IANA.senml] as registry and the "Secondary Units" registry in the "Sensor
specified by Sections 4.5.1 and 12.1 of [RFC8428] and Section 3 of Measurement Lists (SenML)" registry group [IANA.senml] as
[RFC8798], respectively (which by the registration policy are 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). guaranteed to be non-overlapping).
Index value: Percent-encoding (Section 2.1 of RFC 3986 [STD66]) is Index value: Percent-encoding (Section 2.1 of RFC 3986 [STD66]) is
required of any characters in unit names except for the set required of any characters in unit names except for the set
"unreserved" (Section 2.3 of RFC 3986 [STD66]), the set "sub- "unreserved" (Section 2.3 of RFC 3986 [STD66]), the set "sub-
delims" (Section 2.3 of RFC 3986 [STD66]), ":" or "@" (i.e., the delims" (Section 2.3 of RFC 3986 [STD66]), and ":" or "@" (i.e.,
result must match the ABNF rule "pchar" in Section 3.3 of RFC 3986 the result must match the ABNF rule "pchar" in Section 3.3 of RFC
[STD66]). 3986 [STD66]).
7.4. SenML registry group 7.4. SenML Registry Group
IANA is requested to add the following note to the SenML registry IANA has added the following note to the "Sensor Measurement Lists
group [IANA.senml]: (SenML)" registry group [IANA.senml]:
| In SDF [RFC XXXX], a URI unit name is distinguished from a | In SDF [RFC9880], a URI unit name is distinguished from a
| registered unit name by the presence of a colon; any registered | registered unit name by the presence of a colon; any registered
| unit name that contains a colon can therefore not be directly used | unit name that contains a colon can therefore not be directly used
| in SDF. | in SDF.
7.5. Registries 7.5. Registries
IANA is requested to create a "Semantic Definition Format (SDF)" IANA has created the "Semantic Definition Format (SDF)" registry
registry group, with the registries defined in this Section. group with the registries defined in this Section.
7.5.1. Quality Names 7.5.1. SDF Quality Names
IANA is requested to create a "Quality Names" registry in the IANA has created the "SDF Quality Names" registry in the "Semantic
"Semantic Definition Format (SDF)" registry group, with the following Definition Format (SDF)" registry group with the following template:
template:
Name: A quality name composed of ASCII letters, digits, and dollar Name: A quality name composed of ASCII letters, digits, and dollar
signs, starting with a lower case ASCII letter or a dollar sign signs, starting with a lowercase ASCII letter or a dollar sign
(i.e., using a pattern of "[a-z$][A-Za-z$0-9]*"). (i.e., using a pattern of "[a-z$][A-Za-z$0-9]*").
Brief Description: A brief description. Brief Description: A brief description.
Reference: A pointer to a specification. Reference: A pointer to a specification.
Change Controller: (see Section 2.3 of RFC 8126 [BCP26]) Change Controller: (See Section 2.3 of RFC 8126 [BCP26])
Quality Names in this registry are intended to be registered in Quality Names in this registry are intended to be registered in
conjunction with RFCs and activities of the IETF. conjunction with RFCs and activities of the IETF.
The registration policy is Specification Required as per Section 4.6 The registration policy is Specification Required as per Section 4.6
of RFC 8126 [BCP26]. (Note that the policy is not "RFC Required" or 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 "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 registrations can be made earlier in the process, even earlier than
foreseen in [BCP100].) foreseen in [BCP100].)
The instructions to the Experts are: The instructions to the Experts are:
* to ascertain that the specification is available in an immutable * to ascertain that the specification is available in an immutable
reference and has achieved a good level of review in conjunction reference and has achieved a good level of review in conjunction
with RFCs or activities of the IETF, and with RFCs or activities of the IETF, and
* to be frugal in the allocation of quality names that are * to be frugal in the allocation of quality names that are
suggestive of generally applicable semantics, keeping them in suggestive of generally applicable semantics, keeping them in
reserve for qualities that are likely to enjoy wide use and can reserve for qualities that are likely to enjoy wide use and can
make good use of their conciseness. make good use of their conciseness.
The "Quality Names" registry starts out as in Table 13; all The "SDF Quality Names" registry starts out as in Table 13; all
references for these initial entries are to RFC XXXX and all change references for these initial entries are to RFC 9880 (this document)
controllers are given as "IETF"". and all change controllers are "IETF"".
+----------------------+------------------------------------------+ +======================+==========================================+
| Name | Brief Description | | Name | Brief Description |
+----------------------+------------------------------------------+ +======================+==========================================+
| $comment | source code comments only, no semantics | | $comment | source code comments only, no semantics |
+----------------------+------------------------------------------+
| const | constant value | | const | constant value |
+----------------------+------------------------------------------+
| contentFormat | content format | | contentFormat | content format |
+----------------------+------------------------------------------+
| default | default value | | default | default value |
+----------------------+------------------------------------------+
| description | long description text | | description | long description text |
+----------------------+------------------------------------------+
| enum | sdfChoice limited to text strings | | enum | sdfChoice limited to text strings |
+----------------------+------------------------------------------+
| exclusiveMaximum | exclusive maximum for a number | | exclusiveMaximum | exclusive maximum for a number |
+----------------------+------------------------------------------+
| exclusiveMinimum | exclusive minimum for a number | | exclusiveMinimum | exclusive minimum for a number |
+----------------------+------------------------------------------+
| format | specific format for a text string | | format | specific format for a text string |
+----------------------+------------------------------------------+
| items | items of an array | | items | items of an array |
+----------------------+------------------------------------------+
| label | short text (no constraints); defaults to | | label | short text (no constraints); defaults to |
| | key | | | key |
+----------------------+------------------------------------------+
| maxItems | maximum number of items in an array | | maxItems | maximum number of items in an array |
+----------------------+------------------------------------------+
| maxLength | maximum length for a text string (in | | maxLength | maximum length for a text string (in |
| | characters, i.e., Unicode scalar values) | | | characters, i.e., Unicode scalar values) |
+----------------------+------------------------------------------+
| maximum | maximum for a number | | maximum | maximum for a number |
+----------------------+------------------------------------------+
| minItems | minimum number of items in an array | | minItems | minimum number of items in an array |
+----------------------+------------------------------------------+
| minLength | minimum length for a text string (in | | minLength | minimum length for a text string (in |
| | characters, i.e., Unicode scalar values) | | | characters, i.e., Unicode scalar values) |
+----------------------+------------------------------------------+
| minimum | minimum for a number | | minimum | minimum for a number |
+----------------------+------------------------------------------+
| multipleOf | step size of number | | multipleOf | step size of number |
+----------------------+------------------------------------------+
| nullable | boolean: can the item be left out? | | nullable | boolean: can the item be left out? |
+----------------------+------------------------------------------+
| observable | boolean: can the item be observed? | | observable | boolean: can the item be observed? |
+----------------------+------------------------------------------+
| pattern | regular expression pattern for a text | | pattern | regular expression pattern for a text |
| | string | | | string |
+----------------------+------------------------------------------+
| properties | named dataqualities for type="object" | | properties | named dataqualities for type="object" |
+----------------------+------------------------------------------+
| readable | boolean: can the item be read? | | readable | boolean: can the item be read? |
+----------------------+------------------------------------------+
| required | which data items are required? | | required | which data items are required? |
+----------------------+------------------------------------------+
| sdfChoice | named dataqualities for a choice | | sdfChoice | named dataqualities for a choice |
+----------------------+------------------------------------------+
| sdfData | named dataqualities for an independent | | sdfData | named dataqualities for an independent |
| | data type definition | | | data type definition |
+----------------------+------------------------------------------+
| sdfInputData | input data to an action | | sdfInputData | input data to an action |
+----------------------+------------------------------------------+
| sdfOutputData | output data of an action or event | | sdfOutputData | output data of an action or event |
| | (sdfRequired applies here) | | | (sdfRequired applies here) |
+----------------------+------------------------------------------+
| sdfRef | sdf-pointer to definition being | | sdfRef | sdf-pointer to definition being |
| | referenced | | | referenced |
+----------------------+------------------------------------------+
| sdfRequired | pointer-list to declarations of required | | sdfRequired | pointer-list to declarations of required |
| | components | | | components |
+----------------------+------------------------------------------+
| sdfRequiredInputData | pointer-list to declarations of required | | sdfRequiredInputData | pointer-list to declarations of required |
| | input data for an action | | | input data for an action |
+----------------------+------------------------------------------+
| sdfType | more detailed information about the type | | sdfType | more detailed information about the type |
| | of a string | | | of a string |
+----------------------+------------------------------------------+
| type | general category of data type | | type | general category of data type |
+----------------------+------------------------------------------+
| uniqueItems | boolean: do the items of the array need | | uniqueItems | boolean: do the items of the array need |
| | to be all different? | | | to be all different? |
+----------------------+------------------------------------------+
| unit | engineering unit and scale (per SenML | | unit | engineering unit and scale (per SenML |
| | registry) | | | registry) |
+----------------------+------------------------------------------+
| writable | boolean: can the item be written to? | | writable | boolean: can the item be written to? |
+----------------------+------------------------------------------+ +----------------------+------------------------------------------+
Table 13: Initial Content of Quality Names Registry Table 13: Initial Content of the SDF Quality Names Registry
7.5.2. Quality Name Prefixes 7.5.2. SDF Quality Name Prefixes
IANA is requested to create a "Quality Name Prefixes" registry in the IANA has created the "SDF Quality Name Prefixes" registry in the
"Semantic Definition Format (SDF)" registry group, with the following "Semantic Definition Format (SDF)" registry group with the following
template: template:
Prefix: A quality name prefix composed of lower case ASCII letters Prefix: A quality name prefix composed of lower case ASCII letters
and digits, starting with a lower case ASCII letter (i.e., using a and digits, starting with a lower case ASCII letter (i.e., using a
pattern of "[a-z][a-z0-9]*"). pattern of "[a-z][a-z0-9]*").
Contact: A contact point for the organization that assigns quality Contact: A contact point for the organization that assigns quality
names with this prefix. names with this prefix.
Reference: A pointer to additional information, if available. Reference: A pointer to additional information, if available.
Quality Name Prefixes are intended to be registered by organizations Quality Name Prefixes are intended to be registered by organizations
that plan to define quality names constructed with an organization- that plan to define quality names constructed with an organization-
specifix prefix (Section 2.3.3). specific prefix (Section 2.3.3).
The registration policy is Expert Review as per Section 4.5 of RFC The registration policy is Expert Review as per Section 4.5 of RFC
8126 [BCP26]. The instructions to the Expert are to ascertain that 8126 [BCP26]. The instructions to the Expert are to ascertain that
the organization will handle quality names constructed using their the organization will handle quality names constructed using their
prefix in a way that roughly achieves the objectives for an IANA prefix in a way that roughly achieves the objectives for an IANA
registry that support interoperability of SDF models employing these registry that supports interoperability of SDF models employing these
quality names, including: quality names, including:
* Stability, "stable and permanent"; * Stability, "stable and permanent";
* Transparency, "readily available", "in sufficient detail" * Transparency, "readily available" and "in sufficient detail"
(Section 4.6 of RFC 8126 [BCP26]). (Section 4.6 of RFC 8126 [BCP26]).
The "Quality Name Prefixes" registry starts out empty. The "SDF Quality Name Prefixes" registry is empty at this time.
7.5.3. sdfType Values 7.5.3. sdfType Values
IANA is requested to create a "sdfType values" registry in the IANA has created the "sdfType Values" registry in the "Semantic
"Semantic Definition Format (SDF)" registry group, with the following Definition Format (SDF)" registry group with the following template:
template:
Name: A name composed of lower case ASCII letters, digits and - Name: A name composed of lower case ASCII letters, digits and -
(ASCII hyphen/minus) characters, starting with a lower case ASCII (ASCII hyphen/minus) characters, starting with a lower case ASCII
letter (i.e., using a pattern of "[a-z][-a-z0-9]*"). letter (i.e., using a pattern of "[a-z][-a-z0-9]*").
Description: A short description of the information model level Description: A short description of the information model level
structure and semantics structure and semantics.
type: The value of the quality "type" to be used with this sdfType type: The value of the quality "type" to be used with this sdfType.
JSON Representation A short description of a JSON representation JSON Representation A short description of a JSON representation
that can be used for this sdfType. As per Section 4.7.1, this that can be used for this sdfType. As per Section 4.7.1, this
MUST be consistent with the type. MUST be consistent with the type.
Reference: A more detailed specification of meaning and use of Reference: A more detailed specification of meaning and use of
sdfType. sdfType.
sdfType values are intended to be registered to enable modeling sdfType values are intended to be registered to enable modeling
additional SDF-specific types (see Section 4.7.1). additional SDF-specific types (see Section 4.7.1).
skipping to change at page 49, line 40 skipping to change at line 2201
The registration policy is Specification Required as per Section 4.6 The registration policy is Specification Required as per Section 4.6
of RFC 8126 [BCP26]. The instructions to the Expert are to ascertain of RFC 8126 [BCP26]. The instructions to the Expert are to ascertain
that the specification provides enough detail to enable that the specification provides enough detail to enable
interoperability between implementations of the sdfType being interoperability between implementations of the sdfType being
registered, and that names are chosen with enough specificity that registered, and that names are chosen with enough specificity that
ecosystem-specific sdfTypes will not be confused with more generally ecosystem-specific sdfTypes will not be confused with more generally
applicable ones. applicable ones.
The initial set of registrations is described in Table 5. The initial set of registrations is described in Table 5.
7.5.4. Feature Names 7.5.4. SDF Feature Names
IANA is requested to create a "Feature Names" registry in the IANA has created the "SDF Feature Names" registry in the "Semantic
"Semantic Definition Format (SDF)" registry group, with the following Definition Format (SDF)" registry group with the following template:
template:
Name: A feature name composed of ASCII letters, digits, and dollar Name: A feature name composed of ASCII letters, digits, and dollar
signs, starting with a lower case ASCII letter or a dollar sign signs, starting with a lower case ASCII letter or a dollar sign
(i.e., using a pattern of "[a-z$][A-Za-z$0-9]*"). (i.e., using a pattern of "[a-z$][A-Za-z$0-9]*").
Brief Description: A brief description. Brief Description: A brief description.
Reference: A pointer to a specification. Reference: A pointer to a specification.
Change Controller: (see Section 2.3 of RFC 8126 [BCP26]) Change Controller: (See Section 2.3 of RFC 8126 [BCP26])
The registration policy is Specification Required as per Section 4.6 The registration policy is Specification Required as per Section 4.6
of RFC 8126 [BCP26]. of RFC 8126 [BCP26].
The instructions to the Experts are: The instructions to the Experts are:
* to ascertain that the specification is available in an immutable * to ascertain that the specification is available in an immutable
reference and has achieved a good level of review, and reference and has achieved a good level of review, and
* to be frugal in the allocation of feature names that are * to be frugal in the allocation of feature names that are
suggestive of generally applicable semantics, keeping them in suggestive of generally applicable semantics, keeping them in
reserve for features that are likely to enjoy wide use and can reserve for features that are likely to enjoy wide use and can
make good use of their conciseness. make good use of their conciseness.
The "Feature Names" registry starts out empty. The "SDF Feature Names" registry is empty at this time.
8. Security Considerations 8. Security Considerations
Some wider security considerations applicable to Things are discussed Some wider security considerations applicable to Things are discussed
in [RFC8576]. in [RFC8576].
Section 5 of [RFC8610] gives an overview over security considerations Section 5 of [RFC8610] gives an overview over security considerations
that arise when formal description techniques are used to govern that arise when formal description techniques are used to govern
interoperability; analogs of these security considerations can apply interoperability; analogs of these security considerations can apply
to SDF. to SDF.
The security considerations of underlying building blocks such as The security considerations of underlying building blocks such as
those detailed in Section 10 of RFC 3629 [STD63] apply. those detailed in Section 10 of RFC 3629 [STD63] apply.
SDF uses JSON as a representation language. For a number of cases, SDF uses JSON as a representation language. For a number of cases,
[STD90] indicates that implementation behavior for certain constructs [STD90] indicates that implementation behavior for certain constructs
allowed by the JSON grammar is unpredictable. allowed by the JSON grammar is unpredictable.
Implementations need to be robust against invalid or unpredictable Implementations need to be robust against invalid or unpredictable
cases on input, preferably by rejecting input that is invalid or that cases on input, preferably by rejecting input that is invalid or that
would lead to unpredictable behavior, and need to avoid generating would lead to unpredictable behavior, and avoid generating these
these cases on output. cases on output.
Implementations of model languages may also exhibit performance- Implementations of model languages may also exhibit performance-
related availability issues when the attacker can control the input, related availability issues when the attacker can control the input,
see Section 4.1 of [RFC9535] for a brief discussion and Section 8 of see Section 4.1 of [RFC9535] for a brief discussion and Section 8 of
[RFC9485] for considerations specific to the use of pattern. [RFC9485] for considerations specific to the use of pattern.
SDF may be used in two processes that are often security relevant: SDF may be used in two processes that are often security relevant:
model-based _validation_ of data that is intended to be described by model-based _validation_ of data that is intended to be described by
SDF models, and model-based _augmentation_ of these data with SDF models and model-based _augmentation_ of these data with
information obtained from the SDF models that apply. information obtained from the SDF models that apply.
Implementations need to ascertain the provenance (and thus Implementations need to ascertain the provenance (and thus
authenticity and integrity) and applicability of the SDF models they authenticity and integrity) and applicability of the SDF models they
employ operationally in such security relevant ways. Implementations employ operationally in such security-relevant ways. Implementations
that make use of the composition mechanisms defined in this document 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 need to do this for each of the components they combine into the SDF
models they employ. Essentially, this process needs to undergo the models they employ. Essentially, this process needs to undergo the
same care and scrutiny as any other introduction of source code into same care and scrutiny as any other introduction of source code into
a build environment; the possibility of supply-chain attacks on the a build environment; the possibility of supply-chain attacks on the
modules imported needs to be considered. modules imported needs to be considered.
Specifically, implementations might rely on model-based input Specifically, implementations might rely on model-based input
validation for enforcing certain properties of the data structure validation for enforcing certain properties of the data structure
ingested (which, if not validated, could lead to malfunctions such as ingested (which, if not validated, could lead to malfunctions such as
skipping to change at page 51, line 29 skipping to change at line 2287
particularly careful about the data models they apply, including particularly careful about the data models they apply, including
their provenance and potential changes of these properties that their provenance and potential changes of these properties that
upgrades to the referenced modules may (inadvertently or as part of upgrades to the referenced modules may (inadvertently or as part of
an attack) cause. More generally speaking, implementations should an attack) cause. More generally speaking, implementations should
strive to be robust against expected and unexpected limitations of strive to be robust against expected and unexpected limitations of
the model-based input validation mechanisms and their the model-based input validation mechanisms and their
implementations. implementations.
Similarly, implementations that rely on model-based augmentation may Similarly, implementations that rely on model-based augmentation may
generate false data from their inputs; this is an integrity violation generate false data from their inputs; this is an integrity violation
in any case but also can possibly be exploited for further attacks. in any case, but also can possibly be exploited for further attacks.
In applications that dynamically acquire models and obtain modules In applications that dynamically acquire models and obtain modules
from module references in these, the security considerations of from module references in these, the security considerations of
dereferenceable identifiers apply (see [I-D.bormann-t2trg-deref-id] dereferenceable identifiers apply (see [DEREF-ID-PATTERN] for a more
for a more extensive discussion of dereferenceable identifiers). extensive discussion of dereferenceable identifiers).
There may be confidentiality requirements on SDF models, both on There may be confidentiality requirements on SDF models, both on
their content and on the fact that a specific model is used in a their content and on the fact that a specific model is used in a
particular Thing or environment. The present specification does not particular Thing or environment. The present specification does not
discuss model discovery or define an access control model for SDF discuss model discovery or define an access control model for SDF
models, nor does it define a way to obtain selective disclosure where models, nor does it define a way to obtain selective disclosure where
that may be required. It is likely that these definitions require that may be required. It is likely that these definitions require
additional context from underlying ecosystems and the characteristics additional context from underlying ecosystems and the characteristics
of the protocols employed there; this is therefore left as future of the protocols employed there; therefore, this is left as future
work (e.g., for documents such as [I-D.bormann-asdf-sdf-mapping]). work (e.g., for documents such as [SDF-MAPPING]).
9. References 9. References
9.1. Normative References 9.1. Normative References
[BCP14] Best Current Practice 14,
<https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
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>.
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>.
[BCP26] Best Current Practice 26, [BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>. <https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[BCP73] Best Current Practice 73, [BCP73] Best Current Practice 73,
skipping to change at page 52, line 49 skipping to change at line 2343
<https://www.iana.org/assignments/media-types>. <https://www.iana.org/assignments/media-types>.
[IANA.params] [IANA.params]
IANA, "Uniform Resource Name (URN) Namespace for IETF IANA, "Uniform Resource Name (URN) Namespace for IETF
Use", <https://www.iana.org/assignments/params>. Use", <https://www.iana.org/assignments/params>.
[IANA.senml] [IANA.senml]
IANA, "Sensor Measurement Lists (SenML)", IANA, "Sensor Measurement Lists (SenML)",
<https://www.iana.org/assignments/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: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901, "JavaScript Object Notation (JSON) Pointer", RFC 6901,
DOI 10.17487/RFC6901, April 2013, DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/rfc/rfc6901>. <https://www.rfc-editor.org/info/rfc6901>.
[RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396,
DOI 10.17487/RFC7396, October 2014, DOI 10.17487/RFC7396, October 2014,
<https://www.rfc-editor.org/rfc/rfc7396>. <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. [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
DOI 10.17487/RFC8428, August 2018, DOI 10.17487/RFC8428, August 2018,
<https://www.rfc-editor.org/rfc/rfc8428>. <https://www.rfc-editor.org/info/rfc8428>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8798] Bormann, C., "Additional Units for Sensor Measurement [RFC8798] Bormann, C., "Additional Units for Sensor Measurement
Lists (SenML)", RFC 8798, DOI 10.17487/RFC8798, June 2020, Lists (SenML)", RFC 8798, DOI 10.17487/RFC8798, June 2020,
<https://www.rfc-editor.org/rfc/rfc8798>. <https://www.rfc-editor.org/info/rfc8798>.
[RFC9165] Bormann, C., "Additional Control Operators for the Concise [RFC9165] Bormann, C., "Additional Control Operators for the Concise
Data Definition Language (CDDL)", RFC 9165, Data Definition Language (CDDL)", RFC 9165,
DOI 10.17487/RFC9165, December 2021, DOI 10.17487/RFC9165, December 2021,
<https://www.rfc-editor.org/rfc/rfc9165>. <https://www.rfc-editor.org/info/rfc9165>.
[RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists [RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists
(SenML) Fields for Indicating Data Value Content-Format", (SenML) Fields for Indicating Data Value Content-Format",
RFC 9193, DOI 10.17487/RFC9193, June 2022, RFC 9193, DOI 10.17487/RFC9193, June 2022,
<https://www.rfc-editor.org/rfc/rfc9193>. <https://www.rfc-editor.org/info/rfc9193>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>. 2024, <https://www.rfc-editor.org/info/rfc9562>.
[SPDX] "SPDX License List", <https://spdx.org/licenses/>. [SPDX] "SPDX License List", <https://spdx.org/licenses/>.
[STD63] Internet Standard 63, [STD63] Internet Standard 63,
<https://www.rfc-editor.org/info/std63>. <https://www.rfc-editor.org/info/std63>.
At the time of writing, this STD comprises the following: At the time of writing, this STD comprises the following:
Yergeau, F., "UTF-8, a transformation format of ISO Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 54, line 42 skipping to change at line 2441
<https://www.rfc-editor.org/info/std94>. <https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following: At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[W3C.NOTE-curie-20101216] [W3C.NOTE-curie-20101216]
Birbeck, M., Ed. and S. McCarron, Ed., "CURIE Syntax 1.0", Birbeck, M., Ed. and S. McCarron, Ed., "CURIE Syntax 1.0",
W3C NOTE NOTE-curie-20101216, W3C NOTE-curie-20101216, 16 W3C Working Group Note, 16 December 2010,
December 2010,
<https://www.w3.org/TR/2010/NOTE-curie-20101216/>. <https://www.w3.org/TR/2010/NOTE-curie-20101216/>.
9.2. Informative References 9.2. Informative References
[BCP100] Best Current Practice 100, [BCP100] Best Current Practice 100,
<https://www.rfc-editor.org/info/bcp100>. <https://www.rfc-editor.org/info/bcp100>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Cotton, M., "Early IANA Allocation of Standards Track Code Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>. 2014, <https://www.rfc-editor.org/info/rfc7120>.
[CamelCase] [CamelCase]
"Camel Case", December 2014, "Camel Case", December 2014,
<http://wiki.c2.com/?CamelCase>. <http://wiki.c2.com/?CamelCase>.
[ECMA-262] Ecma International, "ECMAScript 2020 Language [DEREF-ID-PATTERN]
Specification", ECMA Standard ECMA-262, 11th Edition, June
2020, <https://www.ecma-international.org/wp-
content/uploads/ECMA-262.pdf>.
[I-D.bormann-asdf-sdf-mapping]
Bormann, C. and J. Romann, "Semantic Definition Format
(SDF): Mapping files", Work in Progress, Internet-Draft,
draft-bormann-asdf-sdf-mapping-07, 20 July 2025,
<https://datatracker.ietf.org/doc/html/draft-bormann-asdf-
sdf-mapping-07>.
[I-D.bormann-asdf-sdftype-link]
Bormann, C., "An sdfType for Links", Work in Progress,
Internet-Draft, draft-bormann-asdf-sdftype-link-04, 6
December 2024, <https://datatracker.ietf.org/doc/html/
draft-bormann-asdf-sdftype-link-04>.
[I-D.bormann-t2trg-deref-id]
Bormann, C. and C. Amsüss, "The "dereferenceable Bormann, C. and C. Amsüss, "The "dereferenceable
identifier" pattern", Work in Progress, Internet-Draft, identifier" pattern", Work in Progress, Internet-Draft,
draft-bormann-t2trg-deref-id-05, 3 March 2025, draft-bormann-t2trg-deref-id-06, 30 August 2025,
<https://datatracker.ietf.org/doc/html/draft-bormann- <https://datatracker.ietf.org/doc/html/draft-bormann-
t2trg-deref-id-05>. t2trg-deref-id-06>.
[I-D.irtf-t2trg-rest-iot] [ECMA-262] Ecma International, "ECMAScript 2024 Language
Keränen, A., Kovatsch, M., and K. Hartke, "Guidance on Specification", 15th Edition, ECMA Standard ECMA-262, June
RESTful Design for Internet of Things Systems", Work in 2024, <https://www.ecma-international.org/wp-
Progress, Internet-Draft, draft-irtf-t2trg-rest-iot-16, 23 content/uploads/ECMA-262.pdf>.
April 2025, <https://datatracker.ietf.org/doc/html/draft-
irtf-t2trg-rest-iot-16>.
[JSO4] Galiegue, F., Zyp, K., and G. Court, "JSON Schema: core [JSO4] Galiegue, F., Ed., Zyp, K., Ed., and G. Court, "JSON
definitions and terminology", Work in Progress, Internet- Schema: core definitions and terminology", Work in
Draft, draft-zyp-json-schema-04, 31 January 2013, Progress, Internet-Draft, draft-zyp-json-schema-04, 31
<https://datatracker.ietf.org/doc/html/draft-zyp-json- January 2013, <https://datatracker.ietf.org/doc/html/
schema-04>. This is the base specification for json- draft-zyp-json-schema-04>.
schema.org "draft 4".
[JSO4V] Zyp, K. and G. Court, "JSON Schema: interactive and non [JSO4V] Zyp, K. and G. Court, "JSON Schema: interactive and non
interactive validation", Work in Progress, Internet-Draft, interactive validation", Work in Progress, Internet-Draft,
draft-fge-json-schema-validation-00, 31 January 2013, draft-fge-json-schema-validation-00, 31 January 2013,
<https://datatracker.ietf.org/doc/html/draft-fge-json- <https://datatracker.ietf.org/doc/html/draft-fge-json-
schema-validation-00>. This is the validation schema-validation-00>.
specification for json-schema.org "draft 4".
[JSO7] Wright, A. and H. Andrews, "JSON Schema: A Media Type for [JSO7] Wright, A., Ed., Andrews, H., Ed., Hutton, B., Ed., and G.
Describing JSON Documents", Work in Progress, Internet- Dennis, "JSON Schema: A Media Type for Describing JSON
Draft, draft-handrews-json-schema-01, 19 March 2018, Documents", Work in Progress, Internet-Draft, draft-
handrews-json-schema-02, 17 September 2019,
<https://datatracker.ietf.org/doc/html/draft-handrews- <https://datatracker.ietf.org/doc/html/draft-handrews-
json-schema-01>. This is the base specification for json- json-schema-02>.
schema.org "draft 7".
[JSO7V] Wright, A., Andrews, H., and G. Luff, "JSON Schema [JSO7V] Wright, A., Ed., Andrews, H., Ed., and B. Hutton, Ed.,
Validation: A Vocabulary for Structural Validation of "JSON Schema Validation: A Vocabulary for Structural
JSON", Work in Progress, Internet-Draft, draft-handrews- Validation of JSON", Work in Progress, Internet-Draft,
json-schema-validation-01, 19 March 2018, draft-handrews-json-schema-validation-02, 17 September
<https://datatracker.ietf.org/doc/html/draft-handrews- 2019, <https://datatracker.ietf.org/doc/html/draft-
json-schema-validation-01>. This is the validation handrews-json-schema-validation-02>.
specification for json-schema.org "draft 7".
[KebabCase] [KebabCase]
"Kebab Case", August 2014, "Kebab Case", August 2014,
<http://wiki.c2.com/?KebabCase>. <http://wiki.c2.com/?KebabCase>.
[OCF] "OCF Resource Type Specification", [OCF] Open Connectivity Foundation, "OCF Resource Type
Specification", Version 2.2.7, November 2023,
<https://openconnectivity.org/specs/ <https://openconnectivity.org/specs/
OCF_Resource_Type_Specification.pdf>. OCF_Resource_Type_Specification.pdf>.
[OMA] "OMA LightweightM2M (LwM2M) Object and Resource Registry", [OMA] Open Mobile Alliance, "OMA LightweightM2M (LwM2M) Object
and Resource Registry",
<http://www.openmobilealliance.org/wp/omna/lwm2m/ <http://www.openmobilealliance.org/wp/omna/lwm2m/
lwm2mregistry.html>. lwm2mregistry.html>.
[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-16, 23
April 2025, <https://datatracker.ietf.org/doc/html/draft-
irtf-t2trg-rest-iot-16>.
[RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
Things (IoT) Security: State of the Art and Challenges", Things (IoT) Security: State of the Art and Challenges",
RFC 8576, DOI 10.17487/RFC8576, April 2019, RFC 8576, DOI 10.17487/RFC8576, April 2019,
<https://www.rfc-editor.org/rfc/rfc8576>. <https://www.rfc-editor.org/info/rfc8576>.
[RFC9485] Bormann, C. and T. Bray, "I-Regexp: An Interoperable [RFC9485] Bormann, C. and T. Bray, "I-Regexp: An Interoperable
Regular Expression Format", RFC 9485, Regular Expression Format", RFC 9485,
DOI 10.17487/RFC9485, October 2023, DOI 10.17487/RFC9485, October 2023,
<https://www.rfc-editor.org/rfc/rfc9485>. <https://www.rfc-editor.org/info/rfc9485>.
[RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann, [RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,
Ed., "JSONPath: Query Expressions for JSON", RFC 9535, Ed., "JSONPath: Query Expressions for JSON", RFC 9535,
DOI 10.17487/RFC9535, February 2024, DOI 10.17487/RFC9535, February 2024,
<https://www.rfc-editor.org/rfc/rfc9535>. <https://www.rfc-editor.org/info/rfc9535>.
[SDF-MAPPING]
Bormann, C., Ed. and J. Romann, "Semantic Definition
Format (SDF): Mapping files", Work in Progress, Internet-
Draft, draft-bormann-asdf-sdf-mapping-05, 6 December 2024,
<https://datatracker.ietf.org/doc/html/draft-bormann-asdf-
sdf-mapping-05>.
[SDFTYPE-LINK]
Bormann, C., "An sdfType for Links", Work in Progress,
Internet-Draft, draft-bormann-asdf-sdftype-link-04, 6
December 2024, <https://datatracker.ietf.org/doc/html/
draft-bormann-asdf-sdftype-link-04>.
[STD97] Internet Standard 97, [STD97] Internet Standard 97,
<https://www.rfc-editor.org/info/std97>. <https://www.rfc-editor.org/info/std97>.
At the time of writing, this STD comprises the following: At the time of writing, this STD comprises the following:
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[WoT] Kaebisch, S., McCool, M., and E. Korkan, "Web of Things [WoT] Kaebisch, S., Ed., McCool, M., Ed., and E. Korkan, Ed.,
(WoT) Thing Description 1.1", W3C Recommendation, 5 "Web of Things (WoT) Thing Description 1.1",
December 2023, W3C Recommendation, 5 December 2023,
<https://www.w3.org/TR/wot-thing-description11/>. <https://www.w3.org/TR/2023/REC-wot-thing-
description11-20231205/>.
[ZCL] "The ZigBee Cluster Library", Elsevier, Zigbee Wireless [ZCL] "Chapter 6 - The ZigBee Cluster Library", Zigbee Wireless
Networking pp. 239-271, Networking, pp. 239-271,
DOI 10.1016/b978-0-7506-8597-9.00006-9, DOI 10.1016/b978-0-7506-8597-9.00006-9,
ISBN ["9780750685979"], 2008, ISBN 9780750685979, 2008,
<https://doi.org/10.1016/b978-0-7506-8597-9.00006-9>. <https://doi.org/10.1016/b978-0-7506-8597-9.00006-9>.
Appendix A. Formal Syntax of SDF Appendix A. Formal Syntax of SDF
This normative appendix describes the syntax of SDF using CDDL This normative appendix describes the syntax of SDF using CDDL
[RFC8610]. [RFC8610].
This appendix shows the framework syntax only, i.e., a syntax with This appendix shows the framework syntax only, i.e., a syntax with
liberal extension points. Since this syntax is nearly useless in liberal extension points. Since this syntax is nearly useless in
finding typos in an SDF specification, a second syntax, the finding typos in an SDF specification, a second syntax, the
skipping to change at page 62, line 44 skipping to change at line 2825
partial-time = time-hour ":" time-minute ":" time-second partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac] [time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday full-date = date-fullyear "-" date-month "-" date-mday
modified-dt = full-date ["T" partial-time "Z"] modified-dt = full-date ["T" partial-time "Z"]
' '
Appendix B. json-schema.org Rendition of SDF Syntax Appendix B. json-schema.org Rendition of SDF Syntax
This informative appendix describes the syntax of SDF defined in This informative appendix describes the syntax of SDF defined in
Appendix A, but using a version of the description techniques Appendix A, but uses a version of the description techniques
advertised on json-schema.org [JSO7] [JSO7V]. advertised on json-schema.org [JSO7] [JSO7V].
The appendix shows both the validation and the framework syntax. The appendix shows both the validation and the framework syntax.
Since most of the lines are the same between these two files, those 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 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 unified diff. Lines leading with a - are part of the validation
syntax, and lines leading with a + are part of the framework syntax. syntax and lines leading with a + are part of the framework syntax.
{ {
- "title": "sdf-validation.cddl -- Generated: 2024-02-29T07:42:35Z", - "title": "sdf-validation.cddl -- Generated: 2024-02-29T07:42:35Z",
+ "title": "sdf-framework.cddl -- Generated: 2024-02-29T07:42:52Z", + "title": "sdf-framework.cddl -- Generated: 2024-02-29T07:42:52Z",
"$schema": "http://json-schema.org/draft-07/schema#", "$schema": "http://json-schema.org/draft-07/schema#",
"$ref": "#/definitions/sdf-syntax", "$ref": "#/definitions/sdf-syntax",
"definitions": { "definitions": {
"sdf-syntax": { "sdf-syntax": {
"type": "object", "type": "object",
"properties": { "properties": {
skipping to change at page 104, line 24 skipping to change at line 4822
- "sdfType-": { - "sdfType-": {
- "type": "string", - "type": "string",
- "enum": [ - "enum": [
- "byte-string", - "byte-string",
- "unix-time" - "unix-time"
- ] - ]
} }
} }
} }
Appendix C. Data Qualities inspired by json-schema.org Appendix C. Data Qualities Inspired by json-schema.org
This appendix is normative. This appendix is normative.
Data qualities define data used in SDF affordances at an information Data qualities define data used in SDF affordances at an information
model level. A popular way to describe JSON data at a data model 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 level is proposed by a number of drafts on json-schema.org (which
collectively are abbreviated JSO here); for reference to a popular collectively are abbreviated JSO here); for reference to a popular
version this appendix points to [JSO7] and [JSO7V]. As the version, this appendix points to [JSO7] and [JSO7V]. As the
vocabulary used by JSO is familiar to many JSON modelers, the present vocabulary used by JSO is familiar to many JSON modelers, the present
specification borrows some of the terms and ports their semantics to specification borrows some of the terms and ports their semantics to
the information model level needed for SDF. the information model level needed for SDF.
The main data quality imported is the "type". In SDF, this can take 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 one of six (text string) values, which are discussed in the following
subsections (note that the JSO type "null" is not supported as a subsections (note that the JSO type "null" is not supported as a
value of this data quality in SDF). value of this data quality in SDF).
The additional quality "const" restricts the data to one specific The additional quality "const" restricts the data to one specific
skipping to change at page 105, line 18 skipping to change at line 4862
C.1. type "number", type "integer" C.1. type "number", type "integer"
The types "number" and "integer" are associated with floating point The types "number" and "integer" are associated with floating point
and integer numbers, as they are available in JSON. A type value of 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 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 (note that 10.0 is an integer value, even if it is in a notation that
would also allow non-zero decimal fractions). would also allow non-zero decimal fractions).
The additional data qualities "minimum", "maximum", The additional data qualities "minimum", "maximum",
"exclusiveMinimum", "exclusiveMaximum" provide number values that "exclusiveMinimum", and "exclusiveMaximum" provide number values that
serve as inclusive/exclusive lower/upper bounds for the number. serve as inclusive/exclusive lower/upper bounds for the number.
(Note that the Boolean form of "exclusiveMinimum"/"exclusiveMaximum" (Note that the Boolean form of "exclusiveMinimum"/"exclusiveMaximum"
found in earlier JSO drafts [JSO4V] is not used.) found in earlier JSO drafts [JSO4V] is not used.)
The data quality "multipleOf" gives a positive number that constrains The data quality "multipleOf" gives a positive number that constrains
the data value to be an integer multiple of the number given. (Type 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, "integer" can also be expressed as a "multipleOf" quality of value 1,
unless another "multipleOf" quality is present.) unless another "multipleOf" quality is present.)
C.2. type "string" C.2. type "string"
The type "string" is associated with Unicode text string values as The type "string" is associated with Unicode text string values, as
they can be represented in JSON. they can be represented in JSON.
The length (as measured in characters, specifically Unicode scalar The length (as measured in characters, specifically Unicode scalar
values) can be constrained by the additional data qualities values) can be constrained by the additional data qualities
"minLength" and "maxLength", which are inclusive bounds. "minLength" and "maxLength", which are inclusive bounds.
(More specifically, Unicode text strings as defined in this (More specifically, Unicode text strings as defined in this
specification are sequences of Unicode scalar values, the number of specification are sequences of Unicode scalar values, the number of
which is taken as the length of such a text string. which is taken as the length of such a text string.
skipping to change at page 106, line 4 skipping to change at line 4896
as an [ECMA-262] regular expression in Unicode mode that constrains as an [ECMA-262] regular expression in Unicode mode that constrains
the string (note that these are not anchored by default, so unless ^ the string (note that these are not anchored by default, so unless ^
and $ anchors are employed, ECMA-262 regular expressions match any and $ anchors are employed, ECMA-262 regular expressions match any
string that _contains_ a match). The JSO proposals acknowledge that string that _contains_ a match). The JSO proposals acknowledge that
regular expression support is rather diverse in various platforms, so regular expression support is rather diverse in various platforms, so
the suggestion is to limit them to: the suggestion is to limit them to:
* characters; * characters;
* character classes in square brackets, including ranges; their * character classes in square brackets, including ranges; their
complements; complements;
* simple quantifiers *, +, ?, and range quantifiers {n}, {n,m}, and * simple quantifiers *, +, ?, and range quantifiers {n}, {n,m}, and
{n,}; {n,};
* grouping parentheses; * grouping parentheses;
* the choice operator |; * the choice operator |;
* and anchors (beginning-of-input ^ and end-of-input $). * and anchors (beginning-of-input ^ and end-of-input $).
Note that this subset is somewhat similar to the subset introduced by Note that this subset is somewhat similar to the subset introduced by
I-Regexps [RFC9485], which however are anchored regular expressions, I-Regexps [RFC9485], which are anchored regular expressions and
and which include certain backslash escapes for characters and include certain backslash escapes for characters and character
character classes. classes.
The additional data quality "format" can take one of the following The additional data quality "format" can take one of the following
values. Note that, at an information model level, the presence of values. Note that, at an information model level, the presence of
this data quality changes the type from being a simple text string to 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- the abstract meaning of the format given (i.e., the format "date-
time" is less about the specific syntax employed in [RFC3339] than time" is less about the specific syntax employed in [RFC3339] than
about the usage as an absolute point in civil time). about the usage as an absolute point in civil time).
* "date-time", "date", "time": An [RFC3339] date-time, full-date, or * "date-time", "date", "time": A date-time, full-date, or full-time
full-time, respectively. as defined in [RFC3339], respectively.
* "uri", "uri-reference": An [STD66] URI or URI Reference, * "uri", "uri-reference": A URI or URI Reference as defined in
respectively. [STD66], respectively.
* "uuid": An [RFC9562] UUID. * "uuid": A Universally Unique Identifier (UUID) as defined in
[RFC9562]).
C.3. type "boolean" C.3. type "boolean"
The type "boolean" can take the values "true" or "false". The type "boolean" can take the values "true" or "false".
C.4. type "array" C.4. type "array"
The type "array" is associated with arrays as they are available in 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 The additional quality "items" gives the type that each of the
elements of the array must match. elements of the array must match.
The number of elements in the array can be constrained by the The number of elements in the array can be constrained by the
additional data qualities "minItems" and "maxItems", which are additional data qualities "minItems" and "maxItems", which are
inclusive bounds. inclusive bounds.
The additional data quality "uniqueItems" gives a Boolean value that, The additional data quality "uniqueItems" gives a Boolean value that,
if true, requires the elements to be all different. if true, requires the elements to be all different.
C.5. type "object" C.5. type "object"
The type "object" is associated with maps, from strings to values, as The type "object" is associated with maps, from strings to values, as
they are available in JSON. they are available in JSON.
The additional quality "properties" is a map the entries of which The additional quality "properties" is a map the entries of which
describe entries in the specified JSON map: The key gives an 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 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 with a named set of data qualities giving the type for the
corresponding value in the specified JSON map. corresponding value in the specified JSON map.
All entries specified this way are optional, unless they are listed All entries specified in this way are optional unless they are listed
in the value of the additional quality "required", which is an array in the value of the additional quality "required", which is an array
of string values that give the key names of required entries. of string values that give the key names of required entries.
Note that the term "properties" as an additional quality for defining Note that the term "properties" as an additional quality for defining
map entries is unrelated to sdfProperty. map entries is unrelated to sdfProperty.
For example, to include information about the type of the event in For example, to include information about the type of the event in
the "overTemperatureEvent" of Figure 4, the sdfOutputData there could the "overTemperatureEvent" of Figure 4, the sdfOutputData there could
be defined as follows: be defined as follows:
skipping to change at page 107, line 35 skipping to change at line 4975
"alarmType": { "alarmType": {
"sdfRef": "cap:#/sdfData/alarmTypes/quantityAlarms", "sdfRef": "cap:#/sdfData/alarmTypes/quantityAlarms",
"const": "OverTemperatureAlarm" "const": "OverTemperatureAlarm"
}, },
"temperature": { "temperature": {
"sdfRef": "#/sdfObject/temperatureWithAlarm/sdfData/temperatureData" "sdfRef": "#/sdfObject/temperatureWithAlarm/sdfData/temperatureData"
} }
} }
} }
Figure 6: Using object type with sdfOutputData Figure 6: Using Object Type with sdfOutputData
C.6. Implementation notes C.6. Implementation Notes
JSO-based keywords are also used in the specification techniques of a JSO-based keywords are also used in the specification techniques of a
number of ecosystems, but some adjustments may be required. number of ecosystems, but some adjustments may be required.
For instance, [OCF] is based on Swagger 2.0 which appears to be based For instance, [OCF] is based on Swagger 2.0, which appears to be
on "draft-4" [JSO4][JSO4V] (also called draft-5, but semantically based on "draft-4" [JSO4] [JSO4V] (also called draft-5, but
intended to be equivalent to draft-4). The "exclusiveMinimum" and semantically intended to be equivalent to draft-4). The
"exclusiveMaximum" keywords use the Boolean form there, so on import "exclusiveMinimum" and "exclusiveMaximum" keywords use the Boolean
to SDF their values have to be replaced by the values of the form there, so on import to SDF, their values have to be replaced by
respective "minimum"/"maximum" keyword, which are themselves then the values of the respective "minimum"/"maximum" keyword, which are
removed; the reverse transformation applies on export. then removed; the reverse transformation applies on export.
Appendix D. Composition Examples Appendix D. Composition Examples
This informative appendix contains two examples illustrating This informative appendix contains two examples illustrating
different composition approaches using the sdfThing quality. different composition approaches using the sdfThing quality.
D.1. Outlet Strip Example D.1. Outlet Strip Example
{ {
"sdfThing": { "sdfThing": {
skipping to change at page 110, line 16 skipping to change at line 5076
revisions of SDF have been in use for several years, and both revisions of SDF have been in use for several years, and both
significant collections of older SDF models and older SDF conversion significant collections of older SDF models and older SDF conversion
tools are available today. This appendix provides a brief checklist tools are available today. This appendix provides a brief checklist
that can aid in upgrading these to the standard. that can aid in upgrading these to the standard.
* The quality unit was previously called units. * The quality unit was previously called units.
* sdfType was developed out of a concept previously called subtype. * sdfType was developed out of a concept previously called subtype.
* sdfChoice is the preferred way to represent JSO enum (only a * sdfChoice is the preferred way to represent JSO enum (only a
limited form of which is retained), and also the way to represent limited form of which is retained) and also the way to represent
JSO anyOf. JSO anyOf.
* the length of text strings (as used with minLength/maxLength * The length of text strings (as used with minLength/maxLength
constraints) was previously defined in bytes. It now is defined constraints) was previously defined in bytes. It now is defined
as the number of characters (Unicode scalar values, to be exact); as the number of characters (Unicode scalar values, to be exact);
a length in bytes is not meaningful unless bound to a specific a length in bytes is not meaningful unless bound to a specific
encoding, which might differ from UTF-8 in some ecosystem mappings encoding, which might differ from UTF-8 in some ecosystem mappings
and protocol bindings. and protocol bindings.
List of Figures List of Figures
Figure 1: A simple example of an SDF document Figure 1: A Simple Example of an SDF Document
Figure 2: Main classes used in SDF models Figure 2: Main Classes Used in SDF Models
Figure 3: Example sdfObject definition Figure 3: Example sdfObject Definition
Figure 4: Using sdfRequired Figure 4: Using sdfRequired
Figure 5: Using an Override to Further Restrict the Set of Data Figure 5: Using an Override to Further Restrict the Set of Data
Values Values
Figure 6: Using object type with sdfOutputData Figure 6: Using Object Type with sdfOutputData
Figure 7: Outlet Strip Example Figure 7: Outlet Strip Example
Figure 8: Refrigerator-Freezer Example Figure 8: Refrigerator-Freezer Example
List of Tables List of Tables
Table 1: Qualities of the Information Block Table 1: Qualities of the Information Block
Table 2: Namespaces Block Table 2: Namespaces Block
Table 3: Common Qualities Table 3: Common Qualities
Table 4: SDF-defined Qualities of sdfData and sdfProperty Table 4: SDF-Defined Qualities of sdfData and sdfProperty
Table 5: Values Defined in Base SDF for the sdfType Quality Table 5: Values Defined in Base SDF for the sdfType Quality
Table 6: Qualities of sdfObject Table 6: Qualities of sdfObject
Table 7: Qualities of sdfProperty Table 7: Qualities of sdfProperty
Table 8: Qualities of sdfAction Table 8: Qualities of sdfAction
Table 9: Qualities of sdfEvent Table 9: Qualities of sdfEvent
Table 10: Qualities of sdfThing Table 10: Qualities of sdfThing
Table 11: Media Type Registration for SDF Table 11: Media Type Registration for SDF
Table 12: SDF Content-format Registration Table 12: SDF Content-Format Registration
Table 13: Initial Content of Quality Names Registry Table 13: Initial Content of the SDF Quality Names Registry
Acknowledgements Acknowledgements
This specification is based on work by the One Data Model group. This specification is based on work by the One Data Model group.
Contributors Contributors
Jan Romann Jan Romann
Hochschule Emden/Leer Hochschule Emden/Leer
Germany Germany
skipping to change at page 111, line 29 skipping to change at line 5138
Threefield Lane Threefield Lane
Southampton Southampton
United Kingdom United Kingdom
Email: w.vanderbeek@cascoda.com Email: w.vanderbeek@cascoda.com
Authors' Addresses Authors' Addresses
Michael Koster (editor) Michael Koster (editor)
KTC Control AB KTC Control AB
29415 Alderpoint Road 29415 Alderpoint Road
Blocksburg, CA, 95514 Blocksburg, CA 95514
United States of America United States of America
Phone: +1-707-502-5136 Phone: +1-707-502-5136
Email: michaeljohnkoster@gmail.com Email: michaeljohnkoster@gmail.com
Carsten Bormann (editor) Carsten Bormann (editor)
Universität Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
 End of changes. 337 change blocks. 
563 lines changed or deleted 610 lines changed or added

This html diff was produced by rfcdiff 1.48.