diff --git a/index.html b/index.html index 38f3b36..176ecba 100644 --- a/index.html +++ b/index.html @@ -98,7 +98,7 @@ background-color: rgb(230,230,230) } - +
@@ -179,7 +179,7 @@- This section describes a generic mechanism to define a - profile of the WoT Thing Description in a unambiguous way. + In order to conform with a profile, a + Web Thing + MUST conform with all the normative statements in the profile's specification.
- The W3C WoT Thing Description specification defines a
- formal language, i.e. a set of vocabulary terms (keywords),
- a set of classes that are built from these keywords, and a
- set of additional rules, that define constraints on
- permitted values and keyword presence (mandatory / optional)
- dependent on the context where the keyword is used. In
- addition the WoT Thing Description specification defines relationships and
- corresponding cardinalities between these classes.
+ In order to denote that a given
+ Web Thing
+ conforms to one or more profiles, its Thing Description MUST include a
+
+ profile
member [[wot-thing-description]]. The value of
+ the profile
member MUST be set to either a valid URI
+ [[RFC3986]] identifying a single profile, or an array of valid URIs
+ identifying multiple profiles.
- The WoT Thing Description specification already has some constraints, - but there is a wide variety of variations that are left to - the interpretation or the discretion of an implementer. The - rationale for the Core Profile is not to forbid - complex things, rather to enable statements like: -
- -- A profile is a set of constraints and rules, which - provide additional semantic guarantees that are applied - to the WoT Thing Description specification. These constraints define a - subset of valid WoT Thing Descriptions by defining - additional rules on various aspects of the WoT Thing - Description specification. -
- -Constraints on | -Rationale | -Example | -
---|---|---|
vocabulary of Thing Description classes | -guaranteed set of metadata fields | -Make specific vocabulary terms mandatory, - remove others | -
class relationships | -unambiguous structure | -limited cardinality, e.g. only one form per - operation per interaction affordance. | -
values of vocabulary terms | -simplified processing | -Limit the length of characters per string. - Always use arrays, where the spec permits a - string or an array of strings. | -
data schemas | -simplified processing | -No arbitrary nested objects or arrays of - arrays | -
security | -reduced implementation effort | -Only a restricted set of security - mechanisms | -
protocol binding | -guaranteed protocol semantics | -limited protocol(s) and protocol features, - Example: predefined mapping of http verbs (GET/PUT) to - operation verbs, similar constraints for other protocols. | -
These constraints and rules fall into two categories:
-These two categories are orthogonal to each other, - i.e. a data model that conforms to a profile can be - mapped to different protocols. - - The protocol binding for - each protocol may contain additional (protocol-specific) - constraints. - -
- -- - A profile is not exclusive, i.e. a thing may conform - to multiple profiles. - - Profiles can build on top of each - other or overlap, extended profiles can be built on top - of the core profile.
-- This specification does not put any requirements on the - scope and contents of other profiles. -
- - - -- In the present document, we define a Core Profile - by defining a Core Data Model and a set of Protocol Binding Rules - for selected protocols. - -
-+ { + "@context": "https://www.w3.org/2019/wot/td/v1", + "id": "urn:dev:ops:32473-WoTLamp-1234", + "profile": "https://www.w3.org/2021/wot/profile/core", + "title": "My Lamp", + "description": "A web connected lamp", + ... + } ++
+ { + "@context": "https://www.w3.org/2019/wot/td/v1", + "id": "urn:dev:ops:32473-WoTLamp-1234", + "profile": [ + "https://www.w3.org/2021/wot/profile/core", + "https://www.w3.org/2021/wot/profile/constrained" + ], + "title": "My Lamp", + "description": "A web connected lamp", + ... + } +
string
or
number
- .
+ .
Different types in a single
@@ -852,7 +747,7 @@
-
+
It will be evaluated whether the profile also recommends some new TD terms that may be
- introduced in TD 1.1.
+ introduced in TD 1.1.
Currently the following terms are discussed: serialNumber,
hardwareRevision, softwareRevision, loc_latitude, loc_longitude
- loc_altitude, loc_height, and loc_depth.
+ loc_altitude, loc_height, and loc_depth.
If these, or some of them, are defined in the TD
1.1 model, they may be recommended here in one of the next draft updates.
@@ -907,7 +802,7 @@ Data
The Core Data Model restricts the use of
arrays and objects to the top level
of Data Schemas, i.e. only a one-level hierarchy is
- permitted.
+ permitted.
The members of a top level
object
@@ -918,10 +813,10 @@ Data
-
+
This may appear as a severe limitation,
however it is motivated by integrating with
- multiple cloud services.
+ multiple cloud services.
Many enterprise services and applications are based on
(relational) databases, where individual
@@ -1044,15 +939,15 @@ Additional Constraints
The Thing Description permits arbitrary
object depths for properties. Parsing of a
deeply nested structure is not possible on
- resource constrained devices.
+ resource constrained devices.
Therefore each
- property MUST NOT exceed a maximum depth
+ property MUST NOT exceed a maximum depth
of 5 levels of nested
array
or
object
- elements. It is RECOMMENDED to keep the nesting
+ elements. It is RECOMMENDED to keep the nesting
of these elements below 4.
It is highly RECOMMENDED to always specify a
-
+
A Thing may provide more than one event
mechanism to enable a variety of consumers.
@@ -1461,7 +1356,7 @@
-
+
A Thing may provide more than one event
mechanism to enable a variety of consumers.
@@ -1574,7 +1469,7 @@
- The response to invoking an action needs to be defined.
+ The response to invoking an action needs to be defined.
Given not all actions can be completed within the
timeout period of an HTTP response, this may need to include a
@@ -2009,7 +1904,7 @@
Web Things MAY respond with other valid HTTP error codes
- (e.g.
-
+
If we define the finite set of error responses as above then we
should also define what a Consumer should do if it receives a 3xx
redirect type response.
@@ -2037,7 +1932,7 @@
-
+
The default representation is JSON. Semantic
annotations based on JSON-LD MAY be present but are not
required to perform all interactions with the thing
unit
- , if a value has a metric.
+ , if a value has a metric.
Authors of Thing Descriptions should be aware, that units
that are common in their geographic region are
@@ -1173,8 +1068,8 @@ Recommended Practice
hex
or
bin
- ,
-
+ ,
+
to indicate how the value should be
interpreted. It is strongly RECOMMENDED to use
the values
@@ -1354,7 +1249,7 @@ Event Affordance
class of section 5.3.1.5 of the WoT Thing Description Specification.
Additional Constraints
Forms
Security
The Core Data Model defines a subset of the
security schemes that MAY be implemented on resource
- constrained devices.
+ constrained devices.
A security scheme MUST be
@@ -1590,8 +1485,8 @@ Security
The set of security schemes supported in the Core
Data Model is based on the PlugFest results.
- To ensure interoperability, a TD consumer, which
- compliant with the Core Data Model MUST
+ To ensure interoperability, a TD consumer, which
+ compliant with the Core Data Model MUST
support all of the following security schemes:
invokeaction
Error Responses
418 I'm a teapot
),
+ (e.g. 418 I'm a teapot
),
but Consumers MAY interpret those error codes as a generic 4xx
or 5xx
@@ -2017,7 +1912,7 @@ Error Responses
Error Responses
External TD
representations