< draft-ietf-asdf-sdf-07.txt		draft-ietf-asdf-sdf-08.txt >
	ASDF M. Koster, Ed.		ASDF M. Koster, Ed.
	Internet-Draft Dogtiger Labs		Internet-Draft PassiveLogic
	Intended status: Standards Track C. Bormann, Ed.		Intended status: Standards Track C. Bormann, Ed.
	Expires: 13 January 2022 Universität Bremen TZI		Expires: 28 April 2022 Universität Bremen TZI
	12 July 2021		25 October 2021
	Semantic Definition Format (SDF) for Data and Interactions of Things		Semantic Definition Format (SDF) for Data and Interactions of Things
	draft-ietf-asdf-sdf-07		draft-ietf-asdf-sdf-08
	Abstract		Abstract
	The Semantic Definition Format (SDF) is a format for domain experts		The Semantic Definition Format (SDF) is a format for domain experts
	to use in the creation and maintenance of data and interaction models		to use in the creation and maintenance of data and interaction models
	in the Internet of Things. It was created as a common language for		in the Internet of Things. It was created as a common language for
	use in the development of the One Data Model liaison organization		use in the development of the One Data Model liaison organization
	(OneDM) definitions. Tools convert this format to database formats		(OneDM) definitions. Tools convert this format to database formats
	and other serializations as needed.		and other serializations as needed.
	An SDF specification describes definitions of SDF Objects and their		An SDF specification describes definitions of SDF Objects and their
	associated interactions (Events, Actions, Properties), as well as the		associated interactions (Events, Actions, Properties), as well as the
	Data types for the information exchanged in those interactions.		Data types for the information exchanged in those interactions.
	// A JSON format representation of SDF 1.0 was defined in version		// A JSON format representation of SDF 1.0 was defined in version
	// (-00) of this document; version (-05) was designated as an		// (-00) of this document; version (-05) was designated as an
	// _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of		// _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of
	// the ASDF WG (2021-03-11). The present version (-07) has a few		// the ASDF WG (2021-03-11). The present version (-08) adds URIs as
	// editorial improvements over -06, which was discussed at the ASDF		// alternative measurement unit names, is editorially more self-
	// interim meeting on 2021-06-02.		// contained, and uses updated xml2rfc conventions for its plain-text
			// rendering.
	Contributing		Contributing
	Recent versions of this document are available at its GitHub		Recent versions of this document are available at its GitHub
	repository https://github.com/ietf-wg-asdf/SDF (https://github.com/		repository https://github.com/ietf-wg-asdf/SDF (https://github.com/
	ietf-wg-asdf/SDF) -- this also provides an issue tracker as well as a		ietf-wg-asdf/SDF) -- this also provides an issue tracker as well as a
	way to supply "pull requests".		way to supply "pull requests".
	General discussion of this SDF Internet-Draft happens on the mailing		General discussion of this SDF Internet-Draft happens on the mailing
	list of the IETF ASDF Working Group, asdf@ietf.org (subscribe at		list of the IETF ASDF Working Group, asdf@ietf.org (subscribe at
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 13 January 2022.		This Internet-Draft will expire on 28 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Terminology and Conventions . . . . . . . . . . . . . . . 4		1.1. Terminology and Conventions . . . . . . . . . . . . . . . 4
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Example Definition . . . . . . . . . . . . . . . . . . . 6		2.1. Example Definition . . . . . . . . . . . . . . . . . . . 6
	2.2. Elements of an SDF model . . . . . . . . . . . . . . . . 7		2.2. Elements of an SDF model . . . . . . . . . . . . . . . . 8
	2.2.1. sdfObject . . . . . . . . . . . . . . . . . . . . . . 8		2.2.1. sdfObject . . . . . . . . . . . . . . . . . . . . . . 9
	2.2.2. sdfProperty . . . . . . . . . . . . . . . . . . . . . 9		2.2.2. sdfProperty . . . . . . . . . . . . . . . . . . . . . 10
	2.2.3. sdfAction . . . . . . . . . . . . . . . . . . . . . . 10		2.2.3. sdfAction . . . . . . . . . . . . . . . . . . . . . . 11
	2.2.4. sdfEvent . . . . . . . . . . . . . . . . . . . . . . 10		2.2.4. sdfEvent . . . . . . . . . . . . . . . . . . . . . . 11
	2.2.5. sdfData . . . . . . . . . . . . . . . . . . . . . . . 11		2.2.5. sdfData . . . . . . . . . . . . . . . . . . . . . . . 12
	2.2.6. sdfThing . . . . . . . . . . . . . . . . . . . . . . 11		2.2.6. sdfThing . . . . . . . . . . . . . . . . . . . . . . 12
	2.2.7. sdfProduct . . . . . . . . . . . . . . . . . . . . . 11		2.2.7. sdfProduct . . . . . . . . . . . . . . . . . . . . . 12
	3. SDF structure . . . . . . . . . . . . . . . . . . . . . . . . 11		3. SDF structure . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.1. Information block . . . . . . . . . . . . . . . . . . . . 12		3.1. Information block . . . . . . . . . . . . . . . . . . . . 13
	3.2. Namespaces section . . . . . . . . . . . . . . . . . . . 13		3.2. Namespaces section . . . . . . . . . . . . . . . . . . . 14
	3.3. Definitions section . . . . . . . . . . . . . . . . . . . 14		3.3. Definitions section . . . . . . . . . . . . . . . . . . . 15
	4. Names and namespaces . . . . . . . . . . . . . . . . . . . . 15		4. Names and namespaces . . . . . . . . . . . . . . . . . . . . 16
	4.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 15		4.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.2. Contributing global names . . . . . . . . . . . . . . . . 15		4.2. Contributing global names . . . . . . . . . . . . . . . . 16
	4.3. Referencing global names . . . . . . . . . . . . . . . . 16		4.3. Referencing global names . . . . . . . . . . . . . . . . 17
	4.4. sdfRef . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.4. sdfRef . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.5. sdfRequired . . . . . . . . . . . . . . . . . . . . . . . 18		4.5. sdfRequired . . . . . . . . . . . . . . . . . . . . . . . 19
	4.6. Common Qualities . . . . . . . . . . . . . . . . . . . . 19		4.6. Common Qualities . . . . . . . . . . . . . . . . . . . . 20
	4.7. Data Qualities . . . . . . . . . . . . . . . . . . . . . 20		4.7. Data Qualities . . . . . . . . . . . . . . . . . . . . . 21
	4.7.1. sdfType . . . . . . . . . . . . . . . . . . . . . . . 24		4.7.1. sdfType . . . . . . . . . . . . . . . . . . . . . . . 23
	4.7.2. sdfChoice . . . . . . . . . . . . . . . . . . . . . . 25		4.7.2. sdfChoice . . . . . . . . . . . . . . . . . . . . . . 24
	5. Keywords for definition groups . . . . . . . . . . . . . . . 27		5. Keywords for definition groups . . . . . . . . . . . . . . . 26
	5.1. sdfObject . . . . . . . . . . . . . . . . . . . . . . . . 27		5.1. sdfObject . . . . . . . . . . . . . . . . . . . . . . . . 26
	5.2. sdfProperty . . . . . . . . . . . . . . . . . . . . . . . 28		5.2. sdfProperty . . . . . . . . . . . . . . . . . . . . . . . 27
	5.3. sdfAction . . . . . . . . . . . . . . . . . . . . . . . . 28		5.3. sdfAction . . . . . . . . . . . . . . . . . . . . . . . . 27
	5.4. sdfEvent . . . . . . . . . . . . . . . . . . . . . . . . 29		5.4. sdfEvent . . . . . . . . . . . . . . . . . . . . . . . . 28
	5.5. sdfData . . . . . . . . . . . . . . . . . . . . . . . . . 29		5.5. sdfData . . . . . . . . . . . . . . . . . . . . . . . . . 28
	6. High Level Composition . . . . . . . . . . . . . . . . . . . 29		6. High Level Composition . . . . . . . . . . . . . . . . . . . 28
	6.1. Paths in the model namespaces . . . . . . . . . . . . . . 30		6.1. Paths in the model namespaces . . . . . . . . . . . . . . 29
	6.2. Modular Composition . . . . . . . . . . . . . . . . . . . 30		6.2. Modular Composition . . . . . . . . . . . . . . . . . . . 29
	6.2.1. Use of the "sdfRef" keyword to re-use a definition . 31		6.2.1. Use of the "sdfRef" keyword to re-use a definition . 30
	6.3. sdfThing . . . . . . . . . . . . . . . . . . . . . . . . 32		6.3. sdfThing . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.4. sdfProduct . . . . . . . . . . . . . . . . . . . . . . . 32		6.4. sdfProduct . . . . . . . . . . . . . . . . . . . . . . . 31
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 33		7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 32
	7.2. Registries . . . . . . . . . . . . . . . . . . . . . . . 33		7.2. Registries . . . . . . . . . . . . . . . . . . . . . . . 32
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 33		8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	9.1. Normative References . . . . . . . . . . . . . . . . . . 34		9.1. Normative References . . . . . . . . . . . . . . . . . . 33
	9.2. Informative References . . . . . . . . . . . . . . . . . 35		9.2. Informative References . . . . . . . . . . . . . . . . . 34
	Appendix A. Formal Syntax of SDF . . . . . . . . . . . . . . . . 36		Appendix A. Formal Syntax of SDF . . . . . . . . . . . . . . . . 35
	Appendix B. json-schema.org Rendition of SDF Syntax . . . . . . 40		Appendix B. json-schema.org Rendition of SDF Syntax . . . . . . 39
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 78		Appendix C. Data Qualities inspired by json-schema.org . . . . . 78
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 78		C.1. type "number", type "integer" . . . . . . . . . . . . . . 79
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79		C.2. type "string" . . . . . . . . . . . . . . . . . . . . . . 79
			C.3. type "boolean" . . . . . . . . . . . . . . . . . . . . . 80
			C.4. type "array" . . . . . . . . . . . . . . . . . . . . . . 80
			C.5. type "object" . . . . . . . . . . . . . . . . . . . . . . 80
			C.6. Implementation notes . . . . . . . . . . . . . . . . . . 81
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 81
			Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 81
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
	1. Introduction		1. Introduction
	The Semantic Definition Format (SDF) is a format for domain experts		The Semantic Definition Format (SDF) is a format for domain experts
	to use in the creation and maintenance of data and interaction models		to use in the creation and maintenance of data and interaction models
	in the Internet of Things. It was created as a common language for		in the Internet of Things. It was created as a common language for
	use in the development of the One Data Model liaison organization		use in the development of the One Data Model liaison organization
	(OneDM) definitions. Tools convert this format to database formats		(OneDM) definitions. Tools convert this format to database formats
	and other serializations as needed.		and other serializations as needed.
	An SDF specification describes definitions of SDF Objects and their		An SDF specification describes definitions of SDF Objects and their
	associated interactions (Events, Actions, Properties), as well as the		associated interactions (Events, Actions, Properties), as well as the
	Data types for the information exchanged in those interactions.		Data types for the information exchanged in those interactions.
	// A JSON format representation of SDF 1.0 was defined in version		// A JSON format representation of SDF 1.0 was defined in version
	// (-00) of this document; version (-05) was designated as an		// (-00) of this document; version (-05) was designated as an
	// _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of		// _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of
	// the ASDF WG (2021-03-11). The present version (-07) has a few		// the ASDF WG (2021-03-11). The present version (-08) adds URIs as
	// editorial improvements over -06, which was discussed at the ASDF		// alternative measurement unit names, is editorially more self-
	// interim meeting on 2021-06-02.		// contained, and uses updated xml2rfc conventions for its plain-text
			// rendering.
	1.1. Terminology and Conventions		1.1. Terminology and Conventions
	Thing: A physical item that is also made available in the Internet		Thing: A physical item that is also made available in the Internet
	of Things. The term is used here for Things that are notable for		of Things. The term is used here for Things that are notable for
	their interaction with the physical world beyond interaction with		their interaction with the physical world beyond interaction with
	humans; a temperature sensor or a light might be a Thing, but a		humans; a temperature sensor or a light might be a Thing, but a
	router that employs both temperature sensors and indicator lights		router that employs both temperature sensors and indicator lights
	might exhibit less Thingness, as the effects of its functioning		might exhibit less Thingness, as the effects of its functioning
	are mostly on the digital side.		are mostly on the digital side.
	skipping to change at page 4, line 45 ¶		skipping to change at page 5, line 11 ¶
	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 together serve a specific function.		specification; these entries together serve a specific function.
	Group: An entry in the main SDF map and in certain nested		Group: An entry in the main SDF map and in certain nested
	definitions that has a Class Name Keyword as its key and a map of		definitions that has a Class Name Keyword as its key and a map of
	definition entries (Definition Group) as a value.		definition entries (Definition Group) as a value.
	Class Name Keyword: One of sdfThing, sdfProduct, sdfObject,		Class Name Keyword: One of sdfThing, sdfProduct, sdfObject,
	sdfProperty, sdfAction, sdfEvent, or sdfData; the Classes for		sdfProperty, sdfAction, sdfEvent, or sdfData; the Classes for
	these type keywords are capitalized and prefixed with "sdf".		these type 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.
	Property: An affordance that can potentially be used to read, write,		Property: An affordance that can potentially be used to read, write,
	and/or observe state on an Object. (Note that Entries are often		and/or observe state on an Object. (Note that Entries are often
	called properties in other environments; in this document, the		called properties in other environments; in this document, the
	term Property is specifically reserved for affordances, even if		term Property is specifically reserved for affordances, even if
	the map key "properties" might be imported from a data definition		the map key "properties" might be imported from a data definition
	language with the other semantics.)		language with the other semantics.)
	skipping to change at page 5, line 42 ¶		skipping to change at page 6, line 8 ¶
	Declaration: A reference to and a use of a definition within an		Declaration: A reference to and a use of a definition within an
	enclosing definition, intended to create component instances		enclosing definition, intended to create component instances
	within that enclosing definition. Every declaration can also be		within that enclosing definition. Every declaration can also be
	used as a definition for reference in a different place.		used as a definition for reference in a different place.
	Protocol Binding: A companion document to an SDF specification that		Protocol Binding: A companion document to an SDF specification that
	defines how to map the abstract concepts in the specification into		defines how to map the abstract concepts in the specification into
	the protocols in use in a specific ecosystem. Might supply URL		the protocols in use in a specific ecosystem. Might supply URL
	components, numeric IDs, and similar details.		components, numeric IDs, and similar details.
			The term "byte" is used in its now-customary sense as a synonym for
			"octet".
	Conventions:		Conventions:
	* 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 here.		defined here.
	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
	BCP 14 [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.
	skipping to change at page 6, line 48 ¶		skipping to change at page 7, line 41 ¶
	"toggle": {		"toggle": {
	"description": "Toggle the switch; equivalent to setting value to its complement."		"description": "Toggle the switch; equivalent to setting value to its complement."
	}		}
	}		}
	}		}
	}		}
	}		}
	Figure 1: A simple example of an SDF definition file		Figure 1: A simple example of an SDF definition file
	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		and will be false for "off". The actions on or off declared in the
	the "sdfAction" group are redundant with setting the "value" and are		sdfAction group are redundant with setting the value and are in the
	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 first retrieving the
	current value and then applying/setting the inverted value.		current value and then applying/setting the inverted value.
	The "sdfObject" group lists the affordances of instances of this		The sdfObject group lists the affordances of instances of this
	object. The "sdfProperty" group lists the property affordances		object. 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 object. Properties can have additional qualities to		state of the object. 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 [I-D.irtf-t2trg-rest-iot], describing state. The
	"sdfAction" group is the mechanism to describe other interactions in		sdfAction group is the mechanism to describe other interactions in
	terms of their names, input, and output data (no data are used in the		terms of their names, input, and output data (no data are used in the
	example), as in a POST method in REST or in a remote procedure call.		example), as in a POST method in REST or in a remote procedure call.
	The example "toggle" is an Action that changes the state based on the		The example toggle is an Action that changes the state based on the
	current state of the Property named "value". (The third type of		current state of the Property named value. (The third type of
	affordance is Events, which are not described in this example.)		affordance is Events, which are not described in this example.)
	In the JSON representation, note how (with the exception of the		In the JSON representation, note how (with the exception of the info
	"info" group) maps that have keys taken from the SDF vocabulary		group) maps that have keys taken from the SDF vocabulary (info,
	("info", "namespace", "sdfObject") alternate in nesting with maps		namespace, sdfObject) alternate in nesting with maps that have keys
	that have keys that are freely defined by the model writer ("Switch",		that are freely defined by the model writer (Switch, value, on,
	"value", "on", etc.); the latter usually use the "named<>" production		etc.); the latter usually use the named<> production in the formal
	in the formal syntax of SDF (Appendix A), while the former SDF-		syntax of SDF (Appendix A), while the former SDF-defined vocabulary
	defined vocabulary items are often, but not always, called		items are often, but not always, called _qualities_.
	_qualities_.
	2.2. Elements of an SDF model		2.2. Elements of an SDF model
	The SDF language uses seven predefined Class Name Keywords for		The SDF language uses seven predefined Class Name Keywords for
	modeling connected Things, six of which are illustrated in Figure 2		modeling connected Things, six of which are illustrated in Figure 2
	(the seventh class "sdfProduct" is similar enough to "sdfThing" that		(the seventh class sdfProduct is similar enough to sdfThing that it
	it would look the same in the figure).		would look the same in the figure).
	,--------.		,--------.
	|sdfThing|		|sdfThing|
	|--------|		|--------|
	`--------'		`--------'
	|		|
	|		|
	,---------.		,---------.
	|sdfObject|		|sdfObject|
	|---------|		|---------|
	skipping to change at page 8, line 33 ¶		skipping to change at page 9, line 33 ¶
	|sdfData|		|sdfData|
	|-------|		|-------|
	`-------'		`-------'
	Figure 2: Main classes used in SDF models		Figure 2: Main classes used in SDF models
	The seven main Class Name Keywords are discussed below.		The seven main Class Name Keywords are discussed below.
	2.2.1. sdfObject		2.2.1. sdfObject
	Objects, the items listed in an "sdfObject" group, are the main		Objects, the items listed in an sdfObject group, are the main "atom"
	"atom" of reusable semantics for model construction. It aligns in		of reusable semantics for model construction. It aligns in scope
	scope with common definition items from many IoT modeling systems,		with common definition items from many IoT modeling systems, for
	for example ZigBee Clusters [ZCL], OMA SpecWorks LwM2M Objects [OMA],		example ZigBee Clusters [ZCL], OMA SpecWorks LwM2M Objects [OMA], and
	and OCF Resource Types [OCF].		OCF Resource Types [OCF].
	An "sdfObject" contains a set of "sdfProperty", "sdfAction", and		An sdfObject contains a set of sdfProperty, sdfAction, and sdfEvent
	"sdfEvent" definitions that describe the interaction affordances		definitions that describe the interaction affordances associated with
	associated with some scope of functionality.		some scope of functionality.
	For the granularity of definition, "sdfObject" definitions are meant		For the granularity of definition, sdfObject definitions are meant to
	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		sdfObject definitions for on/off control, dimming, and color control
	control affordances will enable interoperable functionality to be		affordances will enable interoperable functionality to be configured
	configured for diverse product types. An "sdfObject" definition for		for diverse product types. An sdfObject definition for a common on/
	a common on/off control may be used to control may different kinds of		off control may be used to control may different kinds of Things that
	Things that require on/off control.		require on/off control.
	Optional qualities "minItems" and "maxItems" can be used to define		Optional qualities "minItems" and "maxItems" can be used to define
	sdfObjects as arrays.		sdfObjects as arrays.
	2.2.2. sdfProperty		2.2.2. sdfProperty
	"sdfProperty" is used to model elements of state within "sdfObject"		sdfProperty is used to model elements of state within sdfObject
	instances.		instances.
	An instance of "sdfProperty" may be associated with some protocol		An instance of sdfProperty may be associated with some protocol
	affordance to enable the application to obtain the state variable		affordance to enable the application to obtain the state variable
	and, optionally, modify the state variable. Additionally, some		and, optionally, modify the state variable. Additionally, some
	protocols provide for in-time reporting of state changes. (These		protocols provide for in-time reporting of state changes. (These
	three aspects are described by the qualities "readable", "writable",		three aspects are described by the qualities readable, writable, and
	and "observable" defined for an "sdfProperty".)		observable defined for an sdfProperty.)
	Definitions in "sdfProperty" groups look like definitions in		Definitions in sdfProperty groups look like definitions in sdfData
	"sdfData" groups, however, they actually also declare a Property with		groups, however, they actually also declare a Property with the given
	the given qualities to be potentially present in the containing		qualities to be potentially present in the containing Object.
	Object. (Qualities beyond those of "sdfData" definitions could be		(Qualities beyond those of sdfData definitions could be defined for
	defined for "sdfProperty" declarations but currently aren't; this		sdfProperty declarations but currently aren't; this means that even
	means that even Property qualities such as "readable" and "writable"		Property qualities such as readable and writable can be associated
	can be associated with definitions in "sdfData" groups, as well.)		with definitions in sdfData groups, as well.)
	For definitions in "sdfProperty" and "sdfData", SDF provides		For definitions in sdfProperty and sdfData, SDF provides qualities
	qualities that can constrain the structure and values of data allowed		that can constrain the structure and values of data allowed in an
	in an instance of these data, as well as qualities that associate		instance of these data, as well as qualities that associate semantics
	semantics to these data, for engineering units and unit scaling		to these data, for engineering units and unit scaling information.
	information.
	For the data definition within "sdfProperty" or "sdfData", SDF		For the data definition within sdfProperty or sdfData, SDF borrows
	borrows a number of elements proposed for the drafts 4 and 7 of the		some vocabulary proposed for the drafts 4 and 7 of the json-
	json-schema.org "JSON Schema" format		schema.org "JSON Schema" format (collectively called JSO here),
	[I-D.handrews-json-schema-validation], enhanced by qualities that are		enhanced by qualities that are specific to SDF. Details about the
	specific to SDF. For the current version of SDF, data are		former are in Appendix C. For the current version of SDF, data are
	constrained to be of simple types (number, string, Boolean), JSON		constrained to be of simple types (number, string, Boolean), JSON
	maps composed of named data ("objects"), and arrays of these types.		maps composed of named data ("objects"), and arrays of these types.
	Syntax extension points are provided that can be used to provide		Syntax extension points are provided that can be used to provide
	richer types in future versions of this specification (possibly more		richer types in future versions of this specification (possibly more
	of which can be borrowed from json-schema.org).		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
	general) are not intended to constrain the formats of data used for		general) are not intended to constrain the formats of data used for
	communication over network interfaces. Where needed, data		communication over network interfaces. Where needed, data
	definitions for payloads of protocol messages are expected to be part		definitions for payloads of protocol messages are expected to be part
	of the protocol binding.		of the protocol binding.
	2.2.3. sdfAction		2.2.3. sdfAction
	The "sdfAction" group contains declarations of Actions, model		The sdfAction group contains declarations of Actions, model
	affordances that, when triggered, have more effect than just reading,		affordances that, when triggered, have more effect than just reading,
	updating, or observing Thing state, often resulting in some outward		updating, or observing Thing state, often resulting in some outward
	physical effect (which, itself, cannot be modeled in SDF). From a		physical effect (which, itself, cannot be modeled in SDF). From a
	programmer's perspective, they might be considered to be roughly		programmer's perspective, they might be considered to be roughly
	analogous to method calls.		analogous to method calls.
	Actions may have data parameters; these are modeled as a single item		Actions may have data parameters; these are modeled as a single item
	of input data and output data, each. (Where multiple parameters need		of input data and output data, each. (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.) Actions may be long-running, that is to say		parameters into one.) Actions may be long-running, that is to say
	that the effects may not take place immediately as would be expected		that the effects may not take place immediately as would be expected
	for an update to an "sdfProperty"; the effects may play out over time		for an update to an sdfProperty; the effects may play out over time
	and emit action results. Actions may also not always complete and		and emit action results. Actions may also not always complete and
	may result in application errors, such as an item blocking the		may result in application errors, such as an item blocking the
	closing of an automatic door.		closing of an automatic door.
	Actions may have (or lack) qualities of idempotency and side-effect		Actions may have (or lack) qualities of idempotency and side-effect
	safety.		safety.
	The current version of SDF only provides data constraint modeling and		The current version of SDF only provides data constraint modeling and
	semantics for the input and output data of definitions in "sdfAction"		semantics for the input and output data of definitions in sdfAction
	groups. Again, data definitions for payloads of protocol messages,		groups. Again, data definitions for payloads of protocol messages,
	and detailed protocol settings for invoking the action, are expected		and detailed protocol settings for invoking the action, are expected
	to be part of the protocol binding.		to be part of the protocol binding.
	2.2.4. sdfEvent		2.2.4. sdfEvent
	The "sdfEvent" group contains declarations of Events, which can model		The sdfEvent group contains declarations of Events, which can model
	affordances that inform about "happenings" associated with an		affordances that inform about "happenings" associated with an
	instance of an Object; these may result in a signal being stored or		instance of an Object; these may result in a signal being stored or
	emitted as a result.		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		supported in various implementations of sdfEvent that do distinguish
	distinguish sdfEvent from sdfProperty. For instance, while a state		sdfEvent from sdfProperty. For instance, while a state change may
	change may simply be superseded by another state change, some events		simply be superseded by another state change, some events are
	are "precious" and need to be preserved even if further events		"precious" and need to be preserved even if further events follow.
	follow.
	The current version of SDF only provides data constraint modeling and		The current version of SDF only provides data constraint modeling and
	semantics for the output data of Event affordances. Again, data		semantics for the output data of Event affordances. Again, data
	definitions for payloads of protocol messages, and detailed protocol		definitions for payloads of protocol messages, and detailed protocol
	settings for invoking the action, are expected to be part of the		settings for invoking the action, are expected to be part of the
	protocol binding.		protocol binding.
	2.2.5. sdfData		2.2.5. sdfData
	Definitions in "sdfData" groups are provided separately from those in		Definitions in sdfData groups are provided separately from those in
	"sdfProperty" groups to enable common modeling patterns, data		sdfProperty groups to enable common modeling patterns, data
	constraints, and semantic anchor concepts to be factored out for data		constraints, and semantic anchor concepts to be factored out for data
	items that make up "sdfProperty" items and serve as input and output		items that make up sdfProperty items and serve as input and output
	data for "sdfAction" and "sdfEvent" items.		data for sdfAction and sdfEvent items.
	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"		sdfAction or output data provided by an sdfEvent. sdfData definitions
	definitions also enable factoring out extended application data types		also enable factoring out extended application data types such as
	such as mode and machine state enumerations to be reused across		mode and machine state enumerations to be reused across multiple
	multiple definitions that have similar basic characteristics and		definitions that have similar basic characteristics and requirements.
	requirements.
	2.2.6. sdfThing		2.2.6. sdfThing
	Back at the top level, the "sdfThing" groups enables definition of		Back at the top level, the sdfThing groups 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.		definitions.
	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 from: other definitions in "sdfThing"		definitions it is composed from: other definitions in sdfThing groups
	groups definitions in "sdfObject" groups.		definitions in sdfObject groups.
	2.2.7. sdfProduct		2.2.7. sdfProduct
	"sdfThing" has a derived class "sdfProduct", which can be used to		sdfThing has a derived class sdfProduct, which can be used to
	indicate a top level inventory item with a Stock-Keeping Unit (SKU)		indicate a top level inventory item with a Stock-Keeping Unit (SKU)
	identifier and other particular metadata. Structurally, there is no		identifier and other particular metadata. Structurally, there is no
	difference between definitions in either group; semantically, a		difference between definitions in either group; semantically, a
	definition in an "sdfProduct" group is intended to describe a class		definition in an sdfProduct group is intended to describe a class of
	of complete Things.		complete Things.
	3. SDF structure		3. SDF structure
	SDF definitions are contained in SDF files. One or more SDF files		SDF definitions are contained in SDF files. One or more SDF files
	can work together to provide the definitions and declarations that		can work together to provide the definitions and declarations that
	are the payload of the SDF format.		are the payload of the SDF format.
	A SDF definition file contains a single JSON map (JSON object). This		A SDF definition file contains a single JSON map (JSON object). This
	object has three sections: the information block, the namespaces		object has three sections: the information block, the namespaces
	section, and the definitions section.		section, and the definitions section.
	skipping to change at page 12, line 47 ¶		skipping to change at page 13, line 47 ¶
	| license | string | yes | Link to text or embedded text |		| license | string | yes | Link to text or embedded text |
	| | | | containing license terms |		| | | | containing license terms |
	+-----------+--------+----------+---------------------------------+		+-----------+--------+----------+---------------------------------+
	Table 1: Qualities of the Information Block		Table 1: Qualities of the Information Block
	While the format of the version string is marked as TBD, it is		While the format of the version string is marked as TBD, it is
	intended to be lexicographically increasing over the life of a model:		intended to be lexicographically increasing over the life of a model:
	a newer model always has a version string that string-compares higher		a newer model always has a version string that string-compares higher
	than all previous versions. This is easily achieved by following the		than 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 an [RFC3339] date-time or, if
	new versions are generated less frequently than once a day, just the		new versions are generated less frequently than once a day, just the
	"full-date" (i.e., YYYY-MM-DD); in many cases, that will be all that		full-date (i.e., YYYY-MM-DD); in many cases, that will be all that is
	is needed (see Figure 1 for an example).		needed (see Figure 1 for an example).
	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. (For models to be handled by the One Data Model		license identifier. (For models to be handled by the One Data Model
	liaison group, this will typically be "BSD-3-Clause".)		liaison group, this will typically be "BSD-3-Clause".)
	3.2. Namespaces section		3.2. Namespaces section
	The namespaces section contains the namespace map and the		The namespaces section contains the namespace map and the
	defaultNamespace setting.		defaultNamespace setting.
	skipping to change at page 13, line 40 ¶		skipping to change at page 14, line 40 ¶
	+------------------+--------+----------+-----------------------+		+------------------+--------+----------+-----------------------+
	| defaultNamespace | string | no | Identifies one of the |		| defaultNamespace | string | no | Identifies one of the |
	| | | | prefixes in the |		| | | | prefixes in the |
	| | | | namespace map to be |		| | | | namespace map to be |
	| | | | used as a default in |		| | | | used as a default in |
	| | | | resolving identifiers |		| | | | resolving identifiers |
	+------------------+--------+----------+-----------------------+		+------------------+--------+----------+-----------------------+
	Table 2: Namespaces Section		Table 2: Namespaces Section
	The following example declares a set of namespaces and defines "cap"		The following example declares a set of namespaces and defines cap as
	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",
	If no defaultNamespace setting is given, the SDF definition file does		If no defaultNamespace setting is given, the SDF definition file does
	skipping to change at page 14, line 47 ¶		skipping to change at page 15, line 47 ¶
	"bar": {		"bar": {
	"type": "boolean"		"type": "boolean"
	}		}
	}		}
	}		}
	}		}
	Figure 3: Example Object definition		Figure 3: Example Object definition
	This example defines an Object "foo" that is defined in the default		This example defines an Object "foo" that is defined in the default
	namespace (full address: "#/sdfObject/foo"), containing a property		namespace (full address: #/sdfObject/foo), containing a property that
	that can be addressed as "#/sdfObject/foo/sdfProperty/bar", with data		can be addressed as #/sdfObject/foo/sdfProperty/bar, with data of
	of type boolean.		type boolean.
	Some of the definitions are also declarations: the definition of the		Some of the definitions are also declarations: the definition of the
	entry "bar" in the property "foo" means that each instance of a "foo"		entry "bar" in the property "foo" means that each instance of a "foo"
	can have zero or one instance of a "bar". Entries within		can have zero or one instance of a "bar". Entries within
	"sdfProperty", "sdfAction", and "sdfEvent", within "sdfObject"		sdfProperty, sdfAction, and sdfEvent, within sdfObject entries, are
	entries, are declarations. Similarly, entries within an "sdfThing"		declarations. Similarly, entries within an sdfThing describe
	describe instances of "sdfObject" (or nested "sdfThing") that form		instances of sdfObject (or nested sdfThing) that form part of
	part of instances of the Thing.		instances of the Thing.
	4. Names and namespaces		4. Names and namespaces
	SDF definition files may contribute to a global namespace, and may		SDF definition files may contribute to a global namespace, and may
	reference elements from that global namespace. (An SDF definition		reference elements from that global namespace. (An SDF definition
	file that does not set a defaultNamespace does not contribute to a		file that does not set a defaultNamespace does not contribute to a
	global namespace.)		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 versions of SDF might find a use for		(However, as future versions 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.)		that this may become possible in the future.)
	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
	[RFC3986], with a scheme of "https" and a path ("hier-part" in		[RFC3986], with a scheme of "https" and a path (hier-part in
	[RFC3986]). For the present version of this specification, the query		[RFC3986]). For the present version of this specification, the query
	part should not be used (it might be used in later versions).		part should not be used (it might be used in later versions).
	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
	definition file is constructed from a JSON pointer that selects the		definition file is constructed from a JSON pointer that selects the
	element defined for this name in the SDF definition file.		element defined for this name in the SDF definition file.
	skipping to change at page 16, line 11 ¶		skipping to change at page 17, line 11 ¶
	contributed:		contributed:
	* https://example.com/capability/cap#/sdfObject/Switch		* https://example.com/capability/cap#/sdfObject/Switch
	* https://example.com/capability/cap#/sdfObject/Switch/sdfProperty/		* https://example.com/capability/cap#/sdfObject/Switch/sdfProperty/
	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		Note the #, which separates the absolute-URI part (Section 4.3 of
	[RFC3986]) from the fragment identifier part.		[RFC3986]) from the fragment identifier part.
	4.3. Referencing global names		4.3. Referencing global names
	A name reference takes the form of the production "curie" in		A name reference takes the form of the production curie in
	[W3C.NOTE-curie-20101216] (note that this excludes the production		[W3C.NOTE-curie-20101216] (note that this excludes the production
	"safe-curie"), but also limiting the IRIs involved in that production		safe-curie), but also limiting the IRIs involved in that production
	to URIs as per [RFC3986] and the prefixes to ASCII characters		to URIs as per [RFC3986] and the prefixes to ASCII characters
	[RFC0020].		[RFC0020].
	A name that is contributed by the current SDF definition file can be		A name that is contributed by the current SDF definition file can be
	referenced by a Same-Document Reference as per section 4.4 of		referenced by a Same-Document Reference as per section 4.4 of
	[RFC3986]. As there is little point in referencing the entire SDF		[RFC3986]. As there is little point in referencing the entire SDF
	definition file, this will be a "#" followed by a JSON pointer. This		definition file, this will be a # followed by a JSON pointer. This
	is the only kind of name reference to itself that is possible in an		is the only kind of name reference to itself that is possible in an
	SDF definition file that does not set a default namespace.		SDF definition file that does not set a default namespace.
	Name references that point outside the current SDF definition file		Name references that point outside the current SDF definition file
	need to contain curie prefixes. These then reference namespace		need to contain curie prefixes. These then reference namespace
	declarations in the namespaces section.		declarations in the namespaces section.
	For example, if a namespace prefix is defined:		For example, if a namespace prefix is defined:
	"namespace": {		"namespace": {
	skipping to change at page 19, line 28 ¶		skipping to change at page 20, line 28 ¶
	"currentTemperature": {		"currentTemperature": {
	"sdfRef": "#/sdfObject/temperatureWithAlarm/sdfData/temperatureData"		"sdfRef": "#/sdfObject/temperatureWithAlarm/sdfData/temperatureData"
	}		}
	},		},
	"sdfEvent": {		"sdfEvent": {
	"overTemperatureEvent": {		"overTemperatureEvent": {
	"sdfOutputData": {		"sdfOutputData": {
	"type": "object",		"type": "object",
	"properties": {		"properties": {
	"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"
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	skipping to change at page 19, line 50 ¶		skipping to change at page 20, line 50 ¶
	}		}
	Figure 4: Using sdfRequired		Figure 4: Using sdfRequired
	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 label is required for an application and no label is		absent. If a label is required for an application and no label is
	given in the SDF model, the last part ("reference-token", Section 3		given in the SDF model, the last part (reference-token, Section 3 of
	of [RFC6901]) of the JSON pointer to the definition can be used.		[RFC6901]) of the JSON pointer to the definition can be used.
	+=============+==============+===================================+		+=============+==============+===================================+
	| Quality | Type | Description |		| Quality | Type | Description |
	+=============+==============+===================================+		+=============+==============+===================================+
	| description | text | long text (no constraints) |		| description | text | long text (no constraints) |
	+-------------+--------------+-----------------------------------+		+-------------+--------------+-----------------------------------+
	| label | text | short text (no constraints) |		| label | text | short text (no constraints) |
	+-------------+--------------+-----------------------------------+		+-------------+--------------+-----------------------------------+
	| $comment | text | source code comments only, no |		| $comment | text | source code comments only, no |
	| | | semantics |		| | | semantics |
	skipping to change at page 20, line 25 ¶		skipping to change at page 21, line 25 ¶
	| sdfRef | sdf-pointer | (see Section 4.4) |		| sdfRef | sdf-pointer | (see Section 4.4) |
	+-------------+--------------+-----------------------------------+		+-------------+--------------+-----------------------------------+
	| sdfRequired | pointer-list | (see Section 4.5, applies to |		| sdfRequired | pointer-list | (see Section 4.5, applies to |
	| | | qualities of properties, of data) |		| | | qualities of properties, of data) |
	+-------------+--------------+-----------------------------------+		+-------------+--------------+-----------------------------------+
	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,		Data qualities are used in sdfData and sdfProperty definitions, which
	which are named sets of data qualities (abbreviated as "named-sdq").		are named sets of data qualities (abbreviated as named-sdq).
	Table 4 lists data qualities borrowed from		Appendix C lists data qualities inspired by the various proposals at
	[I-D.handrews-json-schema-validation]; the intention is that these		json-schema.org; the intention is that these (information model
	qualities retain their semantics from the versions of the json-		level) qualities are compatible with the (data model) semantics from
	schema.org proposal they were imported from. A description that		the versions of the json-schema.org proposal they were imported from.
	starts with a parenthesized term means the quality is only applicable
	when "type" has the value of the term.
	Table 5 lists data qualities defined specifically for the present		Table 4 lists data qualities defined specifically for the present
	specification.		specification.
	The term "allowed types" stands for primitive JSON types, JSON maps		+===============+================+======================+=========+
	("objects")" as well as homogeneous arrays of numbers, text,		| Quality | Type | Description | Default |
	Booleans, or maps. (This list might be extended in a future version		+===============+================+======================+=========+
	of SDF.) An "allowed value" is a value allowed for one of these		| (common) | | Section 4.6 | |
	types.		+---------------+----------------+----------------------+---------+
			| unit | string | unit name (note 1) | N/A |
	+================+==========+=======================================+		+---------------+----------------+----------------------+---------+
	|Quality |Type |Description |		| scaleMinimum | number | lower limit of value | N/A |
	+================+==========+=======================================+		| | | in units given by | |
	|type |"number" /|JSON data type (note 1) |		| | | unit (note 2) | |
	| |"string" /| |		+---------------+----------------+----------------------+---------+
	| |"boolean" | |		| scaleMaximum | number | upper limit of value | N/A |
	| |/ | |		| | | in units given by | |
	| |"integer" | |		| | | unit (note 2) | |
	| |/ "array" | |		+---------------+----------------+----------------------+---------+
	| |/ "object"| |		| readable | boolean | Reads are allowed | true |
	+----------------+----------+---------------------------------------+		+---------------+----------------+----------------------+---------+
	|const |allowed |specifies a constant value for a data |		| writable | boolean | Writes are allowed | true |
	| |value |item or property |		+---------------+----------------+----------------------+---------+
	+----------------+----------+---------------------------------------+		| observable | boolean | flag to indicate | true |
	|default |allowed |specifies the default value for |		| | | asynchronous | |
	| |value |initialization |		| | | notification is | |
	+----------------+----------+---------------------------------------+		| | | available | |
	|minimum |number |(number) lower limit of value |		+---------------+----------------+----------------------+---------+
	+----------------+----------+---------------------------------------+		| nullable | boolean | indicates a null | true |
	|maximum |number |(number) upper limit of value |		| | | value is available | |
	+----------------+----------+---------------------------------------+		| | | for this type | |
	|exclusiveMinimum|number or |(number) lower limit of value |		+---------------+----------------+----------------------+---------+
	| |boolean | |		| contentFormat | string | content type (IANA | N/A |
	| |(jso draft| |		| | | media type string | |
	| |7/4) | |		| | | plus parameters), | |
	+----------------+----------+---------------------------------------+		| | | encoding | |
	|exclusiveMaximum|number or |(number) lower limit of value |		+---------------+----------------+----------------------+---------+
	| |boolean | |		| sdfType | string | sdfType enumeration | N/A |
	| |(jso draft| |		| | (Section | (extensible) | |
	| |7/4) | |		| | 4.7.1) | | |
	+----------------+----------+---------------------------------------+		+---------------+----------------+----------------------+---------+
	|multipleOf |number |(number) resolution of the number |		| sdfChoice | named set of | named alternatives | N/A |
	| | |[NEEDED?] |		| | data qualities | | |
	+----------------+----------+---------------------------------------+		| | (Section | | |
	|minLength |integer |(string) shortest length string in |		| | 4.7.2) | | |
	| | |octets |		+---------------+----------------+----------------------+---------+
	+----------------+----------+---------------------------------------+		| enum | array of | abbreviation for | N/A |
	|maxLength |integer |(string) longest length string in |		| | strings | string-valued named | |
	| | |octets |		| | | alternatives | |
	+----------------+----------+---------------------------------------+		+---------------+----------------+----------------------+---------+
	|pattern |string |(string) regular expression to |
	| | |constrain a string pattern |
	+----------------+----------+---------------------------------------+
	|format |"date- |(string) JSON Schema formats as per |
	| |time" / |[I-D.handrews-json-schema-validation], |
	| |"date" / |Section 7.3 |
	| |"time" / | |
	| |"uri" / | |
	| |"uri- | |
	| |reference"| |
	| |/ "uuid" | |
	+----------------+----------+---------------------------------------+
	|minItems |number |(array) Minimum number of items in |
	| | |array |
	+----------------+----------+---------------------------------------+
	|maxItems |number |(array) Maximum number of items in |
	| | |array |
	+----------------+----------+---------------------------------------+
	|uniqueItems |boolean |(array) if true, requires items to be |
	| | |all different |
	+----------------+----------+---------------------------------------+
	|items |(subset of|(array) constraints on array items |
	| |common/ | |
	| |data | |
	| |qualities;| |
	| |see | |
	| |Appendix A| |
	+----------------+----------+---------------------------------------+
	|required |array of |(object) names of properties (note 2) |
	| |strings |that are required in the JSON map |
	| | |("object") |
	+----------------+----------+---------------------------------------+
	|properties |named set |(object) entries allowed for the JSON |
	| |of data |map ("object") |
	| |qualities | |
	+----------------+----------+---------------------------------------+
	Table 4: Qualities of sdfProperty and sdfData borrowed from json-
	schema.org
	(1) A type value of "integer" means that only integral values of JSON
	numbers can be used.
	(2) Note that the term "properties" as used for map entries in
	[I-D.handrews-json-schema-validation] is unrelated to sdfProperty.
	+===============+===========+===========================+=========+
	| Quality | Type | Description | Default |
	+===============+===========+===========================+=========+
	| (common) | | Section 4.6 | |
	+---------------+-----------+---------------------------+---------+
	| unit | string | SenML unit name as per | N/A |
	| | | [IANA.senml], subregistry | |
	| | | SenML Units (note 3) | |
	+---------------+-----------+---------------------------+---------+
	| scaleMinimum | number | lower limit of value in | N/A |
	| | | units given by unit (note | |
	| | | 4) | |
	+---------------+-----------+---------------------------+---------+
	| scaleMaximum | number | upper limit of value in | N/A |
	| | | units given by unit (note | |
	| | | 4) | |
	+---------------+-----------+---------------------------+---------+
	| readable | boolean | Reads are allowed | true |
	+---------------+-----------+---------------------------+---------+
	| writable | boolean | Writes are allowed | true |
	+---------------+-----------+---------------------------+---------+
	| observable | boolean | flag to indicate | true |
	| | | asynchronous notification | |
	| | | is available | |
	+---------------+-----------+---------------------------+---------+
	| nullable | boolean | indicates a null value is | true |
	| | | available for this type | |
	+---------------+-----------+---------------------------+---------+
	| contentFormat | string | content type (IANA media | N/A |
	| | | type string plus | |
	| | | parameters), encoding | |
	+---------------+-----------+---------------------------+---------+
	| sdfType | string | sdfType enumeration | N/A |
	| | (Section | (extensible) | |
	| | 4.7.1) | | |
	+---------------+-----------+---------------------------+---------+
	| sdfChoice | named set | named alternatives | N/A |
	| | of data | | |
	| | qualities | | |
	+---------------+-----------+---------------------------+---------+
	| enum | array of | abbreviation for string- | N/A |
	| | strings | valued named alternatives | |
	+---------------+-----------+---------------------------+---------+
	Table 5: SDF-defined Qualities of sdfProperty and sdfData		Table 4: SDF-defined Qualities of sdfProperty and sdfData
	(3) note that the quality "unit" was called "units" in SDF 1.0.		1. Note that the quality unit was called units in SDF 1.0. The unit
			name SHOULD be as per the SenML Units Registry or the Secondary
			Units Registry in [IANA.senml] as specified by Sections 4.5.1 and
			12.1 of [RFC8428] and Section 3 of [RFC8798], respectively.
			Exceptionally, if a registration in these registries cannot be
			obtained or would be inappropriate, the unit name can also be a
			URI that is pointing to a definition of the unit. Note that SDF
			processors are not expected to (and normally SHOULD NOT)
			dereference these URIs; they may be useful to humans, though. A
			URI unit name is distinguished from a registered unit name by the
			presence of a colon; registered unit names that contain a colon
			(at the time of writing, none) can therefore not be used in SDF.
	(4) these qualities were included in SDF 1.0, but were not fully		2. these qualities were included in SDF 1.0, but were not fully
	defined; they are not included in SDF 1.1. In 1.next, they will be		defined; they are not included in SDF 1.1. In 1.next, they will
	replaced by qualities to express scaling that are more aligned with		be replaced by qualities to express scaling that are more aligned
	the processes that combine ecosystem and instance specific		with the processes that combine ecosystem and instance specific
	information with an SDF model.		information with an SDF model.
	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
	[I-D.handrews-json-schema-validation]. These types are identified by		JSO. These types are identified by the sdfType quality, which is a
	the "sdfType" quality, which is a text string from a set of type		text string from a set of type names defined by SDF.
	names defined by SDF.
	To aid interworking with [I-D.handrews-json-schema-validation]		To aid interworking with [I-D.handrews-json-schema-validation]
	implementations, it is RECOMMENDED that "sdfType" is always used in		implementations, it is RECOMMENDED that sdfType is always used in
	conjunction with the "type" quality inherited from		conjunction with the type quality inherited from
	[I-D.handrews-json-schema-validation], in such a way as to yield a		[I-D.handrews-json-schema-validation], in such a way as to yield a
	common representation of the type's values in JSON.		common representation of the type's values in JSON.
	Values for "sdfType" that are defined in SDF 1.1 are shown in		Values for sdfType that are defined in SDF 1.1 are shown in Table 5.
	Table 6. This table also gives a description of the semantics of the		This table also gives a description of the semantics of the sdfType,
	sdfType, the conventional value for "type" to be used with the		the conventional value for type to be used with the sdfType value,
	"sdfType" value, and a conventional JSON representation for values of		and a conventional JSON representation for values of the type.
	the type.
	+=============+=============+========+==========================+		+=============+=============+========+==========================+
	| sdfType | Description | type | JSON Representation |		| sdfType | Description | type | JSON Representation |
	+=============+=============+========+==========================+		+=============+=============+========+==========================+
	| byte-string | A sequence | string | base64url without |		| byte-string | A sequence | string | base64url without |
	| | of zero or | | padding (Section 3.4.5.2 |		| | of zero or | | padding (Section 3.4.5.2 |
	| | more bytes | | of [RFC8949]) |		| | more bytes | | of [RFC8949]) |
	+-------------+-------------+--------+--------------------------+		+-------------+-------------+--------+--------------------------+
	| unix-time | A point in | number | POSIX time |		| unix-time | A point in | number | POSIX time |
	| | civil time | | (Section 3.4.2 of |		| | civil time | | (Section 3.4.2 of |
	| | (note 1) | | [RFC8949]) |		| | (note 1) | | [RFC8949]) |
	+-------------+-------------+--------+--------------------------+		+-------------+-------------+--------+--------------------------+
	Table 6: Values defined in SDF 1.1 for sdfType quality		Table 5: Values defined in SDF 1.1 for 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 future		More date/time-related sdfTypes are likely to be added in future
	versions of this specification.		versions of this specification.
	In SDF 1.0, a similar concept was called "subtype".		In SDF 1.0, a similar concept was called subtype.
	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 JSON object		alternative is identified by a name (string, key in the JSON object
	used to represent the choice) and a set of dataqualities (object, the		used to represent the choice) and a set of dataqualities (object, the
	value in the JSON object used to represent the choice).		value in the JSON object used to represent the choice).
	sdfChoice merges the functions of two constructs found in		sdfChoice merges the functions of two constructs found in
	[I-D.handrews-json-schema-validation]:		[I-D.handrews-json-schema-validation]:
	* "enum"		* enum
	What would have been		What would have been
	"enum": ["foo", "bar", "baz"]		"enum": ["foo", "bar", "baz"]
	in SDF 1.0, is often best represented as:		in SDF 1.0, is often best represented as:
	"sdfChoice": {		"sdfChoice": {
	"foo": { "description": "This is a foonly"},		"foo": { "description": "This is a foonly"},
	"bar": { "description": "As defined in the second world congress"},		"bar": { "description": "As defined in the second world congress"},
	"baz": { "description": "From zigbee foobaz"}		"baz": { "description": "From zigbee 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 text string,
	e.g. what would have been		e.g. what would have been
	"type": "number",		"type": "number",
	"enum": [1, 2, 3]		"enum": [1, 2, 3]
	in SDF 1.0, is represented as:		in SDF 1.0, 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 },
	"the-third-alternative": { "const": 3 }		"the-third-alternative": { "const": 3 }
	}		}
	where the string names obviously would be chosen in a way that is		where the string names obviously would be chosen in a way that is
	descriptive for what these numbers actually stand for; sdfChoice		descriptive for what these numbers actually stand for; sdfChoice
	also makes it easy to add number ranges into the mix.		also makes it easy to add number ranges into the mix.
	(Note that "const" can also be used for strings as in the previous		(Note that const can also be used for strings as in the previous
	example, e.g., if the actual string value is indeed a crucial		example, e.g., if the actual string value is indeed a crucial
	element for the data model.)		element for the data model.)
	* anyOf		* anyOf
	[I-D.handrews-json-schema-validation] provides a type union called		[I-D.handrews-json-schema-validation] provides a type union called
	"anyOf", which provides a choice between anonymous alternatives.		anyOf, which provides a choice between anonymous alternatives.
	What could have been		What could have been
	"anyOf": [		"anyOf": [
	{"type": "array", "minItems": 3, "maxItems": "3", "items": {		{"type": "array", "minItems": 3, "maxItems": "3", "items": {
	"sdfRef": "rgbVal"}}		"sdfRef": "#/sdfData/rgbVal"}}
	{"type": "array", "minItems": 4, "maxItems": "4", "items": {		{"type": "array", "minItems": 4, "maxItems": "4", "items": {
	"sdfRef": "cmykVal"}}		"sdfRef": "#/sdfData/cmykVal"}}
	]		]
	in [I-D.handrews-json-schema-validation] can be more descriptively		in [I-D.handrews-json-schema-validation] can be more descriptively
	notated in SDF as:		notated in SDF as:
	"sdfChoice": {		"sdfChoice": {
	"rgb": {"type": "array", "minItems": 3, "maxItems": "3", "items": {		"rgb": {"type": "array", "minItems": 3, "maxItems": "3", "items": {
	"sdfRef": "rgbVal"}},		"sdfRef": "#/sdfData/rgbVal"}},
	"cmyk": {"type": "array", "minItems": 4, "maxItems": "4", "items": {		"cmyk": {"type": "array", "minItems": 4, "maxItems": "4", "items": {
	"sdfRef": "cmykVal"}}		"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		allOf or the peculiar type-xor construct oneOf found in
	[I-D.handrews-json-schema-validation].		[I-D.handrews-json-schema-validation].
	As a simplification for readers of SDF specifications accustomed to		As a simplification for readers of SDF specifications accustomed to
	the [I-D.handrews-json-schema-validation] enum keyword, this is		the [I-D.handrews-json-schema-validation] enum keyword, this is
	retained, but limited to a choice of text string values, such that		retained, but limited to a choice of text string values, such that
	"enum": ["foo", "bar", "baz"]		"enum": ["foo", "bar", "baz"]
	is syntactic sugar for		is syntactic sugar for
	skipping to change at page 27, line 19 ¶		skipping to change at page 26, line 19 ¶
	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 Object		The sdfObject keyword denotes a group of zero or more Object
	definitions. Object definitions may contain or include definitions		definitions. Object definitions may contain or include definitions
	of Properties, Actions, Events declared for the object, as well as		of Properties, Actions, Events declared for the object, as well as
	data types (sdfData group) to be used in this or other Objects.		data types (sdfData group) to be used in this or other Objects.
	The qualities of an sdfObject include the common qualities,		The qualities of an sdfObject include the common qualities,
	additional qualities are shown in Table 7. 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 object |		| | | definitions for this object |
	skipping to change at page 27, line 50 ¶		skipping to change at page 26, line 50 ¶
	+-------------+-----------+-----------------------------+		+-------------+-----------+-----------------------------+
	| minItems | number | (array) Minimum number of |		| minItems | number | (array) Minimum number of |
	| | | sdfObject instances in |		| | | sdfObject instances in |
	| | | array |		| | | array |
	+-------------+-----------+-----------------------------+		+-------------+-----------+-----------------------------+
	| maxItems | number | (array) Maximum number of |		| maxItems | number | (array) Maximum number of |
	| | | sdfObject instances in |		| | | sdfObject instances in |
	| | | array |		| | | array |
	+-------------+-----------+-----------------------------+		+-------------+-----------+-----------------------------+
	Table 7: 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.		(and thus the common qualities), see Section 4.7.
	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 which are invoked.
	Actions have parameter data that are supplied upon invocation.		Actions have parameter data that are supplied upon invocation.
	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 7.
	+===============+===========+============================+		+===============+===========+============================+
	| 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 7: 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 which 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 8.
	+===============+===========+============================+		+===============+===========+============================+
	| 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 8: Qualities of sdfEvent
	"sdfOutputData" defines the output data of the action. As discussed		sdfOutputData defines the output data of the action. As discussed in
	in Section 2.2.4, a set of data qualities with type "object" can be		Section 2.2.4, a set of data qualities with type "object" can be used
	used to substructure the output data item, with optionality indicated		to substructure the output data item, with optionality indicated by
	by the data quality "required".		the data quality required.
	5.5. sdfData		5.5. sdfData
	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.
	It is not itself a declaration, i.e., it does not cause any of these		It is not itself a declaration, i.e., it does not cause any of these
	data items to be included in an affordance definition.		data items to be included in an affordance definition.
	skipping to change at page 30, line 38 ¶		skipping to change at page 29, line 38 ¶
	in the definition files that are present in the namespace. For		in the definition files that are present in the namespace. For
	example, definitions that originate from an organization or vendor		example, definitions that originate from an organization or vendor
	are expected to be in a namespace that is specific to that		are expected to be in a namespace that is specific to that
	organization or vendor. There is expected to be an SDF namespace for		organization or vendor. There is expected to be an SDF namespace for
	common SDF definitions used in OneDM.		common SDF definitions used in OneDM.
	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 files in that namespace. For		Pointers to the definitions in the files in that namespace. For
	example, if there is a file defining an object "Switch" with an		example, if there is a file defining an object "Switch" with an
	action "on", then the reference to the action would be		action "on", then the reference to the action would be
	"ns:/sdfObject/Switch/sdfAction/on" where "ns" is the namespace		"ns:/sdfObject/Switch/sdfAction/on" where ns is the namespace prefix
	prefix (short name for the namespace).		(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 file or another file) to become part of a new		(could be in the same file or another file) to become part of a new
	definition by including a reference to the existing definition within		definition by including a reference to the existing definition within
	the model namespace.		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 re-use 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 will use the keyword "sdfRef" as a quality		definition. This pattern will use the keyword "sdfRef" as a quality
	of a new definition with a value consisting of a reference to the		of a new definition with a value consisting of a reference to the
	existing definition that is to be used as a template.		existing 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 (objects) do not have a defined order, so the		(Note that JSON maps (objects) do not have a defined order, so the
	SDF processor may see these overrides before seeing the "sdfRef".)		SDF processor may see these overrides before seeing the sdfRef.)
	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 set of data values, as shown in Figure 5: any value		restricting the set of data values, as shown in Figure 5: any value
	for a "cable-length" also is a valid value for a "length", with the		for a cable-length also is a valid value for a length, with the
	additional restriction that the length cannot be smaller than 5 cm.		additional restriction that the length cannot be smaller than 5 cm.
	(This is labeled as a convention as it cannot be checked in the		(This is labeled as a convention as it cannot be checked in the
	general case; a quality of implementation consideration for a tool		general case; a quality of implementation consideration for a tool
	might be to provide at least some form of checking.) Note that a		might be to provide at least some form of checking.) Note that a
	description is provided that overrides the description of the		description is provided that overrides the description of the
	referenced definition; as this quality is intended for human		referenced definition; as this quality is intended for human
	consumption there is no conflict with the intended goal.		consumption there is no conflict with the intended goal.
	"sdfData":		"sdfData":
	"length" : {		"length" : {
	skipping to change at page 32, line 20 ¶		skipping to change at page 31, line 20 ¶
	encapsulated in an sdfThing, and the socket-thing itself could be		encapsulated in an sdfThing, and the socket-thing itself could be
	used in a declaration in the sdfThing definition for the outlet		used in a declaration in the sdfThing definition for the outlet
	strip.		strip.
	sdfThing definitions carry semantic meaning, such as a defined		sdfThing definitions carry semantic meaning, such as a defined
	refrigerator compartment and a defined freezer compartment, making up		refrigerator compartment and a defined freezer compartment, making up
	a combination refrigerator-freezer product.		a combination refrigerator-freezer product.
	An sdfThing may be composed of sdfObjects and other sdfThings.		An sdfThing may be composed of sdfObjects and other sdfThings.
	The qualities of sdfThing are shown in Table 10.		The qualities of sdfThing are shown in Table 9.
	+===========+========+=============+		+===========+========+=============+
	| Quality | Type | Description |		| Quality | Type | Description |
	+===========+========+=============+		+===========+========+=============+
	| (common) | | Section 4.6 |		| (common) | | Section 4.6 |
	+-----------+--------+-------------+		+-----------+--------+-------------+
	| sdfThing | thing | |		| sdfThing | thing | |
	+-----------+--------+-------------+		+-----------+--------+-------------+
	| sdfObject | object | |		| sdfObject | object | |
	+-----------+--------+-------------+		+-----------+--------+-------------+
	Table 10: Qualities of sdfThing		Table 9: Qualities of sdfThing
	and sdfProduct		and sdfProduct
	6.4. sdfProduct		6.4. sdfProduct
	An sdfProduct provides the level of abstraction for representing a		An sdfProduct provides the level of abstraction for representing a
	unique product or a profile for a standardized type of product, for		unique product or a profile for a standardized type of product, for
	example a "device type" definition with required minimum		example a "device type" definition with required minimum
	functionality.		functionality.
	Products may be composed of Objects and Things at the high level, and		Products may be composed of Objects and Things at the high level, and
	may include their own definitions of Properties, Actions, and Events		may include their own definitions of Properties, Actions, and Events
	that can be used to extend or complete the included Object		that can be used to extend or complete the included Object
	definitions.		definitions.
	Product definitions may set optional defaults and constant values for		Product definitions may set optional defaults and constant values for
	specific use cases, for example units, range, and scale settings for		specific use cases, for example units, range, and scale settings for
	properties, or available parameters for Actions.		properties, or available parameters for Actions.
	The qualities of sdfProduct are the same as for sdfThing and are		The qualities of sdfProduct are the same as for sdfThing and are
	shown in Table 10.		shown in Table 9.
	7. IANA Considerations		7. IANA Considerations
	7.1. Media Type		7.1. Media Type
	IANA is requested to add the following Media-Type to the "Media		IANA is requested to add the following Media-Type to the "Media
	Types" registry.		Types" registry.
	+==========+======================+=======================+		+==========+======================+=======================+
	| Name | Template | Reference |		| Name | Template | Reference |
	+==========+======================+=======================+		+==========+======================+=======================+
	| sdf+json | application/sdf+json | RFC XXXX, Section 7.1 |		| sdf+json | application/sdf+json | RFC XXXX, Section 7.1 |
	+----------+----------------------+-----------------------+		+----------+----------------------+-----------------------+
	Table 11		Table 10
	// RFC Ed.: please replace RFC XXXX with this RFC number and remove		// RFC Ed.: please replace RFC XXXX with this RFC number and remove
	this note.		this note.
	Type name: application		Type name: application
	Subtype name: sdf+json		Subtype name: sdf+json
	Required parameters: none		Required parameters: none
	Optional parameters: none		Optional parameters: none
	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 XXXX
	skipping to change at page 34, line 9 ¶		skipping to change at page 33, line 9 ¶
	8. Security Considerations		8. Security Considerations
	Some wider issues are discussed in [RFC8576].		Some wider issues are discussed in [RFC8576].
	(Specifics: TBD.)		(Specifics: TBD.)
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.handrews-json-schema-validation]
	Wright, A., Andrews, H., and B. Hutton, "JSON Schema
	Validation: A Vocabulary for Structural Validation of
	JSON", Work in Progress, Internet-Draft, draft-handrews-
	json-schema-validation-02, 17 September 2019,
	<https://www.ietf.org/archive/id/draft-handrews-json-
	schema-validation-02.txt>.
	[I-D.ietf-cbor-cddl-control]		[I-D.ietf-cbor-cddl-control]
	Bormann, C., "Additional Control Operators for CDDL", Work		Bormann, C., "Additional Control Operators for CDDL", Work
	in Progress, Internet-Draft, draft-ietf-cbor-cddl-control-		in Progress, Internet-Draft, draft-ietf-cbor-cddl-control-
	03, 7 March 2021, <https://www.ietf.org/archive/id/draft-		07, 21 October 2021, <https://www.ietf.org/archive/id/
	ietf-cbor-cddl-control-03.txt>.		draft-ietf-cbor-cddl-control-07.txt>.
	[IANA.senml]		[IANA.senml]
	IANA, "Sensor Measurement Lists (SenML)",		IANA, "Sensor Measurement Lists (SenML)",
	<http://www.iana.org/assignments/senml>.		<https://www.iana.org/assignments/senml>.
	[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,		[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
	RFC 20, DOI 10.17487/RFC0020, October 1969,		RFC 20, DOI 10.17487/RFC0020, October 1969,
	<https://www.rfc-editor.org/info/rfc20>.		<https://www.rfc-editor.org/info/rfc20>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
			Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
			<https://www.rfc-editor.org/info/rfc3339>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
			[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
			Unique IDentifier (UUID) URN Namespace", RFC 4122,
			DOI 10.17487/RFC4122, July 2005,
			<https://www.rfc-editor.org/info/rfc4122>.
	[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/info/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/info/rfc7396>.		<https://www.rfc-editor.org/info/rfc7396>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
			Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
			DOI 10.17487/RFC8428, August 2018,
			<https://www.rfc-editor.org/info/rfc8428>.
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[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/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
			[RFC8798] Bormann, C., "Additional Units for Sensor Measurement
			Lists (SenML)", RFC 8798, DOI 10.17487/RFC8798, June 2020,
			<https://www.rfc-editor.org/info/rfc8798>.
	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC8949] 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>.
	[SPDX] "SPDX License List", <https://spdx.org/licenses/>.		[SPDX] "SPDX License List", <https://spdx.org/licenses/>.
	[W3C.NOTE-curie-20101216]		[W3C.NOTE-curie-20101216]
	Birbeck, M. and S. McCarron, "CURIE Syntax 1.0", World		Birbeck, M. and S. McCarron, "CURIE Syntax 1.0", World
	Wide Web Consortium NOTE NOTE-curie-20101216, 16 December		Wide Web Consortium NOTE NOTE-curie-20101216, 16 December
	2010, <https://www.w3.org/TR/2010/NOTE-curie-20101216>.		2010, <https://www.w3.org/TR/2010/NOTE-curie-20101216>.
	9.2. Informative References		9.2. Informative References
			[ECMA-262] Ecma International, "ECMAScript 2020 Language
			Specification", ECMA Standard ECMA-262, 11th Edition, June
			2020, <https://www.ecma-international.org/wp-
			content/uploads/ECMA-262.pdf>.
			[I-D.bormann-jsonpath-iregexp]
			Bormann, C., "I-Regexp: An Interoperable Regexp Format",
			Work in Progress, Internet-Draft, draft-bormann-jsonpath-
			iregexp-00, 12 May 2021, <https://www.ietf.org/archive/id/
			draft-bormann-jsonpath-iregexp-00.txt>.
			[I-D.handrews-json-schema-validation]
			Wright, A., Andrews, H., and B. Hutton, "JSON Schema
			Validation: A Vocabulary for Structural Validation of
			JSON", Work in Progress, Internet-Draft, draft-handrews-
			json-schema-validation-02, 17 September 2019,
			<https://www.ietf.org/archive/id/draft-handrews-json-
			schema-validation-02.txt>.
	[I-D.irtf-t2trg-rest-iot]		[I-D.irtf-t2trg-rest-iot]
	Keranen, A., Kovatsch, M., and K. Hartke, "RESTful Design		Keranen, A., Kovatsch, M., and K. Hartke, "Guidance on
	for Internet of Things Systems", Work in Progress,		RESTful Design for Internet of Things Systems", Work in
	Internet-Draft, draft-irtf-t2trg-rest-iot-07, 22 February		Progress, Internet-Draft, draft-irtf-t2trg-rest-iot-08, 25
	2021, <https://www.ietf.org/archive/id/draft-irtf-t2trg-		August 2021, <https://www.ietf.org/archive/id/draft-irtf-
	rest-iot-07.txt>.		t2trg-rest-iot-08.txt>.
			[I-D.wright-json-schema]
			Wright, A. and H. Andrews, "JSON Schema: A Media Type for
			Describing JSON Documents", Work in Progress, Internet-
			Draft, draft-wright-json-schema-01, 16 April 2017,
			<https://www.ietf.org/archive/id/draft-wright-json-schema-
			01.txt>.
	[OCF] "OCF Resource Type Specification",		[OCF] "OCF Resource Type Specification",
	<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] "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>.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<https://www.rfc-editor.org/info/rfc3339>.
	[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/info/rfc8576>.		<https://www.rfc-editor.org/info/rfc8576>.
	[ZCL] "The ZigBee Cluster Library", Zigbee Wireless		[ZCL] "The ZigBee Cluster Library", Zigbee Wireless
	Networking pp. 239-271,		Networking pp. 239-271,
	DOI 10.1016/b978-0-7506-8597-9.00006-9, 2008,		DOI 10.1016/b978-0-7506-8597-9.00006-9, 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 appendix describes the syntax of SDF using CDDL [RFC8610]. Note		This appendix describes the syntax of SDF using CDDL [RFC8610]. Note
	that this appendix was derived from Ari Keranen's "alt-schema" and		that this appendix was derived from Ari Keranen's "alt-schema" and
	Michael Koster's "schema", with a view of covering the syntax that is		Michael Koster's "schema", with a view of covering the syntax that is
	currently in use at the One Data Model "playground" repository.		currently in use at the One Data Model playground repository.
	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
	validation syntax, is defined that does not include the extension		validation syntax, is defined that does not include the extension
	points. The validation syntax can be generated from the framework		points. The validation syntax can be generated from the framework
	syntax by leaving out all lines containing the string "EXTENSION-		syntax by leaving out all lines containing the string EXTENSION-
	POINT"; as this is trivial, the result is not shown here.		POINT; as this is trivial, the result is not shown here.
	This appendix makes use of CDDL "features" as defined in Section 4 of		This appendix makes use of CDDL "features" as defined in Section 4 of
	[I-D.ietf-cbor-cddl-control]. A feature named "1.0" is used to		[I-D.ietf-cbor-cddl-control]. A feature named "1.0" is used to
	indicate parts of the syntax being deprecated towards SDF 1.1, and a		indicate parts of the syntax being deprecated towards SDF 1.1, and a
	feature named "1.1" is used to indicate new syntax intended for SDF		feature named "1.1" is used to indicate new syntax intended for SDF
	1.1. Features whose names end in "-ext" indicate extension points		1.1. Features whose names end in "-ext" indicate extension points
	for further evolution.		for further evolution.
	start = sdf-syntax		start = sdf-syntax
	skipping to change at page 40, line 14 ¶		skipping to change at page 40, line 8 ¶
	Appendix B. json-schema.org Rendition of SDF Syntax		Appendix B. json-schema.org Rendition of SDF Syntax
	This appendix describes the syntax of SDF defined in Appendix A, but		This appendix describes the syntax of SDF defined in Appendix A, but
	using a version of the description techniques advertised on json-		using a version of the description techniques advertised on json-
	schema.org [I-D.handrews-json-schema-validation].		schema.org [I-D.handrews-json-schema-validation].
	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, and lines leading with a + are part of the framework syntax.
	syntax.
	{		{
	- "title": "sdf-validation.cddl",		- "title": "sdf-validation.cddl",
	+ "title": "sdf-framework.cddl",		+ "title": "sdf-framework.cddl",
	"$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 78, line 32 ¶		skipping to change at page 78, line 26 ¶
	- "additionalProperties": false		- "additionalProperties": false
	+ "additionalProperties": {		+ "additionalProperties": {
	+ }		+ }
	},		},
	"productqualities": {		"productqualities": {
	"$ref": "#/definitions/thingqualities"		"$ref": "#/definitions/thingqualities"
	}		}
	}		}
	}		}
			Appendix C. Data Qualities inspired by json-schema.org
			Data qualities define data used in SDF affordances at an information
			model level. A popular way to describe JSON data at a data model
			level is proposed by a number of drafts on json-schema.org (which
			collectively are abbreviated JSO here)); for reference to a popular
			version we will point here to [I-D.handrews-json-schema-validation].
			As the vocabulary used by JSO is familiar to many JSON modellers, the
			present specification borrows some of the terms and ports their
			semantics to the information model level needed for SDF.
			The main data quality imported is the "type". In SDF, this can take
			one of six (text string) values, which are discussed in the following
			subsections (note that the JSO type "null" is not supported as a
			value of this data quality in SDF).
			The additional quality "const" restricts the data to one specific
			value (given as the value of the const quality).
			Similarly, the additional quality "default" provides data that can be
			used in the absence of the data (given as the value of the const
			quality); this is mainly documentary and not very well-defined for
			SDF as no process is defined that would add default values to an
			instance of something.
			C.1. type "number", type "integer"
			The types "number" and "integer" are associated with floating point
			and integer numbers, as they are available in JSON. A type value of
			integer means that only integer values of JSON numbers can be used
			(note that 10.0 is an integer value, even if it is in a notation that
			would also allow non-zero decimal fractions).
			The additional data qualities "minimum", "maximum",
			"exclusiveMinimum", "exclusiveMaximum" provide number values that
			serve as inclusive/exclusive lower/upper bounds for the number.
			(Note that the Boolean form of "exclusiveMinimum"/"exclusiveMaximum"
			found in earlier JSO drafts is not used.)
			The data quality "multipleOf" gives a positive number that constrains
			the data value to be an integer multiple of the number given. (Type
			"integer" can also be expressed as a "multipleOf" quality of value 1,
			unless another "multipleOf" quality is present.)
			C.2. type "string"
			The type "string" is associated with Unicode text string values as
			they are available in JSON.
			The length (as measured in characters) can be constrained by the
			additional data qualities "minLength" and "maxLength", which are
			inclusive bounds. Note that the previous version of the present
			document explained text string length values in bytes, which however
			is not meaningful unless bound to a specific encoding (which could be
			UTF-8, if this unusual behavior is to be restored).
			The data quality "pattern" takes a string value that is interpreted
			as an [ECMA-262] regular expression in Unicode mode that constrain
			the string (note that these are not anchored by default, so unless ^
			and $ anchors are employed, ECMA-262 regular expressions match any
			string that _contains_ a match). The JSO proposals acknowledge that
			regular expression support is rather diverse in various platforms, so
			the suggestion is to limit them to:
			* characters;
			* character classes in square brackets, including ranges; their
			complements;
			* simple quantifiers *, +, ?, and range quantifiers {n}, {n,m}, and
			{n,};
			* grouping parentheses;
			* the choice operator |;
			* and anchors (beginning-of-input ^ and end-of-input $).
			Note that this subset is somewhat similar to the subset introduced by
			iregexps [I-D.bormann-jsonpath-iregexp], which however are anchored
			regular expressions, and which include certain backslash escapes for
			characters and character classes.
			The additional data quality "format" can take one of the following
			values. Note that, at an information model level, the presence of
			this data quality changes the type from being a simple text string to
			the abstract meaning of the format given (i.e., the format "date-
			time" is less about the specific syntax employed in [RFC3339] than
			about the usage as an absolute point in civil time).
			* "date-time", "date", "time": An [RFC3339] date-time, full-date, or
			full-time, respectively.
			* "uri", "uri-reference": An [RFC3986] URI or URI Reference,
			respectively.
			* "uuid": An [RFC4122] UUID.
			C.3. type "boolean"
			The type "boolean" can take the values "true" or "false".
			C.4. type "array"
			The type "array" is associated with arrays as they are available in
			JSON.
			The additional quality "items" gives the type that each of the
			elements of the array must match.
			The number of elements in the array can be constrained by the
			additional data qualities "minItems" and "maxItems", which are
			inclusive bounds.
			The additional data quality "uniqueItems" gives a Boolean value that,
			if true, requires the elements to be all different.
			C.5. type "object"
			The type "object" is associated with maps, from strings to values, as
			they are available in JSON ("objects").
			The additional quality "properties" is a map the entries of which
			describe entries in the specified JSON object: The key gives an
			allowable map key for the specified JSON object, and the value is a
			map with a named set of data qualities giving the type for the
			corresponding value in the specified JSON object.
			All entries specified this way are optional, unless they are listed
			in the value of the additional quality "required", which is an array
			of string values that give the key names of required entries.
			Note that the term "properties" as an additional quality for defining
			map entries is unrelated to sdfProperty.
			C.6. Implementation notes
			JSO-based keywords are also used in the specification techniques of a
			number of ecosystems, but some adjustments may be required.
			E.g., [OCF] is based on Swagger 2.0 which appears to be based on
			"draft-4" [I-D.wright-json-schema] (also called draft-5, but
			semantically intended to be equivalent to draft-4). The
			"exclusiveMinimum" and "exclusiveMaximum" keywords use the Boolean
			form there, so on import to SDF their values have to be replaced by
			the values of the respective "minimum"/"maximum" keyword, which are
			themselves then removed; the reverse transformation applies on
			export.
			TBD: add any useful implementation notes we can find for other
			ecosystems that use JSO.
	Acknowledgements		Acknowledgements
	This draft is based on "sdf.md" and "sdf-schema.json" in the old one-		This draft is based on sdf.md and sdf-schema.json in the old one-
	data-model "language" repository, as well as Ari Keränen's "alt-		data-model language repository, as well as Ari Keränen's "alt-schema"
	schema" from the Ericsson Research "ipso-odm" repository (which is		from the Ericsson Research ipso-odm repository (which is now under
	now under subdirectory "sdflint" in the one-data model "tools"		subdirectory sdflint in the one-data model tools repository).
	repository).
	Contributors		Contributors
	Ari Keränen		Ari Keränen
	Ericsson		Ericsson
	FI-02420 Jorvas		FI-02420 Jorvas
	Finland		Finland
	Email: ari.keranen@ericsson.com		Email: ari.keranen@ericsson.com
	Wouter van der Beek		Wouter van der Beek
	Cascoda Ltd.		Cascoda Ltd.
	Threefield House		Threefield House
	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)
	Dogtiger Labs		PassiveLogic
	524 H Street		524 H Street
	Antioch, CA, 94509		Antioch, CA, 94509
	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
End of changes. 109 change blocks.
	393 lines changed or deleted		494 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/