W3C

Web of Things (WoT) Thing Description:
Implementation Report

Version: 6 Dec 2019

Editors:
Michael McCool (Intel)
Ege Korkan (Siemens / Technical University of Munich)


Table of Contents

1. Introduction

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).

1.1 Implementation Report objectives

1.2 Implementation Report non-objectives

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.

2. Work during the Candidate Recommendation period

During the CR period, the Working Group carried out the following activities:

  1. Clarification and improvement through the exposition of the specification
  2. Disposing of comments that were communicated to the WG during the CR period. These comments and their resolution are detailed in the GitHub Issue tracker with the label CR period.
  3. Preparation of this Implementation Report.

3. Participating in the Implementation Report

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.

4. Entrance criteria for the Proposed Recommendation phase

The Web of Things (WoT) Working Group established the following entrance criteria for the Proposed Recommendation phase in the Request for CR:

  1. Sufficient reports of implementation experience have been gathered to demonstrate that Things can be described by Thing Descriptions in sufficient detail to allow interoperabilty.
  2. Specific Implementation Report requirements (outlined below) have been met.
  3. The Working Group has formally addressed and responded to all public comments received by the Working Group.

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.

5. Implementation Report requirements

5.1 Detailed requirements

  1. Testimonials from implementers are included in the IR when provided to document the utility and implementability of the specification.
  2. IR must cover all specified features in the specification. For each feature the IR should indicate:
  3. Feature status is a factor in test coverage in the report:

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.

5.2 Notes on testing

  1. An implementer report must indicate the outcome of evaluating the implementation with respect to each of the assertions defined in the specification. Possible outcomes are pass, fail, or not-impl (not implemented).

5.3 Out of scope

This implementation Report will not cover:

6. Systems

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.

SmartThings

Three implementations were created, all of which are TD Producers and demonstrate how existing ecosystems can be supported.

Implementation 1: TD Producer

TD which exposes a dimmable light on the Philips Hue hub.

Implementation 2: TD Producer

TD which exposes a dimmable, color control, light on the IKEA Tradfri hub.

Implementation 3: TD Producer

TD which exposes a Motion sensor and Illuminance sensor supported by Node-Red.

ERCIM

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.

Arena Client: TD Consumer

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 WebHub: TD Producer

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 Limited

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.

Fujitsu WoT gateway: TD Producer and Consumer

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.

WoT sensors: TD Producer

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.

Legacy devices with WoT adapters: TD Producer

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.

Node-RED including Node generators: TD Consumer

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, Ltd.

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 for Node-RED: TD Consumer

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 Technologies

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.

WoT-enabled Californium (Cf) CoAP framework: TD Producer

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.

Meta-Interaction Thing: TD Producer

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 Corporation

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.

Security Proxy: Shared Component

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.

OCF Metadata Translator: TD Producer

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

  1. ON\OFF Lights (various: MOSFET, Relay, LEDs),
  2. RGB Light,
  3. Potentiometer (analog input),
  4. Toggle Switch,
  5. Pushbutton,
  6. IR Motion Sensor,
  7. Illuminance Sensor, and
  8. Buzzer.
There were also multiple instances of many of these devices, each given unique identifiers.

WebSpeak: TD Producer

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.

Simple Web Camera: TD Producer

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.

Object Identifier: TD Producer

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 Corporation

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.

Thing Description to Device Model Converters: Shared Component

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 Digital Twin Simulator: TD Producer

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 with Oracle Binding: TD Consumer

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 Corporation

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.

Authentication Server: Shared Component

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.

Browser Based Client: TD Consumer

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.

Node-RED Based Client: TD Consumer

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.

WoT Server for Real Devices: TD Producer

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:

  1. Two Home Air Conditioners,
  2. One robotics cleaner,
  3. One set of Philips Hue Lighting and
  4. Two LED bulletin boards.
This implementation is based on Apache HTTP server with plugins written in PHP.

WoT Simulator: TD Producer

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

  1. Home Air Conditioner,
  2. Robotics cleaner,
  3. Philips Hue Lighting and
  4. Simple LED lighting.
This implementation is based on Node.js. This implementation is portable and also can be run on a local machine such as a Raspberry Pi.

Siemens AG

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.

node-wot: TD Consumer and Producer

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).

Thingweb Directory: TD Consumer and Producer

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: TD Consumer

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

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.

Bare Micropython Light Sensor: TD Producer

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.

Python Flask: TD Producer

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.

MQTT Publisher: TD Producer

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.

MQTT Publisher with Retain: TD Producer

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.

Philips HUE: TD Producer

TDs for different HUE devices, including the Bridge. These TDs show that we can describe already existing devices with TDs

7. Security

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.

8. Test results

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:

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.

8.1 Automated Validation Results

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_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-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-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-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-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-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-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-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

8.2 Manual validation results

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

Appendix

Acknowledgements

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.