Version: 6 Dec 2019
Editors:
Michael McCool (Intel)
Ege Korkan (Siemens / Technical University of Munich)
Copyright © 2019 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The Web of Things (WoT) Thing Description specification entered the Candidate Recommendation period for the second time on 6 November 2019.
The planned date for entering Proposed Recommendation is 10 December 2019. This document summarizes the results from the Web of Things (WoT) TD implementer reports received and describes the process that the Web of Things (WoT) Working Group followed in preparing this Implementation Report (IR).
Although results were generated with a combination of automated and manual tests, the automated tests were only meant to provide assistance to implementers in preparing their individual implementation test reports.
During the CR period, the Working Group carried out the following activities:
Implementers were invited to contribute to the assessment of the Web of Things (WoT) Thing Description Candidate Recommendation by submitting implementer reports describing the coverage of their implementations with respect to the test assertions outlined in the table below.
Implementer reports were collected through the W3C WoT Interest Group's
PlugFest activity and collected in the GitHub
repository
https://github.com/w3c/wot
under testing/tests/2019-05/.
Comments on this document, or requests made for further information were posted to the Working Group's public mailing list wot-wg@w3.org (archive) and as issues on the GitHub repository https://github.com/w3c/wot-thing-description.
The Web of Things (WoT) Working Group established the following entrance criteria for the Proposed Recommendation phase in the Request for CR:
All three of these criteria have been met. The testimonials below indicate the broad base of support for the specification. All of the required features had at least two implementations. All of the optional features also received at least one implementation. However, these optional features do not have conformance requirements that have an impact on interoperability.
Feature status is in practice indicated by RFC 2119 assertions associated with the feature. Features defined using any assertions containing the words MUST are considered required. Features defined using MAY and SHOULD assertions are considered optional.
pass, fail, or
not-impl (not implemented).
This implementation Report will not cover:
This section contains descriptions of each of the implementations of the WoT Thing Description specification from all organizations that submitted implementer reports. Each implementation represents a working system that either exposes or consumes at least one WoT Thing Description. Implementations that expose a network interface described by a Thing Description will be referred to as "servers". Implementations that consume Thing Descriptions will be referred to as "clients". Note that these terms will be used with these specific definitions in the following regardless of which device initiates network requests. Normally the client initiates requests and the server responds. However, in some protocols or sub-protocols that support push notifications (such as webhooks or MQTT) the usual relationship of initiator/responder may be reversed. In some cases a given implementation may be used for multiple Things and a single Thing may also act as both client and server on multiple interfaces.
We only count systems with mostly independent code bases as distinct implementations. There are however some cases (documented in the following) where implementations shared components but were still considered substantially independent implementations. In cases where a substantial component was shared across implementations the features supported by that component were only counted once.
Three implementations were created, all of which are TD Producers and demonstrate how existing ecosystems can be supported.
TD which exposes a dimmable light on the Philips Hue hub.
TD which exposes a dimmable, color control, light on the IKEA Tradfri hub.
TD which exposes a Motion sensor and Illuminance sensor supported by Node-Red.
Arena Web Hub is an open source node-based application server for the Web of Things that has been implemented with support from the European Commission for the F-Interop project as a means to demonstrate high level interoperability testing for the Web of Things.
One of the example applications is a browser-based test suite for both client and server in respect to the contract implied by a Thing Description. This uses a specially designed Thing Description, together with associated client and server applications, and has been developed to cover the constraints implied by the data schemas defined by the Thing Description specification.
Other example applications include remote control of a cyber-physical system, a digital twin for a smart light, and multi-channel data streaming for remote diagnosis of cardiac problems. All of these applications combine an exposed thing with a web page for the associated user interface.
This is a browser-based JavaScript library designed to support multiple server platforms, including the Arena Web Hub, Eclipse ThingWeb (node-wot), and Mozilla's Things Gateway.
Arena Web Hub is a secure by design application server with support for HTTPS and WebSockets. HTTPS is used together with a bearer token for access control, along with support for Server-Sent Events and Long Polling. You can get or set the values of all properties in a single transaction. The WebSockets sub-protocol is initiated via a protocol upgrade request from HTTPS, and includes suppport for properties, actions and events. This makes use of a RESTful request/response pattern with the same status codes as for HTTPS. Arena has minimal dependencies on other modules and can be installed via npm or a git clone of the open source repository. Applications can combine the producer and consumer modules as needed.
Fujitsu supports this specification to connect any kinds of devices used in a various fields and to lead them to operate from the cloud services. The WoT gateway can bring the devices to the WoT world easily, since it can provide adaptation functionality to convert their proprietary i nterfaces to the WoT interface.
The Fujitsu WoT gateway has an API similar to Scripting API. This API enables developers to make device adapters to convert their propriety interface to WoT and create applications to handle their devices using with WoT interface. These adapters can be attached and detached easily using with OSGi framework, since the adapters are developed as OSGi bundles (plug-ins) and installed to the WoT gateway just before the devices to be connected.
Multi-layered gateways are effective for the large scale system. Mainly lower gateways can connect physical devices and upper gateways aggregate lower gateways. This configuration can cover the huge number of devices connected to widely deployed gateways. If the upper gateway and lower gateways deploy on the cloud and on the local network respectively, for example, inside buildings, the applications can monitor and control the devices on the buildings beyond firewall and NAT. In the WoT plugfest, Fujitsu set up the upper gateway on the internet and the lower gateways on the local networks in the smart home and at the plugfests site.
The WoT sensors includes a Wi-Fi communication unit that has a WoT stack on it and easily make compatible WoT devices using sensors units. This communication unit has a common interface like I2C and GPIO for the connections.
Home appliances and facilities like window blinds in the smart home can be connected with adapters to convert the propriety interface like ECHONET Lite to WoT. Rotating light that has EtherCAT interface can be done in the same way.
The pre-proccesing mechanism for Node-RED is supported to generate the nodes on Node-RED corresponding to the shadow devices on the WoT gateway. This is composed of a retriever of TDs on the gateway and the node generator provided by Hitachi and offers a good application development environment to quickly set up.
Hitachi understands the importance of standardization to make the world seamlessly connected, and strongly supports W3C's activities.
Hitachi expects that standardization of Web of Things enables easy integration accross various Things and IoT platforms. We create a tool for rapid application development using Node-RED, called Node generator.
Node generator is command line tool to generate Node-RED node modules from several various sources including Thing Description of Web of Things. Using this tool, node developers can dramatically reduce their time to implement Node-RED node modules.
Huawei supports this specification as a practical solution to counter fragmentation in the IoT. W3C Web of Things aligns, for instance, with oneM2M, where WoT Thing Descriptions are considered as a solution for the so-called Interworking Proxies. A particularly noteworthy benefit of W3C Web of Things is that it applies to any IoT application domain, from consumer electronics to heavy industries.
At this stage, Huawei focuses on supporting the standardization process. The implementations cover features of the comprehensive and versatile specification that are not sufficiently covered by others.
Eclipse Californium is a comprehensive implementation of the Constrained Application Protocol (RFC 7252). It supports all DTLS security schemes, PSK, certificates, and RawPublicKey. By providing WoT Thing Descriptions (TDs), CoAP servers implemented by Californium – or any other CoAP implementation – become part of the Web of Things. Huawei provides TDs for the Californium demo apps, in particular cf-secure to demonstrate the feasibility to describe CoAPS security schemes.
This implementation supports the full range of meta-interactions possible for Things. They are declared and
described through the forms array within the TD root object and allow to read/write all
Properties or to read/write multiple Properties.
The Meta-Interaction Thing also supports language negotiation and secures one Property with Digest and another
with a fictional Useless Web Token (UWT) that is described through a TD Context Extension (security scheme
bearer with format set to the UWT class name).
Intel supports this specification as it enables interoperation between devices from different manufacturers, supporting the growth of an ecosystem of interoperating IoT services and easing barriers to adoption.
Three separate implementations were developed, all based on Node.js. The core implementations focused on basic local network access without built-in security. A separate project, used by all three implementations, provided security (encryption and authentication) by means of a reverse proxy. For the purposes of validation this reverse proxy was considered a shared component of all three implementations, and the features it implemented were only counted once in the results.
This component, shared across all implementations provided by Intel, was a reverse proxy service that provided authentication (via various mechanisms indicated by the schemes indicated in the Thing Description) and encrypted transport termination. The reverse proxy service was made accessible over a secure tunnel, and depending on the circumstances, was run in the cloud, on a gateway computer, or locally on a device. As this component implemented the security features in all other implementations from Intel, for the purposes of validation these features are only recorded as being supported in a single implementation.
This implementation translated metadata made available by devices implemented using the OCF standard and re-expressed that metadata in the form of WoT Thing Descriptions. The actual network interfaces were however provided either by the OCF devices themselves directly via CoAP, or via a CoAP/HTTP bridge developed by OCF. The metadata translator also had the ability to add semantic markup to the generated WoT Thing Descriptions, using a database that related OCF Resource Types to iotschema.org capabilities. It also had the capability to register generated TDs with directory services. Secure interfaces (e.g. HTTPS combined with an authentication scheme) were provided via a reverse proxy attached to the HTTP interface provided by the OCF CoAP/HTTP bridge.
The OCF devices were based on the OCF Smart Home Demo and included both real and simulated devices. Real devices used for testing included
This implementation provided a service to convert text to speech. English text set to its network interface was spoken audibily. This service was used to test several accessibility scenarios, including automatic conversion of visible status and event information to spoken announcements in order to support blind users. This implementation only supported an HTTP network interface, without security. Secure interfaces (eg HTTPS combined with an authentication scheme) were provided via a reverse proxy attached to the HTTP interface. The TDs for this service were generated using a template mechanism, and the service also had the capability to automatically register these TDs with a directory service.
This implementation provided a service to capture still images from a camera and provide them over its network interface. This was used to test various aspects of actions, including support for inputs and outputs with different content types. The service was also capaple of introspecting the parameters made available via any particular attached video4linux camera and made those parameters available as WoT Thing Description properties. This implementation only supported an HTTP network interface, without security. Secure interfaces (eg HTTPS combined with an authentication scheme) were provided via a reverse proxy attached to the HTTP interface. The TDs for this service were generated using a template mechanism, and the service also had the capability to automatically register these TDs with a directory service.
This implementation provided a service to detect, recognize, and localize objects in an image using a hardware-accelerated neural network. This was implemented using a service running on a gateway. This was used to test various aspects of actions, including support for inputs and outputs with different content types, but in an opposite way to the camera. The camera accepted JSON to localize a region of interest and output an image; the object identification service took a JPEG image and output JSON listing the objects recognized and their location. This implementation only supported an HTTP network interface, without security. Secure interfaces (eg HTTPS combined with an authentication scheme) were provided via a reverse proxy attached to the HTTP interface. The TDs for this service were generated using a template mechanism, and the service also had the capability to automatically register these TDs with a directory service.
Oracle supports this specification as it enables manufacturers of IoT cloud platforms and applications to integrate devices across multiple vendors, who describe their features and functionality in a uniform way. This enables application scenarios that allow monitoring and control of devices from different manufacturers. Flexible rules can be used to define alert conditions that trigger actions on devices based on sensor data from other devices. Sensor data combined with big data analytics can be used to predict maintenance needs of devices to prevent downtime.
A common way of describing devices grows the ecosystem of devices that can be easily integrated into cloud platforms out of the box and thus enables creating digital twins of physical devices for asset monitoring, production monitoring, fleet management, and the management of buildings and smart cities.
Oracle offers an IoT Cloud Service that enables management of devices, messages and alerts. This platform is complemented with cloud applications for asset monitoring, production monitoring, fleet management, connected workers and others. The IoT Cloud Service interoperates with WoT servients as described in the sections below.
Oracle's Asset Monitoring application is used to define scenarios that combine devices from different manufacturers. Flexible rules trigger actions and issue alerts based on sensor data from other devices. In several scenarios (home, industrial, smart energy) devices from various manufacturers, including Fujitsu, Intel, Panasonic, KETI and others were integrated into a combined use case. Devices include home devices (e.g. smart lamps, air conditioners, window blinds, cleaners, robots) and industrial devices (e.g. alert lights, pumps, valves, liquid sensors, environment monitors, solar chargers, speech output). These devices were controlled by rules that were triggered by events on various sensors, e.g. draining a tank when a critical environment condition happens, indicating the water level in a tank with RGB lamps and a numeric display panel, and more.
Oracle's IoT cloud platform defines a device model abstraction that is used to describe the common
behaviour of a class of devices via properties (attributes), actions, messages and alerts. This format is
similar to the WoT thing description and thing descriptions can be converted to device models and vice
versa.
Devices that are managed by the IoT cloud platform can be expose using the WoT thing description format and
devices that are described via thing descriptions can be consumed from the IoT cloud service. Oracle provides
open source implementations of converters to generate a device model from a thing description (td2dm) and vice
versa (dm2td).
Oracle's IoT Cloud Service includes a simulator for devices which allows to model and test asset monitoring scenarios without having the physical device already available. This allows experimenting with different device models and finding the right abstraction before a device is actually manufacturered and thus reduce the implementation risk. Various device simulations were provided by Oracle:
These simulations were exposed via TDs that were generated from device models using the converters above. The simulator uses HTTP/REST with JSON to interact with the devices. To facilitate easy integration and interworking during the plug fests we used basic. In real world scenarios typically OAuth2 is used.
TD's for devices from other manufacterer were imported using the td2dm converter and simulators were defined for the following devices:
node-wot contains a binding to Oracle's IoT Cloud Service that was kindly developed by Matthias Kovatsch. The binding uses Oracle's JavaScript client library that encapsulates Oracle's proprietary device to cloud communication protocol. The integration allows node-wot to expose Things to Oracle's IoT Cloud Service. Users of the Oracle Cloud API can then read Properties and invoke Actions on the node-wot based Things. The converters above consume the TDs and instantiate devices with the corresponding Oracle device model in the IoT Cloud Service.
Panasonic supports this specification as it enables device manufacturers to describe features and functionality of multiple devices in a uniform way. This will make it possible to build mash-up applications easily with multiple devices not only from single vendor but also from different vendors, which will expand the ecosystem.
Panasonic already has various IoT devices in the market and this specification is the first candidate to be used for the directory system to discover those devices. At the moment, Panasonic implements two types of clients (TD consumer) as well as two types of servers (TD producer), together with independent authentication server as a shared component, for experimental purposes.
This component provides authentication functionality for users who access Panasonic things (TD producers) such as the real things or simulated things provided by other implementations. This component supports HTTPS, receives a predetermined userid and password via an HTTP POST method and sends back a bearer token based on JWT. The token should be placed in the Authentication request header upon access to a Thing supporting the "bearer" security scheme. The URL and other information of this component is provided in the security elements of the Thing Descriptions produced by Panasonic things.
This implementation is a TD Consumer which works on the Chrome browser. This implementation reads a Thing Description from a designated URL via HTTP(S), expands its properties, actions and events into UI form, then allows user to read, write or observe a property value, invoke an action, or subscribe/unsubscribe to an event through the UI. When the TD indicates that the thing needs a bearer token, this implementation also supports the settting of user credentials such as userid and password and retrieves the access token from the authentication service at the URL designated in the TD, such as the Panasonic Authentication Server explained above. This implementation also allows the manual addition of any HTTP headers to the request message sent to the things.
This implementation basically supports only HTTP(S) and does not support CoAP and MQTT. For observe property
and events, this implementation supports both HTTP(S) long poll and a simple WebSocket protocol which contains
only a data value in its transaction. This implementation only supports application/json as message body and
does not support text/plain. Since this implementation is browser based and uses Ajax, its default mode
requires support of CORS from the server exposing the Things, unless the chrome browser is launched with the
--disable-web-security option.
This implementation is a TD Consumer which works on Node-RED. This implementation reads a Thing Description from a designated URL via HTTP(S) and from a local folder, finds a specific thing according to a semantic annotation, and turns the thing on/off. The implementation supports only HTTP(S) with `"nosec"` and `"basic"` authorization. For MQTT and WebSockets, this implementation needs a hard-coded URL due to the restriction of normal Node-RED.
This implementation is a TD producer which is hosted on a cloud server and connected to real things in the lab through a proprietary tunneling mechanism alike to remote and local WoT proxy. This implementation accepts HTTP bindings with bearer token authorization issued by the Panasonic Authentication Server explained above. This implementation currently provides the following things:
This implementation is a TD producer which is hosted on a cloud server and hosts virtual things running on the server. This implementation accepts HTTP bindings with bearer token authorization issued by the Panasonic Authentication Server explained above. This implementation currently provides simulation of things such as
Siemens supports this specification as it allows manufacturers to attach metadata to heterogeneous IoT devices and services in a uniform way. The extensible model with a standardized serialization format in particular remedies interoperability challenges with an installed base of long-lived industrial devices. Furthermore, this specification is a central building block for several digitalization topics such as device onboarding, device management, digital twins, and data analytics.
Siemens commits to several open-source implementations of W3C Web of Things, which are managed in the public Eclipse Thingweb project. Siemens also implemented concepts of this specification in products and aims at aligning the implementations and opening the features to customers once this specification reaches REC status.
The node-wot implementation is a Node.js-based framework for WoT Servients. It features an implementation of the WoT Scripting API to both consume TDs to instantiate Consumed Things and produce Exposed Things that provide a TD. The node-wot implementation supports several Protocol Bindings including HTTP, CoAP, WebSockets, and MQTT, with corresponding security mechanisms such as DTLS (CoAP); TLS (HTTP, MQTT), Basic, Digest, and Bearer Token authentication (HTTP), PSK (CoAP), and username/password authentication (MQTT).
The Thingweb Directory provides a directory service written in Java to register TDs and look them up through queries (primarily SPARQL). The implementation consumes TDs registered with it through a web API, represent their metadata in a KnowledgeGraph, and (re-)produces TDs to return the results of queries. Currently it supports HTTP and CoAP bindings.
WoT-fxUI is a generic user interface (UI) for Things based on Java with JavaFX. It consumes TDs to render UI elements that allow human users to interact with Things. The implementation currently supports HTTP and CoAP bindings.
Technical University of Munich supports the Thing Description standardization with the testing efforts and is interested in the development of multiple WoT standards.
Multiple implementations have been provided, including TDs for closed source Philips HUE devices.
A light sensor that is attached to an ESP 8266 board that is programmed in Micropython. The board is resource constrained and does not allow installation of HTTP server libraries like Flask. That is why it is called bare.
Two implementations using the Flask library for creating an HTTP server. One of the implementations is a camera that can take pictures and the other one is an LED Strip that allows for complex data structures.
Example of an MQTT servient that allows for observable properties. There are also examples on how to use oneOf and null vocabulary terms. This is a running instance at the Eclipse Thingweb server that uses the test.mosquitto online broker.
Example of an MQTT servient that allows for observable and readable properties. It uses the Mosca MQTT broker that is available from Node-Red. The values pushed are temperature values that vary between 10 and 11.
TDs for different HUE devices, including the Bridge. These TDs show that we can describe already existing devices with TDs
The Web of Things (WoT) Thing Description specification includes features to support security. Functional aspects of assertions associated with security features are validated in the same fashion as other functional features. In addition, however, the Web of Things (WoT) WG Charter requires the development of a test plan that includes adversarial testing. An appropriate security test plan, including a description of how existing web service penetration testing tools can be used, in addition to a description of more general security and privacy considerations, is included in Web of Things (WoT) Security and Privacy Guidelines.
The aim of this section is to summarize the assertions from the Web of Things (WoT) Thing Description specification and summarize the results from the implementation reports received in the CR period. The tables in each section below lists all assertions derived from the Web of Things (WoT) Thing Description specification. The results are broken into two parts: those for which automated testing has been implemented, and those for which it has not and manual testing and reporting was necessary.
The headers for these tables are described as follows:
pass (P),
fail (F), and not-impl (N) status results in the individual implementer
reports.
In the case of assertions with multiple mutually exclusive options (for example, enumerated values) each of these options may be tested separately and the results combined. In this case the 'pass' and 'total' values reported are the minimum value of any of the more detailed tests, while the 'fail' and 'not implemented' values report the maximum value of any of these tests. Since minimum and maximum value may be drawn from different detailed tests, the sum of the 'pass', 'fail', and 'not implemented' cases may not equal the 'total'. Instead the total represents the number of implementations for which all options were tested. For such cases the "child" assertions have underscores in their names prior to each value tested and the table row is also rendered in a different color.
The following assertions have been validated by automated testing using the ThingWeb Playground AssertionTester.
| ID | Category | Req | Context | Assertion | Parent | Results | |||
|---|---|---|---|---|---|---|---|---|---|
| P | F | N | T | ||||||
| td-action-arrays | Syntax | Y |
ActionAffordance |
The value assigned to forms in an instance of ActionAffordance MUST be serialized as a JSON array containing one or more JSON object serializations as defined in . | td-actions |
19 | 0 | 7 | 26 |
| td-action-names | Syntax | Y |
ActionAffordance |
All name-value pairs of an instance of ActionAffordance, where the name is a Vocabulary Term included in (one of) the Signatures of ActionAffordance or InteractionAffordance, MUST be serialized as members of the JSON object that results from serializing the ActionAffordance instance, with the Vocabulary Term as name. | td-actions |
4 | 0 | 22 | 26 |
| td-action-names_at-type | Syntax | Y |
ActionAffordance |
The vocabulary term @type MUST be serialized as a JSON name within an Action object. | td-actions |
4 | 0 | 22 | 26 |
| td-action-names_forms | Syntax | Y |
ActionAffordance |
The vocabulary term forms MUST be serialized as a JSON name within an Action object. | td-action-names |
19 | 0 | 7 | 26 |
| td-action-names_idempotent | Syntax | Y |
ActionAffordance |
The vocabulary term idempotent MUST be serialized as a JSON name within an Action object. | td-action-names |
10 | 0 | 16 | 26 |
| td-action-names_output | Syntax | Y |
ActionAffordance |
The vocabulary term output MUST be serialized as a JSON name within an Action object. | td-action-names |
4 | 0 | 22 | 26 |
| td-action-names_safe | Syntax | Y |
ActionAffordance |
The vocabulary term safe MUST be serialized as a JSON name within an Action object. | td-action-names |
8 | 0 | 18 | 26 |
| td-action-objects | Syntax | Y |
ActionAffordance |
The values assigned to input and output in an instance of ActionAffordance MUST be serialized as JSON objects. | td-actions |
4 | 0 | 22 | 26 |
| td-action-objects_input | Syntax | Y |
ActionAffordance |
The type of the members input MUST be serialized as a JSON object. | td-action-objects |
10 | 0 | 16 | 26 |
| td-action-objects_output | Syntax | Y |
ActionAffordance |
The type of the members output MUST be serialized as a JSON object. | td-action-objects |
4 | 0 | 22 | 26 |
| td-actions | Syntax | Y |
Thing |
All name-value pairs of a Map of ActionAffordance instances MUST be serialized as members of the JSON object that results from serializing the Map; the name of a pair MUST be serialized as a JSON string and the value of the pair, an instance of ActionAffordance, MUST be serialized as a JSON object. | 19 | 0 | 7 | 26 | |
| td-actions_existence | Syntax | Y |
ActionAffordance |
Actions offered by a Thing MUST be collected in the JSON-object based actions member. | td-actions |
19 | 0 | 7 | 26 |
| td-actions_uniqueness | Syntax | Y |
ActionAffordance |
Actions collected in the JSON-object based actions member MUST have unique JSON names. | td-actions |
19 | 0 | 7 | 26 |
| td-array-type | Type | Y |
Thing |
A value of type Array MUST be serialized as JSON array, with each value of the name-value pairs as element of the JSON array ordered by the numeric name of the pair. | 26 | 0 | 0 | 26 | |
| td-arrays | Syntax | Y |
Forms Links Security Scopes |
All values assigned to links, and forms in an instance of the Class Thing MUST be serialized as JSON arrays containing JSON objects as defined in and , respectively. | 2 | 0 | 24 | 26 | |
| td-arrays_forms | Syntax | Y |
Thing InteractionAffordance |
The type of the member forms MUST be a JSON array. | td-arrays |
26 | 0 | 0 | 26 |
| td-arrays_links | Syntax | Y |
Thing |
The type of the member links MUST be a JSON array. | td-arrays |
5 | 0 | 21 | 26 |
| td-arrays_scopes | Syntax | Y |
Thing Form |
The type of the member scopes MUST be a JSON array. | td-arrays |
2 | 0 | 24 | 26 |
| td-arrays_security | Syntax | Y |
Thing Form |
The value of the member security MUST be serialized as a JSON array. | td-arrays |
26 | 0 | 0 | 26 |
| td-boolean-type | Type | Y |
Thing |
Values that are of type boolean MUST be serialized as JSON boolean. | 25 | 0 | 1 | 26 | |
| td-class-type | Type | Y |
Thing |
A Class instance MUST be serialized as JSON object, following the detailed rules given individually in . | 26 | 0 | 0 | 26 | |
| td-context | Syntax | Y |
Thing |
The root element of a TD Serialization MUST be a JSON object that includes a member with the name @context and a value of type string or array that equals or respectively contains https://www.w3.org/2019/wot/td/v1. | 26 | 0 | 0 | 26 | |
| td-context-default-language | Syntax | N |
Thing |
One Map contained in an @context Array SHOULD contain a name-value pair that defines the default language for the Thing Description, where the name is the Term @language and the value is a well-formed language tag as defined by [[!BCP47]] (e.g., en, de-AT, gsw-CH, zh-Hans, zh-Hant-HK, sl-nedis). | 9 | 0 | 17 | 26 | |
| td-context-default-language-direction-script | Language | Y | (TD Consumer) |
In cases where a language can be written in more than one script with different base directions, the corresponding language tag given in @language or MultiLanguage Maps MUST include a script subtag, so that an appropriate base direction can be inferred. | 2 | 0 | 25 | 27 | |
| td-context-ns-thing-mandatory | Context | Y | (Context) |
The @context name-value pair MUST contain the anyURI https://www.w3.org/2019/wot/td/v1 either directly when of type anyURI or as first element when of type Array. | 26 | 0 | 1 | 27 | |
| td-context-ns-thing-map-of-namespaces | Context | N | (Context) |
Maps contained in an @context Array MAY contain name-value pairs, where the value is a namespace identifier of type anyURI and the name a Term or prefix denoting that namespace. | 18 | 0 | 9 | 27 | |
| td-context-ns-thing-optional | Context | N | (Context) |
When @context is an Array, the anyURI https://www.w3.org/2019/wot/td/v1 MAY be followed by elements of type anyURI or type Map in any order, while it is RECOMMENDED to include only one Map with all the name-value pairs in the @context Array. | 18 | 0 | 9 | 27 | |
| td-context-toplevel | Syntax | Y |
Thing |
All name-value pairs of an instance of Thing, where the name is a Vocabulary Term in the Signature of Thing, MUST be serialized as JSON members of the root object. | 26 | 0 | 0 | 26 | |
| td-data-schema | Syntax | Y |
DataSchema |
All name-value pairs of an instance of one of the Subclasses of DataSchema, where the name is a Vocabulary Term included in the Signature of that Subclass or in the Signature of DataSchema, MUST be serialized as members of the JSON object that results from serializing the DataSchema Subclass's instance, with the Vocabulary Term as name. | 3 | 1 | 23 | 27 | |
| td-data-schema-arrays | Syntax | Y |
DataSchema |
The values assigned to enum, required, and oneOf in an instance of DataSchema MUST be serialized as a JSON array. | td-data-schema |
4 | 0 | 22 | 26 |
| td-data-schema-arrays_enum | Syntax | Y |
DataSchema |
The value of the member enum MUST be serialized as a JSON array with a DataSchema object. | td-data-schema-arrays |
5 | 0 | 21 | 26 |
| td-data-schema-arrays_oneOf | Syntax | Y |
DataSchema |
The value of the member oneOf MUST be serialized as a JSON array with a DataSchema object. | td-data-schema-arrays |
4 | 0 | 22 | 26 |
| td-data-schema-arrays_required | Syntax | Y |
DataSchema |
The value of the member required MUST be serialized as a JSON array with a DataSchema object. | td-data-schema-arrays |
6 | 0 | 20 | 26 |
| td-data-schema-objects | Syntax | Y |
DataSchema |
The value assigned to properties in an instance of ObjectSchema MUST be serialized as a JSON object. | td-data-schema |
14 | 0 | 13 | 27 |
| td-data-schema-objects-arrays | Syntax | Y |
DataSchema |
The value assigned to items in an instance of ArraySchema MUST be serialized as a JSON object or a JSON array containing JSON objects. | td-data-schema |
9 | 0 | 17 | 26 |
| td-data-schema_at-type | Syntax | Y |
DataSchema |
The @type vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
8 | 0 | 18 | 26 |
| td-data-schema_const | Syntax | Y |
DataSchema |
The const vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
5 | 0 | 21 | 26 |
| td-data-schema_description | Syntax | Y |
DataSchema |
The description vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
14 | 0 | 12 | 26 |
| td-data-schema_descriptions | Syntax | Y |
DataSchema |
The descriptions vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
6 | 0 | 20 | 26 |
| td-data-schema_enum | Syntax | Y |
DataSchema |
The enum vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
5 | 0 | 21 | 26 |
| td-data-schema_format | Y |
DataSchema |
The format vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
3 | 0 | 23 | 26 | |
| td-data-schema_items | Syntax | Y |
ArraySchema |
The items vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
9 | 0 | 17 | 26 |
| td-data-schema_maxItems | Syntax | Y |
ArraySchema |
The maxItems vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
4 | 0 | 22 | 26 |
| td-data-schema_maximum-IntegerSchema | Syntax | Y |
IntegerSchema |
The maximum vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
6 | 1 | 19 | 26 |
| td-data-schema_maximum-NumberSchema | Syntax | Y |
NumberSchema |
The maximum vocabulary term as defined in the class DataSchema for numbers MUST be serialized as a JSON name. | td-data-schema |
9 | 0 | 17 | 26 |
| td-data-schema_minItems | Syntax | Y |
ArraySchema |
The minItems vocabulary term as defined in the class DataSchema MUST be serialized as a JSON name. | td-data-schema |
3 | 0 | 23 | 26 |
| td-data-schema_minimum-IntegerSchema | Syntax | Y |
IntegerSchema |
The minimum vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
7 | 1 | 18 | 26 |
| td-data-schema_minimum-NumberSchema | Syntax | Y |
NumberSchema |
The minimum vocabulary term as defined in the class DataSchema for numbers MUST be serialized as a JSON name. | td-data-schema |
9 | 0 | 17 | 26 |
| td-data-schema_oneOf | Syntax | Y |
DataSchema |
The oneOf vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
4 | 0 | 22 | 26 |
| td-data-schema_properties | Syntax | Y |
ObjectSchema |
The properties vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
14 | 0 | 12 | 26 |
| td-data-schema_readOnly | Syntax | Y |
DataSchema |
The readOnly vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
19 | 0 | 7 | 26 |
| td-data-schema_required | Syntax | Y |
DataSchema |
The required vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
6 | 0 | 20 | 26 |
| td-data-schema_title | Syntax | Y |
DataSchema |
The title vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
9 | 0 | 17 | 26 |
| td-data-schema_titles | Syntax | Y |
DataSchema |
The titles vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
4 | 0 | 22 | 26 |
| td-data-schema_type | Syntax | Y |
DataSchema |
The type vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
21 | 1 | 4 | 26 |
| td-data-schema_unit | Syntax | Y |
DataSchema |
The unit vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
5 | 0 | 21 | 26 |
| td-data-schema_writeOnly | Syntax | Y |
DataSchema |
The writeOnly vocabulary term as defined in the class DataSchema for integers MUST be serialized as a JSON name. | td-data-schema |
12 | 0 | 14 | 26 |
| td-datetime-recommended-type | Syntax | N |
Thing |
Values that are of type dateTime SHOULD use the literal Z representing the UTC time zone instead of an offset. | 7 | 0 | 19 | 26 | |
| td-datetime-type | Syntax | Y |
Thing |
Values that are of type dateTime MUST be serialized as JSON strings following the "date-time" format specified by [[RFC3339]]. | 7 | 0 | 19 | 26 | |
| td-event-arrays | Syntax | Y |
EventAffordance |
The value assigned to forms in an instance of EventAffordance MUST be serialized as a JSON array containing one or more JSON object serializations as defined in . | td-events |
13 | 0 | 13 | 26 |
| td-event-names | Syntax | Y |
EventAffordance |
All name-value pairs of an instance of EventAffordance, where the name is a Vocabulary Term included in (one of) the Signatures of EventAffordance or InteractionAffordance, MUST be serialized as members of the JSON object that results from serializing the EventAffordance instance, with the Vocabulary Term as name. | td-events |
2 | 0 | 24 | 26 |
| td-event-names_at-type | Syntax | Y | The vocabulary term @type MUST be serialized as a JSON name within an Event object. | 2 | 0 | 24 | 26 | ||
| td-event-names_cancellation | Syntax | Y |
EventAffordance |
The vocabulary term cancellation MUST be serialized as a JSON name within an Event object. | td-event-names |
2 | 0 | 24 | 26 |
| td-event-names_data | Syntax | Y |
EventAffordance |
The vocabulary term data MUST be serialized as a JSON name within an Event object. | td-event-names |
6 | 0 | 20 | 26 |
| td-event-names_forms | Syntax | Y |
EventAffordance |
The vocabulary term forms MUST be serialized as a JSON name within an Event object. | td-event-names |
13 | 0 | 13 | 26 |
| td-event-names_subscription | Syntax | Y |
EventAffordance |
The vocabulary term subscription MUST be serialized as a JSON name within an Event object. | td-event-names |
2 | 0 | 24 | 26 |
| td-event-objects | Syntax | Y |
EventAffordance |
The values assigned to subscription, data, and cancellation in an instance of EventAffordance MUST be serialized as JSON objects. | td-events |
2 | 0 | 24 | 26 |
| td-event-objects_cancellation | Syntax | Y |
EventAffordance |
The type of the members cancellation MUST be serialized as a JSON object. | td-event-objects |
2 | 0 | 24 | 26 |
| td-event-objects_data | Syntax | Y |
EventAffordance |
The type of the members data MUST be serialized as a JSON object. | td-event-objects |
6 | 0 | 20 | 26 |
| td-event-objects_subscription | Syntax | Y |
EventAffordance |
The type of the members subscription MUST be serialized as a JSON object. | td-event-objects |
2 | 0 | 24 | 26 |
| td-events | Syntax | Y |
Thing |
All name-value pairs of a Map of EventAffordance instances MUST be serialized as members of the JSON object that results from serializing the Map; the name of a pair MUST be serialized as a JSON string and the value of the pair, an instance of EventAffordance, MUST be serialized as a JSON object. | 13 | 0 | 13 | 26 | |
| td-events_existence | Syntax | Y |
EventAffordance |
Events offered by a Thing MUST be collected in the JSON-object based events member. | td-events |
13 | 0 | 13 | 26 |
| td-events_uniqueness | Syntax | Y |
EventAffordance |
Events collected in the JSON-object based events member MUST have unique JSON names. | td-events |
13 | 0 | 13 | 26 |
| td-form-response-object | Syntax | Y |
Form |
If present, the value assigned to response in an instance of Form MUST be a JSON object. | td-forms |
3 | 0 | 23 | 26 |
| td-format-validation-known-values | Syntax | N |
DataSchema |
Servients MAY use the format value to perform additional validation accordingly. | td-data-schema |
4 | 0 | 23 | 27 |
| td-forms | Syntax | Y |
Thing InteractionAffordance |
All name-value pairs of an instance of Form, where the name is a Vocabulary Term included in the Signature of Form, MUST be serialized as members of the JSON object that results from serializing the Form instance, with the Vocabulary Term as name. | 26 | 0 | 0 | 26 | |
| td-forms-response | Syntax | Y |
Form |
If present, the response object MUST contain a contentType member as defined in the Class definition of ExpectedResponse. | 3 | 0 | 23 | 26 | |
| td-integer-type | Syntax | Y |
Thing |
Values that are of type integer or unsignedInt MUST be serialized as JSON numbers without a fraction or exponent part. | 10 | 1 | 15 | 26 | |
| td-json-open_utf-8 | Syntax | Y |
Thing |
TDs MUST be encoded using UTF-8 [[!RFC3629]]. | td-json-open |
26 | 0 | 0 | 26 |
| td-jsonld-keywords_at-context | Syntax | N |
Thing |
Thing Description instances MAY contain the JSON-LD keyword @context. | td-jsonld-keywords |
26 | 0 | 0 | 26 |
| td-jsonld-keywords_at-type | Syntax | N |
Thing InteractionAffordance DataSchema |
Thing Description instances MAY contain the JSON-LD keyword @type. | td-jsonld-keywords |
12 | 0 | 14 | 26 |
| td-links | Syntax | Y |
Thing |
All name-value pairs of an instance of Link, where the name is a Vocabulary Term included in the Signature of Link, MUST be serialized as members of the JSON object that results from serializing the Link instance, with the Vocabulary Term as name. | 5 | 0 | 21 | 26 | |
| td-map-type | Type | Y |
Thing |
A value of type Map MUST be serialized as JSON object, with each name-value pair as member of the JSON object. | 26 | 0 | 0 | 26 | |
| td-multi-languages | Syntax | Y |
Thing InteractionAffordance DataSchema |
All name-value pairs of a MultiLanguage Map MUST be serialized as members of a JSON object, where the name is a well-formed language tag as defined by [[!BCP47]] and the value is a human-readable string in the language indicated by the tag. | 6 | 0 | 20 | 26 | |
| td-multi-languages-consistent | Syntax | N |
Thing InteractionAffordance DataSchema |
All MultiLanguage object within a TD document SHOULD contain the same set of language members. | 26 | 0 | 0 | 26 | |
| td-multi-languages_descriptions | Syntax | Y |
Thing InteractionAffordance DataSchema |
Whenever the vocabulary terms descriptions can be used it MUST be serialized as JSON object. The member names of the JSON Object MUST be the language tags as defined in [[BCP47]] (e.g., "en", "de", "ja", "zh-Hans", "zh-Hant"). The value of each member MUST be serialized as JSON string. | td-multi-languages |
8 | 0 | 18 | 26 |
| td-multi-languages_titles | Syntax | Y |
Thing InteractionAffordance DataSchema |
Whenever the vocabulary terms titles can be used it MUST be serialized as JSON object. The member names of the JSON Object MUST be the language tags as defined in [[BCP47]] (e.g., "en", "de", "ja", "zh-Hans", "zh-Hant"). The value of each member MUST be serialized as JSON string. | td-multi-languages |
6 | 0 | 20 | 26 |
| td-multilanguage-language-tag | Syntax | Y |
MultiLanguage |
Each name of the MultiLanguage Map MUST be a language tag as defined in [[!BCP47]]. | 26 | 0 | 0 | 26 | |
| td-multilanguage-value | Syntax | Y |
MultiLanguage |
Each value of the MultiLanguage Map MUST be of type string. | 8 | 0 | 18 | 26 | |
| td-number-type | Syntax | Y |
Thing |
Values that are of type double MUST be serialized as JSON number. | 15 | 0 | 11 | 26 | |
| td-objects | Syntax | Y |
PropertyAffordance ActionAffordance EventAffordance SecurityScheme MultiLanguage |
All values assigned to version, securityDefinitions, properties, actions, and events in an instance of the Class Thing MUST be serialized as JSON objects. | 6 | 0 | 20 | 26 | |
| td-objects_actions | Syntax | Y |
Thing |
The type of the members actions MUST be serialized as a JSON object. | td-objects |
19 | 0 | 7 | 26 |
| td-objects_events | Syntax | Y |
Thing |
The type of the members events MUST be serialized as a JSON object. | td-objects |
13 | 0 | 13 | 26 |
| td-objects_properties | Syntax | Y |
Thing |
The type of the members properties MUST be serialized as a JSON object. | td-objects |
23 | 0 | 3 | 26 |
| td-objects_securityDefinitions | Syntax | Y |
Thing |
The type of the members securityDefinitions MUST be serialized as a JSON object. | td-objects |
26 | 0 | 0 | 26 |
| td-objects_version | Syntax | Y |
Thing |
The type of the members version MUST be serialized as a JSON object. | td-objects |
6 | 0 | 20 | 26 |
| td-op-for-action | Syntax | Y |
ActionAffordance |
When a Form instance is within an ActionAffordance instance, the value assigned to op MUST be invokeaction. | td-forms |
8 | 0 | 18 | 26 |
| td-op-for-event | Syntax | Y |
EventAffordance |
When a Form instance is within an EventAffordance instance, the value assigned to op MUST be either subscribeevent, unsubscribeevent, or both terms within an Array. | td-forms |
5 | 0 | 21 | 26 |
| td-op-for-property | Syntax | Y |
PropertyAffordance |
When a Form instance is within a PropertyAffordance instance, the value assigned to op MUST be one of readproperty, writeproperty, observeproperty, unobserveproperty or an Array containing a combination of these terms. | td-forms |
16 | 0 | 10 | 26 |
| td-op-for-thing | Syntax | Y |
Thing |
When the forms Array of a Thing instance contains Form instances, the string values assigned to the name op, either directly or within an Array, MUST be one of the following opteration types: readallproperties, writeallproperties, readmultipleproperties, or writemultipleproperties. | td-forms |
7 | 0 | 19 | 26 |
| td-processor | Syntax | Y | (TD Processor) |
A TD Processor MUST satisfy the Class instantiation constraints on all Classes defined in , , , and . | 26 | 0 | 0 | 26 | |
| td-properties | Syntax | Y |
Thing |
All name-value pairs of a Map of PropertyAffordance instances MUST be serialized as members of the JSON object that results from serializing the Map; the name of a pair MUST be serialized as a JSON string and the value of the pair, an instance of PropertyAffordance, MUST be serialized as a JSON object. | 23 | 0 | 3 | 26 | |
| td-properties_existence | Syntax | Y |
Thing |
Properties offered by a Thing MUST be collected in the JSON-object based properties member. | td-properties |
23 | 0 | 3 | 26 |
| td-properties_uniqueness | Syntax | Y |
Thing |
Properties collected in the JSON-object based properties member MUST have unique JSON names. | td-properties |
23 | 0 | 3 | 26 |
| td-property-arrays | Syntax | Y |
PropertyAffordance |
The value assigned to forms in an instance of PropertyAffordance MUST be serialized as a JSON array containing one or more JSON object serializations as defined in . | td-properties |
23 | 0 | 3 | 26 |
| td-property-names | Syntax | Y |
PropertyAffordance |
All name-value pairs of an instance of PropertyAffordance, where the name is a Vocabulary Term included in (one of) the Signatures of PropertyAffordance, InteractionAffordance, or DataSchema, MUST be serialized as members of the JSON object that results from serializing the PropertyAffordance instance, with the Vocabulary Term as name. | td-properties |
8 | 0 | 18 | 26 |
| td-property-names_at-type | Syntax | Y |
PropertyAffordance |
The vocabulary term @type MUST be serialized as a JSON name within a Property object. | td-property-names |
8 | 0 | 18 | 26 |
| td-property-names_forms | Syntax | Y |
PropertyAffordance |
The vocabulary term forms MUST be serialized as a JSON name within a Property object. | td-property-names |
23 | 0 | 3 | 26 |
| td-property-names_observable | Syntax | Y |
PropertyAffordance |
The vocabulary term observable MUST be serialized as a JSON name within a Property object. | td-property-names |
11 | 0 | 15 | 26 |
| td-security | Security | Y |
Thing Form |
All name-value pairs of a Map of SecurityScheme instances MUST be serialized as members of the JSON object that results from serializing the Map; the name of a pair MUST be serialized as a JSON string and the value of the pair, an instance of SecurityScheme, MUST be serialized as a JSON object. | td-security |
26 | 0 | 0 | 26 |
| td-security-activation | Syntax | Y |
Thing Form |
The value assigned to security in an instance of Class Thing MUST be serialized as JSON string or as JSON array whose elements are JSON strings. | td-security |
26 | 0 | 0 | 26 |
| td-security-bearer-format-extensions | Security | N |
BearerSecurityScheme PopSecurityScheme |
Other formats and algorithms for bearer tokens MAY be specified in vocabulary extensions | td-security |
1 | 0 | 25 | 26 |
| td-security-bearer-format-extensions_alg | N | Other algorithms for bearer tokens MAY be specified in vocabulary extensions. | 1 | 0 | 25 | 26 | |||
| td-security-bearer-format-extensions_format | N | Other formats for bearer tokens MAY be specified in vocabulary extensions. | 1 | 0 | 25 | 26 | |||
| td-security-mandatory | Security | Y |
Thing |
At least one security definition MUST be activated through the security array at the Thing level (i.e., in the TD root object). | td-security |
26 | 0 | 0 | 26 |
| td-security-oauth2-code-flow | Security | Y |
OAuth2SecurityScheme |
For the code flow both authorization and token MUST be included. | td-security |
2 | 0 | 25 | 27 |
| td-security-overrides | Security | N |
Thing Form |
Security definitions MAY also be activated at the form level by including a security member in form objects, which overrides (i.e., completely replace) all definitions activated at the Thing level. | td-security |
7 | 0 | 20 | 27 |
| td-security-scheme-name | Syntax | Y |
SecurityScheme |
The value assigned to the name scheme MUST be defined within a Vocabulary included in the Thing Description, either in the standard Vocabulary defined in or in a TD Context Extension. | td-security |
26 | 0 | 0 | 26 |
| td-security-schemes | Syntax | Y |
SecurityScheme |
All name-value pairs of an instance of one of the Subclasses of SecurityScheme, where the name is a Vocabulary Term included in the Signature of that Subclass or in the Signature of SecurityScheme, MUST be serialized as members of the JSON object that results from serializing the SecurityScheme Subclass's instance, with the Vocabulary Term as name. | td-security |
26 | 0 | 0 | 26 |
| td-string-type | Syntax | Y |
Thing |
Values that are of type string or anyURI MUST be serialized as JSON strings. | 26 | 0 | 0 | 26 | |
| td-title-description | Syntax | N |
Thing InteractionAffordance DataSchema |
When title and titles or description and descriptions are present within the same JSON object, the values of title and description MAY be seen as the default text. | 7 | 0 | 20 | 27 | |
| td-title-description_descriptions | Syntax | N |
Thing InteractionAffordance DataSchema |
If description and descriptions are defined at the same time at the JSON level, description MAY be seen as default text. | td-title-description |
9 | 0 | 18 | 27 |
| td-title-description_titles | Syntax | N |
Thing InteractionAffordance DataSchema |
If title and titles are defined at the same time at the JSON level, title MAY be seen as default text. | td-title-description |
7 | 0 | 20 | 27 |
| td-titles-descriptions | Syntax | N |
Thing InteractionAffordance DataSchema |
When title and titles or description and descriptions are present in a TD document, each title and description member SHOULD have a corresponding titles and descriptions member, respectively. | 6 | 2 | 18 | 26 | |
| td-uriVariables-dataschema | Syntax | Y |
InteractionAffordance |
The serialization of each value in the map assigned to uriVariables in an instance of Form MUST rely on the Class DataSchema, whose serialization is defined in . | 5 | 0 | 21 | 26 | |
| td-uriVariables-names | Syntax | Y |
InteractionAffordance |
In such a case, the URI Template variables MUST be collected in the JSON-object based uriVariables member with the associated (unique) variable names as JSON names. | 5 | 0 | 21 | 26 | |
| td-version | Syntax | Y |
Thing |
All name-value pairs of an instance of VersionInfo, where the name is a Vocabulary Term included in the Signature of VersionInfo, MUST be serialized as JSON members with the Vocabulary Term as name. | 6 | 0 | 20 | 26 | |
| td-vocab-actions--Thing | Vocabulary | N |
Thing |
actions: All Action-based Interaction Affordances of the Thing. MAY be included. Type: Map of ActionAffordance. | td-vocabulary |
19 | 0 | 7 | 26 |
| td-vocab-alg--BearerSecurityScheme | Vocabulary | N |
BearerSecurityScheme |
alg: Encoding, encryption, or digest algorithm. MAY be included. Type: string (e.g., MD5, ES256, or ES512-256). | td-vocabulary |
4 | 0 | 22 | 26 |
| td-vocab-anchor--Link | Vocabulary | N |
Link |
anchor: Overrides the link context (by default the Thing itself identified by its id) with the given URI or IRI. MAY be included. Type: anyURI. | td-vocabulary |
1 | 0 | 25 | 26 |
| td-vocab-at-context--Thing | Vocabulary | Y |
Thing |
@context: JSON-LD keyword to define short-hand names called terms that are used throughout a TD document. MUST be included. Type: anyURI or Array. | td-vocabulary |
26 | 0 | 0 | 26 |
| td-vocab-at-type--DataSchema | Vocabulary | N |
DataSchema |
@type: JSON-LD keyword to label the object with semantic tags (or types) MAY be included. Type: string or Array of string. | td-vocabulary |
8 | 0 | 18 | 26 |
| td-vocab-at-type--InteractionAffordance | Vocabulary | N |
InteractionAffordance |
@type: JSON-LD keyword to label the object with semantic tags (or types). MAY be included. Type: string or Array of string. | td-vocabulary |
8 | 0 | 18 | 26 |
| td-vocab-at-type--SecurityScheme | Vocabulary | N |
DataSchema |
@type: JSON-LD keyword to label the object with semantic tags (or types). MAY be included. Type: string or Array of string. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-at-type--Thing | Vocabulary | N |
Thing |
@type: JSON-LD keyword to label the object with semantic tags (or types). MAY be included. Type: string or Array of string. | td-vocabulary |
11 | 0 | 15 | 26 |
| td-vocab-authorization--BearerSecurityScheme | Vocabulary | N |
BearerSecurityScheme |
authorization: URI of the authorization server. MAY be included. Type: anyURI. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-authorization--OAuth2SecurityScheme | Vocabulary | N |
OAuth2SecurityScheme |
authorization: URI of the authorization server. MAY be included. Type: anyURI. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-base--Thing | Vocabulary | N |
Thing |
base: Define the base URI that is used for all relative URI references throughout a TD document. In TD instances, all relative URIs are resolved relative to the base URI using the algorithm defined in [[RFC3986]].base does not affect the URIs used in @context and the IRIs used within Linked Data [[?LINKED-DATA]] graphs that are relevant when semantic processing is applied to TD instances. MAY be included. Type: anyURI. | td-vocabulary |
15 | 0 | 11 | 26 |
| td-vocab-cancellation--EventAffordance | Vocabulary | N |
EventAffordance |
cancellation: Defines any data that needs to be passed to cancel a subscription, e.g., a specific message to remove a Webhook. MAY be included. Type: DataSchema. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-const--DataSchema | Vocabulary | N |
DataSchema |
const: Provides a constant value. MAY be included. Type: any type. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-contentCoding--Form | Vocabulary | N |
Form |
contentCoding: Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Examples of content coding include "gzip", "deflate", etc. . MAY be included. Type: string. | td-vocabulary |
1 | 0 | 25 | 26 |
| td-vocab-contentType--ExpectedResponse | Vocabulary | Y |
ExpectedResponse |
contentType: Assign a content type based on a media type (e.g., text/plain) and potential parameters (e.g., charset=utf-8) for the media type [[RFC2046]]. MUST be included. Type: string. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-contentType--Form | Vocabulary | N |
Form |
contentType: Assign a content type based on a media type (e.g., text/plain) and potential parameters (e.g., charset=utf-8) for the media type [[RFC2046]]. MAY be included. Type: string. | td-vocabulary |
23 | 0 | 3 | 26 |
| td-vocab-created--Thing | Vocabulary | N |
Thing |
created: Provides information when the TD instance was created. MAY be included. Type: dateTime. | td-vocabulary |
7 | 0 | 19 | 26 |
| td-vocab-data--EventAffordance | Vocabulary | N |
EventAffordance |
data: Defines the data schema of the Event instance messages pushed by the Thing. MAY be included. Type: DataSchema. | td-vocabulary |
6 | 0 | 20 | 26 |
| td-vocab-description--DataSchema | Vocabulary | N |
DataSchema |
description: Provides additional (human-readable) information based on a default language. MAY be included. Type: string. | td-vocabulary |
14 | 0 | 12 | 26 |
| td-vocab-description--InteractionAffordance | Vocabulary | N |
InteractionAffordance |
description: Provides additional (human-readable) information based on a default language. MAY be included. Type: string. | td-vocabulary |
14 | 0 | 12 | 26 |
| td-vocab-description--SecurityScheme | Vocabulary | N |
SecurityScheme |
description: Provides additional (human-readable) information based on a default language. MAY be included. Type: string. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-description--Thing | Vocabulary | N |
Thing |
description: Provides additional (human-readable) information based on a default language. MAY be included. Type: string. | td-vocabulary |
17 | 0 | 9 | 26 |
| td-vocab-descriptions--DataSchema | Vocabulary | N |
DataSchema |
descriptions: Can be used to support (human-readable) information in different languages. MAY be included. Type: MultiLanguage. | td-vocabulary |
6 | 0 | 20 | 26 |
| td-vocab-descriptions--InteractionAffordance | Vocabulary | N |
InteractionAffordance |
descriptions: Can be used to support (human-readable) information in different languages. MAY be included. Type: MultiLanguage. | td-vocabulary |
6 | 0 | 20 | 26 |
| td-vocab-descriptions--SecurityScheme | Vocabulary | N |
SecurityScheme |
descriptions: Can be used to support (human-readable) information in different languages. MAY be included. Type: MultiLanguage. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-descriptions--Thing | Vocabulary | N |
Thing |
descriptions: Can be used to support (human-readable) information in different languages. MAY be included. Type: MultiLanguage. | td-vocabulary |
7 | 0 | 19 | 26 |
| td-vocab-enum--DataSchema | Vocabulary | N |
DataSchema |
enum: Restricted set of values provided as an array. MAY be included. Type: Array of any type. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-events--Thing | Vocabulary | N |
Thing |
events: All Event-based Interaction Affordances of the Thing. MAY be included. Type: Map of EventAffordance. | td-vocabulary |
13 | 0 | 13 | 26 |
| td-vocab-flow--OAuth2SecurityScheme | Vocabulary | Y |
OAuth2SecurityScheme |
flow: Authorization flow. MUST be included. Type: string (one of code). | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-format--BearerSecurityScheme | Vocabulary | N |
BearerSecurityScheme |
format: Specifies format of security authentication information. MAY be included. Type: string (e.g., jwt, cwt, jwe, or jws). | td-vocabulary |
4 | 0 | 22 | 26 |
| td-vocab-format--DataSchema | Vocabulary | N |
DataSchema |
format: Allows validation based on a format pattern such as "date-time", "email", "uri", etc. (Also see below.) MAY be included. Type: string. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-forms--InteractionAffordance | Vocabulary | Y |
InteractionAffordance |
forms: Set of form hypermedia controls that describe how an operation can be performed. Forms are serializations of Protocol Bindings. MUST be included. Type: Array of Form. | td-vocabulary |
26 | 0 | 0 | 26 |
| td-vocab-forms--Thing | Vocabulary | N |
Thing |
forms: Set of form hypermedia controls that describe how an operation can be performed. Forms are serializations of Protocol Bindings. In this version of TD, all operations that can be described at the Thing level are concerning how to interact with the Thing's Properties collectively at once. MAY be included. Type: Array of Form. | td-vocabulary |
7 | 0 | 19 | 26 |
| td-vocab-href--Form | Vocabulary | Y |
Form |
href: Target IRI of a link or submission target of a form. MUST be included. Type: anyURI. | td-vocabulary |
26 | 0 | 0 | 26 |
| td-vocab-href--Link | Vocabulary | Y |
Link |
href: Target IRI of a link or submission target of a form. MUST be included. Type: anyURI. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-id--Thing | Vocabulary | N |
Thing |
id: Identifier of the Thing in form of a URI [[RFC3986]] (e.g., stable URI, temporary and mutable URI, URI with local IP address, URN, etc.). MAY be included. Type: anyURI. | td-vocabulary |
26 | 0 | 0 | 26 |
| td-vocab-idempotent--ActionAffordance | Vocabulary | N |
ActionAffordance |
idempotent: Indicates whether the Action is idempotent (=true) or not. Informs whether the Action can be called repeatedly with the same result, if present, based on the same input. MAY be included. Type: boolean. | td-vocabulary |
10 | 0 | 16 | 26 |
| td-vocab-identity--PSKSecurityScheme | Vocabulary | N |
PSKSecurityScheme |
identity: Identifier providing information which can be used for selection or confirmation. MAY be included. Type: string. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-in--APIKeySecurityScheme | Vocabulary | N |
APIKeySecurityScheme |
in: Specifies the location of security authentication information. MAY be included. Type: string (one of header, query, body, or cookie). | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-in--BasicSecurityScheme | Vocabulary | N |
BasicSecurityScheme |
in: Specifies the location of security authentication information. MAY be included. Type: string (one of header, query, body, or cookie). | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-in--BearerSecurityScheme | Vocabulary | N |
BearerSecurityScheme |
in: Specifies the location of security authentication information. MAY be included. Type: string (one of header, query, body, or cookie). | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-in--DigestSecurityScheme | Vocabulary | N |
DigestSecurityScheme |
in: Specifies the location of security authentication information. MAY be included. Type: string (one of header, query, body, or cookie). | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-input--ActionAffordance | Vocabulary | N |
ActionAffordance |
input: Used to define the input data schema of the Action. MAY be included. Type: DataSchema. | td-vocabulary |
10 | 0 | 16 | 26 |
| td-vocab-instance--VersionInfo | Vocabulary | Y |
VersionInfo |
instance: Provides a version indicator of this TD instance. MUST be included. Type: string. | td-vocabulary |
6 | 0 | 20 | 26 |
| td-vocab-items--ArraySchema | Vocabulary | N |
ArraySchema |
items: Used to define the characteristics of an array. MAY be included. Type: DataSchema or Array of DataSchema. | td-vocabulary |
9 | 0 | 17 | 26 |
| td-vocab-links--Thing | Vocabulary | N |
Thing |
links: Provides Web links to arbitrary resources that relate to the specified Thing Description. MAY be included. Type: Array of Link. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-maxItems--ArraySchema | Vocabulary | N |
ArraySchema |
maxItems: Defines the maximum number of items that have to be in the array. MAY be included. Type: unsignedInt. | td-vocabulary |
4 | 0 | 22 | 26 |
| td-vocab-maximum--IntegerSchema | Vocabulary | N |
IntegerSchema |
maximum: Specifies a maximum numeric value. Only applicable for associated number or integer types. MAY be included. Type: integer. | td-vocabulary |
6 | 1 | 19 | 26 |
| td-vocab-maximum--NumberSchema | Vocabulary | N |
NumberSchema |
maximum: Specifies a maximum numeric value. Only applicable for associated number or integer types. MAY be included. Type: double. | td-vocabulary |
9 | 0 | 17 | 26 |
| td-vocab-minItems--ArraySchema | Vocabulary | N |
ArraySchema |
minItems: Defines the minimum number of items that have to be in the array. MAY be included. Type: unsignedInt. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-minimum--IntegerSchema | Vocabulary | N |
IntegerSchema |
minimum: Specifies a minimum numeric value. Only applicable for associated number or integer types. MAY be included. Type: integer. | td-vocabulary |
7 | 1 | 18 | 26 |
| td-vocab-minimum--NumberSchema | Vocabulary | N |
NumberSchema |
minimum: Specifies a minimum numeric value. Only applicable for associated number or integer types. MAY be included. Type: double. | td-vocabulary |
9 | 0 | 17 | 26 |
| td-vocab-modified--Thing | N |
Thing |
modified: Provides information when the TD instance was last modified. MAY be included. Type: dateTime. | td-vocabulary |
7 | 0 | 19 | 26 | |
| td-vocab-name--APIKeySecurityScheme | Vocabulary | N |
APIKeySecurityScheme |
name: Name for query, header, or cookie parameters. MAY be included. Type: string. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-name--BasicSecurityScheme | Vocabulary | N |
BasicSecurityScheme |
name: Name for query, header, or cookie parameters. MAY be included. Type: string. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-name--BearerSecurityScheme | Vocabulary | N |
BearerSecurityScheme |
name: Name for query, header, or cookie parameters. MAY be included. Type: string. | td-vocabulary |
1 | 0 | 25 | 26 |
| td-vocab-name--DigestSecurityScheme | Vocabulary | N |
DigestSecurityScheme |
name: Name for query, header, or cookie parameters. MAY be included. Type: string. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-observable--PropertyAffordance | Vocabulary | N |
PropertyAffordance |
observable: A hint that indicates whether Servients hosting the Thing and Intermediaries should provide a Protocol Binding that supports the observeproperty operation for this Property. MAY be included. Type: boolean. | td-vocabulary |
11 | 0 | 15 | 26 |
| td-vocab-oneOf--DataSchema | Vocabulary | N |
DataSchema |
oneOf: Used to ensure that the data is valid against one of the specified schemas in the array. MAY be included. Type: Array of DataSchema. | td-vocabulary |
4 | 0 | 22 | 26 |
| td-vocab-op--Form | Vocabulary | N |
Form |
op: Indicates the semantic intention of performing the operation(s) described by the form. For example, the Property interaction allows get and set operations. The protocol binding may contain a form for the get operation and a different form for the set operation. The op attribute indicates which form is for which and allows the client to select the correct form for the operation required. op can be assigned one or more interaction verb(s) each representing a semantic intention of an operation. MAY be included. Type: string or Array of string (one of readproperty, writeproperty, observeproperty, unobserveproperty, invokeaction, subscribeevent, unsubscribeevent, readallproperties, writeallproperties, readmultipleproperties, or writemultipleproperties). | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-op--Form_invokeaction | Y | Type: MUST be string or Array of string (invokeaction). | 8 | 0 | 18 | 26 | |||
| td-vocab-op--Form_observeproperty | Y | Type: MUST be string or Array of string (observeproperty). | 6 | 0 | 20 | 26 | |||
| td-vocab-op--Form_readallproperties | Y | Type: MUST be string or Array of string (readallproperties). | 7 | 0 | 19 | 26 | |||
| td-vocab-op--Form_readmultipleproperties | Y | Type: MUST be string or Array of string (readmultipleproperties). | 2 | 0 | 24 | 26 | |||
| td-vocab-op--Form_readproperty | Y | Type: MUST be string or Array of string (readproperty). | 13 | 0 | 13 | 26 | |||
| td-vocab-op--Form_subscribeevent | Y | Type: MUST be string or Array of string (subscribeevent). | 5 | 0 | 21 | 26 | |||
| td-vocab-op--Form_unobserveproperty | Y | Type: MUST be string or Array of string (unobserveproperty). | 2 | 0 | 24 | 26 | |||
| td-vocab-op--Form_unsubscribeevent | Y | Type: MUST be string or Array of string (unsubscribeevent). | 2 | 0 | 24 | 26 | |||
| td-vocab-op--Form_writeallproperties | Y | Type: MUST be string or Array of string (writeallproperties). | 3 | 0 | 23 | 26 | |||
| td-vocab-op--Form_writemultipleproperties | Y | Type: MUST be string or Array of string (writemultipleproperties). | 2 | 0 | 24 | 26 | |||
| td-vocab-op--Form_writeproperty | Y | Type: MUST be string or Array of string (writeproperty). | 5 | 0 | 21 | 26 | |||
| td-vocab-output--ActionAffordance | Vocabulary | N |
ActionAffordance |
output: Used to define the output data schema of the Action. MAY be included. Type: DataSchema. | td-vocabulary |
4 | 0 | 22 | 26 |
| td-vocab-properties--ObjectSchema | Vocabulary | N |
ObjectSchema |
properties: Data schema nested definitions. MAY be included. Type: Map of DataSchema. | td-vocabulary |
14 | 0 | 12 | 26 |
| td-vocab-properties--Thing | Vocabulary | N |
Thing |
properties: All Property-based Interaction Affordances of the Thing. MAY be included. Type: Map of PropertyAffordance. | td-vocabulary |
23 | 0 | 3 | 26 |
| td-vocab-proxy--SecurityScheme | Vocabulary | N |
SecurityScheme |
proxy: URI of the proxy server this security configuration provides access to. If not given, the corresponding security configuration is for the endpoint. MAY be included. Type: anyURI. | td-vocabulary |
1 | 0 | 25 | 26 |
| td-vocab-qop--DigestSecurityScheme | Vocabulary | N |
DigestSecurityScheme |
qop: Quality of protection. MAY be included. Type: string (one of auth, or auth-int). | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-readOnly--DataSchema | Vocabulary | N |
DataSchema |
readOnly: Boolean value that is a hint to indicate whether a property interaction / value is read only (=true) or not (=false). MAY be included. Type: boolean. | td-vocabulary |
19 | 0 | 7 | 26 |
| td-vocab-refresh--OAuth2SecurityScheme | Vocabulary | N |
OAuth2SecurityScheme |
refresh: URI of the refresh server. MAY be included. Type: anyURI. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-rel--Link | Vocabulary | N |
Link |
rel: A link relation type identifies the semantics of a link. MAY be included. Type: string. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-required--ObjectSchema | Vocabulary | N |
ObjectSchema |
required: Defines which members of the object type are mandatory. MAY be included. Type: Array of string. | td-vocabulary |
6 | 0 | 20 | 26 |
| td-vocab-response--Form | Vocabulary | N |
Form |
response: This optional term can be used if, e.g., the output communication metadata differ from input metadata (e.g., output contentType differ from the input contentType). The response name contains metadata that is only valid for the response messages. MAY be included. Type: ExpectedResponse. | td-vocabulary |
3 | 0 | 23 | 26 |
| td-vocab-safe--ActionAffordance | Vocabulary | N |
ActionAffordance |
safe: Signals if the Action is safe (=true) or not. Used to signal if there is no internal state (cf. resource state) is changed when invoking an Action. In that case responses can be cached as example. MAY be included. Type: boolean. | td-vocabulary |
8 | 0 | 18 | 26 |
| td-vocab-scheme--SecurityScheme | Vocabulary | Y |
SecurityScheme |
scheme: Identification of the security mechanism being configured. MUST be included. Type: string (e.g., nosec, basic, digest, bearer, psk, oauth2, or apikey). | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-scheme--SecurityScheme_apikey | Vocabulary | N |
APIKeySecurityScheme |
scheme: Identification of security mechanism being configured MAY be set to "apikey". |
td-vocab-scheme--SecurityScheme |
2 | 0 | 24 | 26 |
| td-vocab-scheme--SecurityScheme_basic | Vocabulary | N |
BasicSecurityScheme |
scheme: Identification of security mechanism being configured MAY be set to "basic". |
td-vocab-scheme--SecurityScheme |
12 | 0 | 14 | 26 |
| td-vocab-scheme--SecurityScheme_bearer | Vocabulary | N |
BearerSecurityScheme |
scheme: Identification of security mechanism being configured MAY be set to "bearer". |
td-vocab-scheme--SecurityScheme |
4 | 0 | 22 | 26 |
| td-vocab-scheme--SecurityScheme_digest | Vocabulary | N |
DigestSecurityScheme |
scheme: Identification of security mechanism being configured MAY be set to "digest". |
td-vocab-scheme--SecurityScheme |
5 | 0 | 21 | 26 |
| td-vocab-scheme--SecurityScheme_nosec | Vocabulary | N |
NoSecurityScheme |
scheme: Identification of security mechanism being configured MAY be set to "nosec". |
td-vocab-scheme--SecurityScheme |
22 | 0 | 4 | 26 |
| td-vocab-scheme--SecurityScheme_oauth2 | Vocabulary | N |
OAuth2SecurityScheme |
scheme: Identification of security mechanism being configured MAY be set to "oauth2". |
td-vocab-scheme--SecurityScheme |
2 | 0 | 24 | 26 |
| td-vocab-scheme--SecurityScheme_psk | Vocabulary | N |
PSKSecurityScheme |
scheme: Identification of security mechanism being configured MAY be set to "psk". |
td-vocab-scheme--SecurityScheme |
2 | 0 | 24 | 26 |
| td-vocab-scopes--Form | Vocabulary | N |
Form |
scopes: Set of authorization scope identifiers provided as an array. These are provided in tokens returned by an authorization server and associated with forms in order to identify what resources a client may access and how. The values associated with a form should be chosen from those defined in an OAuth2SecurityScheme active on that form. MAY be included. Type: string or Array of string. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-scopes--OAuth2SecurityScheme | Vocabulary | N |
OAuth2SecurityScheme |
scopes: Set of authorization scope identifiers provided as an array. These are provided in tokens returned by an authorization server and associated with forms in order to identify what resources a client may access and how. The values associated with a form should be chosen from those defined in an OAuth2SecurityScheme active on that form. MAY be included. Type: string or Array of string. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-security--Form | Vocabulary | N |
Form |
security: Set of security definition names, chosen from those defined in securityDefinitions. These must all be satisfied for access to resources. MAY be included. Type: string or Array of string. | td-vocabulary |
6 | 0 | 20 | 26 |
| td-vocab-security--Thing | Vocabulary | Y |
Thing |
security: Set of security definition names, chosen from those defined in securityDefinitions. These must all be satisfied for access to resources. MUST be included. Type: string or Array of string. | td-vocabulary |
26 | 0 | 0 | 26 |
| td-vocab-securityDefinitions--Thing | Vocabulary | Y |
Thing |
securityDefinitions: Set of named security configurations (definitions only). Not actually applied unless names are used in a security name-value pair. MUST be included. Type: Map of SecurityScheme. | td-vocabulary |
26 | 0 | 0 | 26 |
| td-vocab-subprotocol--Form | Vocabulary | N |
Form |
subprotocol: Indicates the exact mechanism by which an interaction will be accomplished for a given protocol when there are multiple options. For example, for HTTP and Events, it indicates which of several available mechanisms should be used for asynchronous notifications such as long polling (longpoll), WebSub [[websub]] (websub), Server-Sent Events [[eventsource]] (sse). Please note that there is no restriction on the subprotocol selection and other mechanisms can also be announced by this subprotocol term. MAY be included. Type: string (e.g., longpoll, websub, or sse). | td-vocabulary |
4 | 0 | 22 | 26 |
| td-vocab-subscription--EventAffordance | Vocabulary | N |
EventAffordance |
subscription: Defines data that needs to be passed upon subscription, e.g., filters or message format for setting up Webhooks. MAY be included. Type: DataSchema. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-support--Thing | Vocabulary | N |
Thing |
support: Provides information about the TD maintainer as URI scheme (e.g., mailto [[?RFC6068]], tel [[?RFC3966]], https). MAY be included. Type: anyURI. | td-vocabulary |
8 | 0 | 18 | 26 |
| td-vocab-title--DataSchema | Vocabulary | N |
DataSchema |
title: Provides a human-readable title (e.g., display a text for UI representation) based on a default language. MAY be included. Type: string. | td-vocabulary |
9 | 0 | 17 | 26 |
| td-vocab-title--InteractionAffordance | Vocabulary | N |
InteractionAffordance |
title: Provides a human-readable title (e.g., display a text for UI representation) based on a default language. MAY be included. Type: string. | td-vocabulary |
10 | 0 | 16 | 26 |
| td-vocab-title--Thing | Vocabulary | Y |
Thing |
title: Provides a human-readable title (e.g., display a text for UI representation) based on a default language. MUST be included. Type: string. | td-vocabulary |
26 | 0 | 0 | 26 |
| td-vocab-titles--DataSchema | Vocabulary | N |
DataSchema |
titles: Provides multi-language human-readable titles (e.g., display a text for UI representation in different languages). MAY be included. Type: MultiLanguage. | td-vocabulary |
4 | 0 | 22 | 26 |
| td-vocab-titles--InteractionAffordance | Vocabulary | N |
InteractionAffordance |
titles: Provides multi-language human-readable titles (e.g., display a text for UI representation in different languages). MAY be included. Type: MultiLanguage. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-titles--Thing | Vocabulary | N |
Thing |
titles: Provides multi-language human-readable titles (e.g., display a text for UI representation in different languages). MAY be included. Type: MultiLanguage. | td-vocabulary |
4 | 0 | 22 | 26 |
| td-vocab-token--OAuth2SecurityScheme | Vocabulary | N |
OAuth2SecurityScheme |
token: URI of the token server. MAY be included. Type: anyURI. | td-vocabulary |
2 | 0 | 24 | 26 |
| td-vocab-type--DataSchema | Vocabulary | N |
DataSchema |
type: Assignment of JSON-based data types compatible with JSON Schema (one of boolean, integer, number, string, object, array, or null). MAY be included. Type: string (one of object, array, string, number, integer, boolean, or null). | td-vocabulary |
3 | 1 | 23 | 27 |
| td-vocab-type--DataSchema_array | Y | type: Assignment of JSON-based data types MUST be compatible with JSON Schema (array). | 9 | 0 | 17 | 26 | |||
| td-vocab-type--DataSchema_boolean | Y | type: Assignment of JSON-based data types MUST be compatible with JSON Schema (boolean). | 11 | 0 | 15 | 26 | |||
| td-vocab-type--DataSchema_integer | Y | type: Assignment of JSON-based data types MUST be compatible with JSON Schema (integer). | 10 | 1 | 15 | 26 | |||
| td-vocab-type--DataSchema_null | Y | type: Assignment of JSON-based data types MUST be compatible with JSON Schema (null). | 3 | 0 | 23 | 26 | |||
| td-vocab-type--DataSchema_number | Y | type: Assignment of JSON-based data types MUST be compatible with JSON Schema (number). | 15 | 0 | 11 | 26 | |||
| td-vocab-type--DataSchema_object | Y | type: Assignment of JSON-based data types MUST be compatible with JSON Schema (object). | 14 | 0 | 12 | 26 | |||
| td-vocab-type--DataSchema_string | Y | type: Assignment of JSON-based data types MUST be compatible with JSON Schema (string). | 15 | 0 | 11 | 26 | |||
| td-vocab-type--Link | Vocabulary | N |
Link |
type: Target attribute providing a hint indicating what the media type [[RFC2046]] of the result of dereferencing the link should be. MAY be included. Type: string. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-unit--DataSchema | Vocabulary | N |
DataSchema |
unit: Provides unit information that is used, e.g., in international science, engineering, and business. MAY be included. Type: string. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-uriVariables--InteractionAffordance | Vocabulary | N |
InteractionAffordance |
uriVariables: Define URI template variables as collection based on DataSchema declarations. MAY be included. Type: Map of DataSchema. | td-vocabulary |
5 | 0 | 21 | 26 |
| td-vocab-version--Thing | Vocabulary | N |
Thing |
version: Provides version information. MAY be included. Type: VersionInfo. | td-vocabulary |
6 | 0 | 20 | 26 |
| td-vocab-writeOnly--DataSchema | Vocabulary | N |
DataSchema |
writeOnly: Boolean value that is a hint to indicate whether a property interaction / value is write only (=true) or not (=false). MAY be included. Type: boolean. | td-vocabulary |
12 | 0 | 14 | 26 |
The following assertions have been manually validated by the implementers.
| ID | Category | Req | Context | Assertion | Parent | Results | |||
|---|---|---|---|---|---|---|---|---|---|
| P | F | N | T | ||||||
| bindings-requirements-scheme | Behavior | Y |
Form |
Every form in a WoT Thing Description MUST follow the requirements of the Protocol Binding indicated by the URI scheme of its href member. | 13 | 0 | 3 | 16 | |
| bindings-server-accept | Behavior | Y | (TD Producer) |
Every form in a WoT Thing Description MUST accurately describe requests (including request headers, if present) accepted by the Thing in an interaction. | 14 | 0 | 3 | 17 | |
| client-data-schema | Behavior | Y | (TD Consumer) |
A Thing acting as a Consumer when interacting with another target Thing described in a WoT Thing Description MUST generate data organized according to the data schemas given in the corresponding interactions. | 6 | 0 | 9 | 15 | |
| client-data-schema-accept-extras | Behavior | Y | (TD Consumer) |
A Thing acting as a Consumer when interacting with another Thing MUST accept without error any additional data not described in the data schemas given in the Thing Description of the target Thing. | 5 | 1 | 9 | 15 | |
| client-data-schema-no-extras | Behavior | Y | (TD Consumer) |
A Thing acting as a Consumer when interacting with another Thing MUST NOT generate data not described in the data schemas given in the Thing Description of that Thing. | 5 | 1 | 9 | 15 | |
| client-uri-template | Behavior | Y | (TD Consumer) |
A Thing acting as a Consumer when interacting with another Thing MUST generate URIs according to the URI Templates, base URIs, and form href parameters given in the Thing Description of the target Thing. | 3 | 0 | 12 | 15 | |
| iana-security-alter | IANA | N | (TD Consumer) |
For this reason, Consumer again SHOULD vet and cache remote contexts before allowing the system to use it. | 1 | 0 | 6 | 7 | |
| iana-security-execution | IANA | N | (TD Consumer) |
Since WoT Thing Description is intended to be a pure data exchange format for Thing metadata, the serialization SHOULD NOT be passed through a code execution mechanism such as JavaScript's eval() function to be parsed. | 5 | 0 | 2 | 7 | |
| iana-security-expansion | IANA | N | (TD Consumer) |
Consumers SHOULD treat any TD metadata with due skepticism. | 1 | 0 | 4 | 5 | |
| iana-security-remote | IANA | N | (TD Consumer) |
While implementations on resource-constrained devices are expected to perform raw JSON processing (as opposed to JSON-LD processing), implementations in general SHOULD statically cache vetted versions of their supported context extensions and not to follow links to remote contexts. | 3 | 0 | 5 | 8 | |
| server-data-schema | Behavior | Y | (TD Producer) |
A WoT Thing Description MUST accurately describe the data returned and accepted by each interaction. | 17 | 1 | 3 | 21 | |
| server-data-schema-extras | Behavior | N | (TD Producer) |
A Thing MAY return additional data from an interaction even when such data is not described in the data schemas given in its WoT Thing Description. | 7 | 1 | 13 | 21 | |
| server-uri-template | Behavior | Y | (TD Producer) |
URI Templates, base URIs, and href members in a WoT Thing Description MUST accurately describe the WoT Interface of the Thing. | 10 | 0 | 11 | 21 | |
| td-context-default-language-direction-heuristic | Language | N | (TD Consumer) |
If no language tag is given, the base direction SHOULD be inferred through first-strong heuristics or detection algorithms such as the CLDR Likely Subtags [[?LDML]]. | 2 | 0 | 9 | 11 | |
| td-context-default-language-direction-independence | Language | Y | (TD Consumer) |
However, when interpreting human-readable text, each human-readable string value MUST be processed independently. | 2 | 0 | 9 | 11 | |
| td-context-default-language-direction-inference | Language | N | (TD Consumer) |
Outside of MultiLanguage Maps, the base direction MAY be inferred from the language tag of the default language. | 1 | 0 | 9 | 10 | |
| td-context-ns-multilanguage-text-direction-infer | Language | N | (TD Consumer) |
Inside of MultiLanguage Maps, the base direction of each value of the name-value pairs MAY be inferred from the language tag given in the corresponding name. | 1 | 0 | 9 | 10 | |
| td-default-alg | Default | Y |
BearerSecurityScheme |
The value associated with member " alg " if not given MUST be assumed to have the default value "ES256". |
td-serialization-default-values |
3 | 0 | 10 | 13 |
| td-default-contentType | Default | Y |
Form |
The value associated with member " contentType " if not given MUST be assumed to have the default value "application/json". |
td-serializiation-default-values |
11 | 0 | 6 | 17 |
| td-default-format | Default | Y |
BearerSecurityScheme |
The value associated with member " format " if not given MUST be assumed to have the default value "jwt". |
td-serialization-default-values |
4 | 0 | 13 | 17 |
| td-default-http-method | Default | Y |
Form |
When no method is indicated in a form representing an Protocol Binding based on HTTP, a Default Value MUST be assumed as shown in the following table. |
td-serializiation-default-values |
3 | 0 | 5 | 8 |
| td-default-http-method_get | Default | Y |
htv:methodName |
The value associated with member "GET" if not given MUST be assumed to have the default value " Form with operation type readproperty, readallproperties, readmultipleproperties ". |
td-serialization-default-values |
4 | 0 | 4 | 8 |
| td-default-http-method_post | Default | Y |
htv:methodName |
The value associated with member "POST" if not given MUST be assumed to have the default value " Form with operation type invokeaction ". |
td-serialization-default-values |
3 | 0 | 5 | 8 |
| td-default-http-method_put | Default | Y |
htv:methodName |
The value associated with member "PUT" if not given MUST be assumed to have the default value " Form with operation type writeproperty, writeallproperties, writemultipleproperties ". |
td-serialization-default-values |
4 | 0 | 4 | 8 |
| td-default-idempotent | Default | Y |
ActionAffordance |
The value associated with member " idempotent " if not given MUST be assumed to have the default value "false". |
td-serializiation-default-values |
2 | 0 | 14 | 16 |
| td-default-in-apikey | Default | Y |
APIKeySecurityScheme |
The value associated with member " in " if not given MUST be assumed to have the default value "query". |
td-serialization-default-values |
2 | 0 | 8 | 10 |
| td-default-in-basic | Default | Y |
BasicSecurityScheme |
The value associated with member " in " if not given MUST be assumed to have the default value "header". |
td-serialization-default-values |
2 | 0 | 8 | 10 |
| td-default-in-bearer | Default | Y |
BearerSecurityScheme |
The value associated with member " in " if not given MUST be assumed to have the default value "header". |
td-serialization-default-values |
4 | 0 | 6 | 10 |
| td-default-in-digest | Default | Y |
DigestSecurityScheme |
The value associated with member " in " if not given MUST be assumed to have the default value "header". |
td-serialization-default-values |
2 | 0 | 8 | 10 |
| td-default-op-actions | Default | Y |
Form |
The value associated with member " op " if not given MUST be assumed to have the default value "invokeaction". |
td-serialization-default-values |
2 | 0 | 11 | 13 |
| td-default-op-events | Default | Y |
Form |
The value associated with member " op " if not given MUST be assumed to have the default value "subscribeevent". |
td-serialization-default-values |
2 | 0 | 11 | 13 |
| td-default-op-properties | Default | Y |
Form |
The value associated with member " op " if not given MUST be assumed to have the default value "Array of string with the elements readproperty and writeproperty ". |
td-serialization-default-values |
4 | 0 | 9 | 13 |
| td-default-qop | Default | Y |
DigestSecurityScheme |
The value associated with member " qop " if not given MUST be assumed to have the default value "auth". |
td-serialization-default-values |
2 | 0 | 12 | 14 |
| td-default-readOnly | Default | Y |
PropertyAffordance DataSchema |
The value associated with member " readOnly " if not given MUST be assumed to have the default value "false". |
td-serializiation-default-values |
11 | 0 | 5 | 16 |
| td-default-safe | Default | Y |
ActionAffordance |
The value associated with member " safe " if not given MUST be assumed to have the default value "false". |
td-serializiation-default-values |
3 | 0 | 14 | 17 |
| td-default-writeOnly | Default | Y |
PropertyAffordance DataSchema |
The value associated with member " writeOnly " if not given MUST be assumed to have the default value "false". |
td-serializiation-default-values |
11 | 0 | 5 | 16 |
| td-expectedResponse-contentType | Syntax | Y |
ActionAffordance Form |
If the content type of the expected response differs from the content type of the form, the Form instance MUST include a name-value pair with the name response. | td-actions |
3 | 0 | 9 | 12 |
| td-expectedResponse-default-contentType | Default | Y |
ActionAffordance Form |
If no response name-value pair is provided, it MUST be assumed that the content type of the response is equal to the content type assigned to the Form instance. |
td-serialization-default-values |
9 | 0 | 3 | 12 |
| td-form-protocolbindings | Syntax | N |
Form |
If required, form objects MAY be supplemented with protocol-specific Vocabulary Terms identified with a prefix. | td-forms |
11 | 0 | 9 | 20 |
| td-format-validation-other-values | Syntax | N |
DataSchema |
When a value that is not found in the known set of values is assigned to format, such a validation SHOULD succeed. | td-data-schema |
4 | 0 | 8 | 12 |
| td-json-open | Syntax | Y |
Thing |
TDs MUST be serialized according to the requirements defined in Section 8.1 of RFC8259 [[!RFC8259]] for open ecosystems. | 2 | 0 | 9 | 11 | |
| td-json-open_accept-byte-order | Syntax | N |
Thing |
TD Processors MAY ignore the presence of a byte order mark rather than treating it as an error. | td-json-open |
2 | 0 | 9 | 11 |
| td-json-open_no-byte-order | Syntax | Y |
Thing |
Implementations MUST NOT add a byte order mark (U+FEFF) to the beginning of a TD document. | td-json-open |
10 | 0 | 2 | 12 |
| td-ns-multilanguage-content-negotiation | Behavior | Y | (TD Producer) |
In cases where the default language has been negotiated, an @language member MUST be present to indicate the result of the negotiation and the corresponding default language of the returned content. | 2 | 0 | 10 | 12 | |
| td-ns-multilanguage-content-negotiation-no-multi | Behavior | N | (TD Producer) |
When the default language has been negotiated successfully, TD documents SHOULD include the appropriate matching values for the members title and description in preference to MultiLanguage objects in titles and descriptions members. | 2 | 0 | 10 | 12 | |
| td-ns-multilanguage-content-negotiation-optional | Behavior | N | (TD Producer) |
Note however that Things MAY choose to not support such dynamically-generated TDs nor to support language negotiation (e.g., because of resource constraints). | 3 | 0 | 8 | 11 | |
| td-processor-serialization | Syntax | Y | (TD Processor) |
A TD Processor MUST be able to serialize Thing Descriptions into the JSON format [[!RFC8259]] and/or deserialize Thing Descriptions from that format, according to the rules noted in and . | 8 | 0 | 2 | 10 | |
| td-security-binding | Behavior | Y |
Thing |
If a Thing requires a specific access mechanism for an interaction, that mechanism MUST be specified in the security configuration of the Thing Description. | td-security |
9 | 0 | 4 | 13 |
| td-security-no-extras | Behavior | Y |
Thing |
If a Thing does not require a specific access mechanism for an interaction, that mechanism MUST NOT be specified in the security configuration of the Thing Description. | td-security |
10 | 0 | 8 | 18 |
| td-vocabulary-defaults | Vocabulary | Y |
Thing |
When assignments in a TD are missing, a TD Processor MUST follow the Default Value assignments expressed in the table of . | td-vocabulary |
11 | 0 | 2 | 13 |
| well-known-operation-types-only | Syntax | N |
Form |
operations types SHOULD NOT be arbitrarily set by servients. | 9 | 0 | 3 | 12 | |
The Web of Things Working Group would like to acknowledge the contributions to the making of this document from the following individuals in various capacities.