From c65581e0c05c684ff1ef9aafa91ae042493d80f6 Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Wed, 17 Jul 2024 17:22:49 +0100 Subject: [PATCH 01/12] A start on use cases and requirements for Profiles 2.0 --- requirements/V2_REQUIREMENTS.md | 69 +++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 requirements/V2_REQUIREMENTS.md diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md new file mode 100644 index 0000000..be41041 --- /dev/null +++ b/requirements/V2_REQUIREMENTS.md @@ -0,0 +1,69 @@ +# WoT Profiles 2.0 Use Cases & Requirements + +## Introduction + +The [Web of Things](https://www.w3.org/WoT/) (WoT) seeks to counter the fragmentation of the [Internet of Things](https://en.wikipedia.org/wiki/Internet_of_things) (IoT) by using and extending existing, standardized web technologies. + +The [W3C WoT Thing Description 1.1 specification](https://w3c.github.io/wot-profile/#bib-wot-thing-description11) defines an information model and JSON-based representation format for describing the capabilities of connected devices and the interfaces with which to communicate with them. Thing Descriptions are designed to be protocol-agnostic and flexible enough to describe a wide range of existing ("brownfield") IoT devices. + +In order to provide this level of flexibility the Thing Description specification includes a number of extension points including protocol bindings, payload bindings, security mechanisms, link relations and semantic contexts. As long as all of the capabilities of a device can be described using a Thing Description and a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) implements all of the extensions used, the Consumer should be able to interoperate with that device. However, the result of this extensible architecture is that any given Consumer can only interoperate with a subset of possible [Web Things](https://w3c.github.io/wot-profile/#dfn-thing). + +The WoT Profiles specification should complement the [Thing Description](https://w3c.github.io/wot-profile/#bib-wot-thing-description11) specification, by enabling ad-hoc interoperability through the use of "profiles". A profile prescribes a finite set of extensions and defaults that a Thing can be constrained to in order to guarantee out-of-the-box interoperability with any Consumer which implements that profile. Out-of-the-box interoperability means that a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) is guaranteed to be able to use every capability of a [Thing](https://w3c.github.io/wot-profile/#dfn-thing), without Thing-specific customization. + +Profiles will be designed specifically for new ("greenfield") implementations where developers have the freedom to conform to a prescriptive protocol binding and set of common constraints, in order to benefit from this additional level of interoperability. + +## Use Cases + +As a developer of a WoT Consumer, I want to guarantee out-of-the-box interoperability with a wide range of WoT Things. + +As a developer of a WoT Thing, I want to guarantee out-of-the-box interoperability with a wide range of WoT Consumers. + +### Smart Home + +As the developer of DIY smart home hub software, I want to safely expose an HTTP-based API for monitoring and controlling a home which conforms to a common standard, so that cloud services from multiple vendors can add value to a user's smart home without having to implement a vendor-specific API. + +As the developer of a smart home mobile app I want to offer my users out-of-the-box interoperability with a wide range of smart home devices so that I can maximise the audience for my app. + +### Smart Buildings + +As the developer of a smart building hub, I want to safely expose an HTTP-based API for monitoring and controlling a commercial building which conforms to a common standard, so that cloud services from multiple vendors can consume data from that hub without having to implement a vendor-specific API. + +As the developer of a smart building cloud service, I want to be able to provide data analytics for smart buildings using smart building hubs from different vendors which conform to a common standard, rather than having to implement multiple vendor-specific APIs. + +### Smart Cities + +### Manufacturing + +### Energy + +### Transportation + +### Agriculture + +## Requirements + +### WoT Profiles Specification + +The WoT Profiles specification: +1. MUST define a mechanism by which the author of a WoT Thing Description can denote that the Thing it describes conforms to a particular profile +2. MUST define a registry of profiles to which WoT Things and WoT Consumers may conform +3. SHOULD aim to keep the number of registered profiles as small as possible by rejecting profiles that significantly overlap in technologies or use cases, in order to minimise fragmentation on the Web of Things +### Individual Profiles + +Individual profile documents: +1. MUST specify an identifier (URI) which identifies the profile +2. SHOULD constrain a finite set of protocol bindings that a conformant Thing may use and that a conformant Consumer can be expected to support + 1. MAY constrain conformant Things to always follow certain defaults defined in a protocol binding document +3. SHOULD constrain a finite set of payload bindings that a conformant Thing may use and that a conformant Consumer can be expected to support + 1. MAY constrain conformant Things to always follow certain default payload formats defined in a payload binding document + 2. MAY constrain conformant Things to follow certain conventions such as date formats and error formats +4. SHOULD constrain a finite set of security mechanisms that a conformant Thing may use and that a conformant Consumer can be expected to support +5. SHOULD constrain a finite set of discovery mechanisms that a conformant Thing may use and that a conformant Consumer can be expected to support +6. MAY constrain a finite set of link relation types that a conformant Thing is recommended to use, and how they should be interpreted by a WoT Consumer +7. MAY constrain a finite set of semantic contexts that a conformant Thing is recommended to use and that a conformant Consumer can be expected to support +8. SHOULD NOT directly extend the WoT Thing Description information model, which should be defined using TD context extensions +9. SHOULD NOT define protocol behaviour, which should be defined in a protocol binding document +10. SHOULD NOT define data payload formats, which should be specified in a payload binding document +11. SHOULD NOT define discovery mechanisms, which should be defined in the WoT Discovery specification +12. SHOULD NOT define security mechanisms, which should be defined in a protocol binding document +13. SHOULD NOT describe an existing single-vendor IoT platform, which should be defined in a platform binding document \ No newline at end of file From 42c696d5c9a43b5a9ab5d3ff716da8d38ef6fe7f Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Thu, 18 Jul 2024 11:06:32 +0100 Subject: [PATCH 02/12] Update requirements/V2_REQUIREMENTS.md Co-authored-by: Ted Thibodeau Jr --- requirements/V2_REQUIREMENTS.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index be41041..9430d0f 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -22,7 +22,9 @@ As a developer of a WoT Thing, I want to guarantee out-of-the-box interoperabili As the developer of DIY smart home hub software, I want to safely expose an HTTP-based API for monitoring and controlling a home which conforms to a common standard, so that cloud services from multiple vendors can add value to a user's smart home without having to implement a vendor-specific API. -As the developer of a smart home mobile app I want to offer my users out-of-the-box interoperability with a wide range of smart home devices so that I can maximise the audience for my app. +As the developer of a smart home mobile app, I want to offer my users out-of-the-box interoperability with a wide range of smart home devices so that I can maximise the audience for my app. + +As the developer of a smart home device, I want my device to be controllable by any smart home hub software and/or any smart home mobile app that conforms to a common standard.... ### Smart Buildings From 1e15ca96a86f3d28dab8663d5de1d2f37879b170 Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Thu, 18 Jul 2024 11:07:11 +0100 Subject: [PATCH 03/12] Clarify out-of-the-box interoperability --- requirements/V2_REQUIREMENTS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index 9430d0f..576d1f5 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -8,7 +8,7 @@ The [W3C WoT Thing Description 1.1 specification](https://w3c.github.io/wot-prof In order to provide this level of flexibility the Thing Description specification includes a number of extension points including protocol bindings, payload bindings, security mechanisms, link relations and semantic contexts. As long as all of the capabilities of a device can be described using a Thing Description and a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) implements all of the extensions used, the Consumer should be able to interoperate with that device. However, the result of this extensible architecture is that any given Consumer can only interoperate with a subset of possible [Web Things](https://w3c.github.io/wot-profile/#dfn-thing). -The WoT Profiles specification should complement the [Thing Description](https://w3c.github.io/wot-profile/#bib-wot-thing-description11) specification, by enabling ad-hoc interoperability through the use of "profiles". A profile prescribes a finite set of extensions and defaults that a Thing can be constrained to in order to guarantee out-of-the-box interoperability with any Consumer which implements that profile. Out-of-the-box interoperability means that a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) is guaranteed to be able to use every capability of a [Thing](https://w3c.github.io/wot-profile/#dfn-thing), without Thing-specific customization. +The WoT Profiles specification should complement the [Thing Description](https://w3c.github.io/wot-profile/#bib-wot-thing-description11) specification, by enabling ad-hoc interoperability through the use of "profiles". A profile prescribes a finite set of extensions and defaults that a Thing can be constrained to in order to guarantee out-of-the-box interoperability with any Consumer which implements that profile. Out-of-the-box interoperability means that a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) which implements a given profile is guaranteed to be able to use every capability of a [Thing](https://w3c.github.io/wot-profile/#dfn-thing), which implements that same profile, without Thing-specific customization. Profiles will be designed specifically for new ("greenfield") implementations where developers have the freedom to conform to a prescriptive protocol binding and set of common constraints, in order to benefit from this additional level of interoperability. From 15bf16f0572a2c0b0f7511c150bdc6ba5063ae82 Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Fri, 19 Jul 2024 11:40:34 +0100 Subject: [PATCH 04/12] Make it clearer that Profiles should not directly extend or conflict with the TD specification --- requirements/V2_REQUIREMENTS.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index 576d1f5..4bd2093 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -8,7 +8,8 @@ The [W3C WoT Thing Description 1.1 specification](https://w3c.github.io/wot-prof In order to provide this level of flexibility the Thing Description specification includes a number of extension points including protocol bindings, payload bindings, security mechanisms, link relations and semantic contexts. As long as all of the capabilities of a device can be described using a Thing Description and a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) implements all of the extensions used, the Consumer should be able to interoperate with that device. However, the result of this extensible architecture is that any given Consumer can only interoperate with a subset of possible [Web Things](https://w3c.github.io/wot-profile/#dfn-thing). -The WoT Profiles specification should complement the [Thing Description](https://w3c.github.io/wot-profile/#bib-wot-thing-description11) specification, by enabling ad-hoc interoperability through the use of "profiles". A profile prescribes a finite set of extensions and defaults that a Thing can be constrained to in order to guarantee out-of-the-box interoperability with any Consumer which implements that profile. Out-of-the-box interoperability means that a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) which implements a given profile is guaranteed to be able to use every capability of a [Thing](https://w3c.github.io/wot-profile/#dfn-thing), which implements that same profile, without Thing-specific customization. + +"WoT Profiles" are a mechanism by which out-of-the-box interoperability between WoT [Consumers](https://w3c.github.io/wot-profile/#dfn-consumer) and [Things](https://w3c.github.io/wot-profile/#dfn-thing) can be guaranteed, by constraining a Thing to a finite list of options for each extension point, and requiring that it conforms to certain defaults. As long as a Consumer implements all of the extensions and defaults prescribed by a Profile, it should be guaranteed to be able to use all of the capabilities of a Thing which conform to that Profile, without Thing-specific customisation. Profiles will be designed specifically for new ("greenfield") implementations where developers have the freedom to conform to a prescriptive protocol binding and set of common constraints, in order to benefit from this additional level of interoperability. @@ -68,4 +69,5 @@ Individual profile documents: 10. SHOULD NOT define data payload formats, which should be specified in a payload binding document 11. SHOULD NOT define discovery mechanisms, which should be defined in the WoT Discovery specification 12. SHOULD NOT define security mechanisms, which should be defined in a protocol binding document -13. SHOULD NOT describe an existing single-vendor IoT platform, which should be defined in a platform binding document \ No newline at end of file +13. SHOULD NOT describe an existing single-vendor IoT platform, which should be defined in a platform binding document +14. MUST NOT include any assertions which would require a Thing Description of a conformant Web Thing to be non-conformant with the Thing Description 2.0 specification \ No newline at end of file From 5a608a883fb46e062afdd2cbd53a6099df0d53dc Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Fri, 19 Jul 2024 11:40:55 +0100 Subject: [PATCH 05/12] Assert that a Thing can conform to multiple profiles --- requirements/V2_REQUIREMENTS.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index 4bd2093..469d6a5 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -70,4 +70,5 @@ Individual profile documents: 11. SHOULD NOT define discovery mechanisms, which should be defined in the WoT Discovery specification 12. SHOULD NOT define security mechanisms, which should be defined in a protocol binding document 13. SHOULD NOT describe an existing single-vendor IoT platform, which should be defined in a platform binding document -14. MUST NOT include any assertions which would require a Thing Description of a conformant Web Thing to be non-conformant with the Thing Description 2.0 specification \ No newline at end of file +14. MUST NOT include any assertions which would require a Thing Description of a conformant Web Thing to be non-conformant with the Thing Description 2.0 specification +15. SHOULD NOT include any assertions which conflict with another Profile, so that a Thing may conform with multiple Profiles \ No newline at end of file From c095b61de8ea17d53d577cb32e491f0d3223ef7c Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Mon, 22 Jul 2024 13:25:50 +0100 Subject: [PATCH 06/12] Reword paragraph that mentions greenfield --- requirements/V2_REQUIREMENTS.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index 469d6a5..fa86dc8 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -11,7 +11,7 @@ In order to provide this level of flexibility the Thing Description specificatio "WoT Profiles" are a mechanism by which out-of-the-box interoperability between WoT [Consumers](https://w3c.github.io/wot-profile/#dfn-consumer) and [Things](https://w3c.github.io/wot-profile/#dfn-thing) can be guaranteed, by constraining a Thing to a finite list of options for each extension point, and requiring that it conforms to certain defaults. As long as a Consumer implements all of the extensions and defaults prescribed by a Profile, it should be guaranteed to be able to use all of the capabilities of a Thing which conform to that Profile, without Thing-specific customisation. -Profiles will be designed specifically for new ("greenfield") implementations where developers have the freedom to conform to a prescriptive protocol binding and set of common constraints, in order to benefit from this additional level of interoperability. +Whilst the Web of Things provides the freedom to describe a wide range of existing IoT systems using [WoT Binding Templates](https://www.w3.org/TR/wot-binding-templates/), Profiles provide an optional additional layer of common constraints to which new implementations can conform in order to benefit from an increased level of interoperability. ## Use Cases @@ -25,7 +25,7 @@ As the developer of DIY smart home hub software, I want to safely expose an HTTP As the developer of a smart home mobile app, I want to offer my users out-of-the-box interoperability with a wide range of smart home devices so that I can maximise the audience for my app. -As the developer of a smart home device, I want my device to be controllable by any smart home hub software and/or any smart home mobile app that conforms to a common standard.... +As the developer of a smart home device, I want my device to be controllable by any smart home hub software and/or any smart home mobile app that conforms to a common standard. ### Smart Buildings From 305e88e3474c047d5df14b7737d354fa81621a0a Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Mon, 22 Jul 2024 13:32:33 +0100 Subject: [PATCH 07/12] Add note about Thing capabilities outside of a Profile --- requirements/V2_REQUIREMENTS.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index fa86dc8..d5eaf72 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -13,6 +13,8 @@ In order to provide this level of flexibility the Thing Description specificatio Whilst the Web of Things provides the freedom to describe a wide range of existing IoT systems using [WoT Binding Templates](https://www.w3.org/TR/wot-binding-templates/), Profiles provide an optional additional layer of common constraints to which new implementations can conform in order to benefit from an increased level of interoperability. +Conforming to a Profile does not prevent a Web Thing from describing additional capabilities and protocol bindings in their Thing Description beyond those described in the Profile, as long as they conform with all of the normative assertions of the Profile. + ## Use Cases As a developer of a WoT Consumer, I want to guarantee out-of-the-box interoperability with a wide range of WoT Things. From 29202e6a2c0c21864f832dc78aedd4ad96c6f88b Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Mon, 22 Jul 2024 13:49:41 +0100 Subject: [PATCH 08/12] Reinforce point about constraining vs. extending --- requirements/V2_REQUIREMENTS.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index d5eaf72..6510f56 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -13,6 +13,8 @@ In order to provide this level of flexibility the Thing Description specificatio Whilst the Web of Things provides the freedom to describe a wide range of existing IoT systems using [WoT Binding Templates](https://www.w3.org/TR/wot-binding-templates/), Profiles provide an optional additional layer of common constraints to which new implementations can conform in order to benefit from an increased level of interoperability. +Profiles are designed to constrain, not extend, the Web of Things. They should only be used to constrain the set of options for existing extension points, never to extend the Web of Things directly. + Conforming to a Profile does not prevent a Web Thing from describing additional capabilities and protocol bindings in their Thing Description beyond those described in the Profile, as long as they conform with all of the normative assertions of the Profile. ## Use Cases From 640406952cb311466d3d3862bada3ddf95b43c44 Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Mon, 22 Jul 2024 15:29:39 +0100 Subject: [PATCH 09/12] Remove the word brownfield --- requirements/V2_REQUIREMENTS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index 6510f56..5291bfa 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -4,7 +4,7 @@ The [Web of Things](https://www.w3.org/WoT/) (WoT) seeks to counter the fragmentation of the [Internet of Things](https://en.wikipedia.org/wiki/Internet_of_things) (IoT) by using and extending existing, standardized web technologies. -The [W3C WoT Thing Description 1.1 specification](https://w3c.github.io/wot-profile/#bib-wot-thing-description11) defines an information model and JSON-based representation format for describing the capabilities of connected devices and the interfaces with which to communicate with them. Thing Descriptions are designed to be protocol-agnostic and flexible enough to describe a wide range of existing ("brownfield") IoT devices. +The [W3C WoT Thing Description 1.1 specification](https://w3c.github.io/wot-profile/#bib-wot-thing-description11) defines an information model and JSON-based representation format for describing the capabilities of connected devices and the interfaces with which to communicate with them. Thing Descriptions are designed to be protocol-agnostic and flexible enough to describe a wide range of existing IoT devices. In order to provide this level of flexibility the Thing Description specification includes a number of extension points including protocol bindings, payload bindings, security mechanisms, link relations and semantic contexts. As long as all of the capabilities of a device can be described using a Thing Description and a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) implements all of the extensions used, the Consumer should be able to interoperate with that device. However, the result of this extensible architecture is that any given Consumer can only interoperate with a subset of possible [Web Things](https://w3c.github.io/wot-profile/#dfn-thing). From 0dd28e73df7d7a980d69935655ef1537b61cdffe Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Mon, 22 Jul 2024 15:31:46 +0100 Subject: [PATCH 10/12] Binding Templates -> Thing Descriptions --- requirements/V2_REQUIREMENTS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index 5291bfa..93d2215 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -11,7 +11,7 @@ In order to provide this level of flexibility the Thing Description specificatio "WoT Profiles" are a mechanism by which out-of-the-box interoperability between WoT [Consumers](https://w3c.github.io/wot-profile/#dfn-consumer) and [Things](https://w3c.github.io/wot-profile/#dfn-thing) can be guaranteed, by constraining a Thing to a finite list of options for each extension point, and requiring that it conforms to certain defaults. As long as a Consumer implements all of the extensions and defaults prescribed by a Profile, it should be guaranteed to be able to use all of the capabilities of a Thing which conform to that Profile, without Thing-specific customisation. -Whilst the Web of Things provides the freedom to describe a wide range of existing IoT systems using [WoT Binding Templates](https://www.w3.org/TR/wot-binding-templates/), Profiles provide an optional additional layer of common constraints to which new implementations can conform in order to benefit from an increased level of interoperability. +Whilst the Web of Things provides the freedom to describe a wide range of existing IoT systems using Thing Description, Profiles provide an optional additional layer of common constraints to which new implementations can conform in order to benefit from an increased level of interoperability. Profiles are designed to constrain, not extend, the Web of Things. They should only be used to constrain the set of options for existing extension points, never to extend the Web of Things directly. From f437ef0e936e13ee2f34454a2dd4bbda463143bf Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Tue, 23 Jul 2024 12:37:22 +0100 Subject: [PATCH 11/12] Update requirements/V2_REQUIREMENTS.md Co-authored-by: Ted Thibodeau Jr --- requirements/V2_REQUIREMENTS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index 93d2215..5bce8cb 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -15,7 +15,7 @@ Whilst the Web of Things provides the freedom to describe a wide range of existi Profiles are designed to constrain, not extend, the Web of Things. They should only be used to constrain the set of options for existing extension points, never to extend the Web of Things directly. -Conforming to a Profile does not prevent a Web Thing from describing additional capabilities and protocol bindings in their Thing Description beyond those described in the Profile, as long as they conform with all of the normative assertions of the Profile. +Conforming to a Profile does not prevent a Web Thing from describing additional capabilities or protocol bindings beyond those described in the Profile in their Thing Description, as long as they conform with all of the normative assertions of the Profile. ## Use Cases From 5dbcb09fcedbe67387b3d085b0b00152886cd66d Mon Sep 17 00:00:00 2001 From: Ben Francis Date: Wed, 26 Mar 2025 10:46:35 +0000 Subject: [PATCH 12/12] Discourage Profiles specific to a single application domain --- requirements/V2_REQUIREMENTS.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/requirements/V2_REQUIREMENTS.md b/requirements/V2_REQUIREMENTS.md index 5bce8cb..1524266 100644 --- a/requirements/V2_REQUIREMENTS.md +++ b/requirements/V2_REQUIREMENTS.md @@ -8,7 +8,6 @@ The [W3C WoT Thing Description 1.1 specification](https://w3c.github.io/wot-prof In order to provide this level of flexibility the Thing Description specification includes a number of extension points including protocol bindings, payload bindings, security mechanisms, link relations and semantic contexts. As long as all of the capabilities of a device can be described using a Thing Description and a [Consumer](https://w3c.github.io/wot-profile/#dfn-consumer) implements all of the extensions used, the Consumer should be able to interoperate with that device. However, the result of this extensible architecture is that any given Consumer can only interoperate with a subset of possible [Web Things](https://w3c.github.io/wot-profile/#dfn-thing). - "WoT Profiles" are a mechanism by which out-of-the-box interoperability between WoT [Consumers](https://w3c.github.io/wot-profile/#dfn-consumer) and [Things](https://w3c.github.io/wot-profile/#dfn-thing) can be guaranteed, by constraining a Thing to a finite list of options for each extension point, and requiring that it conforms to certain defaults. As long as a Consumer implements all of the extensions and defaults prescribed by a Profile, it should be guaranteed to be able to use all of the capabilities of a Thing which conform to that Profile, without Thing-specific customisation. Whilst the Web of Things provides the freedom to describe a wide range of existing IoT systems using Thing Description, Profiles provide an optional additional layer of common constraints to which new implementations can conform in order to benefit from an increased level of interoperability. @@ -17,6 +16,8 @@ Profiles are designed to constrain, not extend, the Web of Things. They should o Conforming to a Profile does not prevent a Web Thing from describing additional capabilities or protocol bindings beyond those described in the Profile in their Thing Description, as long as they conform with all of the normative assertions of the Profile. +Profiles are designed to promote cross-vendor and cross-domain interoperability, so a Profile should not be restricted to a single application domain. + ## Use Cases As a developer of a WoT Consumer, I want to guarantee out-of-the-box interoperability with a wide range of WoT Things. @@ -55,6 +56,8 @@ The WoT Profiles specification: 1. MUST define a mechanism by which the author of a WoT Thing Description can denote that the Thing it describes conforms to a particular profile 2. MUST define a registry of profiles to which WoT Things and WoT Consumers may conform 3. SHOULD aim to keep the number of registered profiles as small as possible by rejecting profiles that significantly overlap in technologies or use cases, in order to minimise fragmentation on the Web of Things +4. SHOULD not include profiles which are specific to a single application domain, in order to maximise cross-domain interoperability + ### Individual Profiles Individual profile documents: