Profile Requirements

The following requirements were identified by the WoT profile task force and are addressed by the Profile 1.0 specification.

Interoperability

This is the most important objective of the profile. A TD Consumer satisfying the requirements of a profile should be able to process any TD also satisfying the profile and should be able to correctly interact with all affordances of the Thing such a TD describes.

This implies that a profile has three parts:

Restrictions on TDs
Implementation requirements, constraints and behavioral assertions for Consumers
Implementation requirements, constraints and behavioral assertions on Things

Note: The WoT HTTP Basic Profile does not prevent a TD to have forms for additional protocols, but these can be ignored by compliant consumers, and could be removed without affecting profile conformance and compatibility. This may be useful for consumers that support multiple profiles.

Limit and reduce complexity

Complexity addresses at least the following two things to simplify the development and reduce the implementation effort:

Implementation complexity on a thing and consumer, e.g. eliminating the need of RDF processing, but still permitting semantic annotations.
Simplifying thing description to have fewer variations.
Limiting the effort for JSON implementation.

No Ambiguities, select single choice

Get rid of ambiguities, i.e. clarify specifications to define interpretation of a TD and behavior of the thing and consumer.

Examples are the choice of properties vs. actions, use of PUT or POST for HTTP, observe protocols.

Developer guidance

A profile should help define what needs to be implemented. This requirement also includes behavioral goals and recommendations about best practice for the implementation of Consumers and Things.

Multiple profiles (mechanism)

The mechanism used to indicate that a TD satisfies a profile should be general enough to indicate the TD satisfies the requirements for multiple profiles.

Composable profiles

It should be possible to combine multiple profiles both for production and consumption:

It should be possible to indicate that a consumer can ingest TDs that satisfy one or more profiles, even if each TDs individually only satisfies one profile. For example, a Smart Building may need to use both "constrained" devices and "unconstrained" devices. A gateway consuming TDs should be able to ingest TDs designed for both the constrained and unconstrained contexts.

A Thing that satisfies all the requirements for multiple TDs (for example, a device using protocols common to two different usage contexts) should be able to indicate that.

Validatible TDs

Whether or not a TD satisfies the requirements of a given profile should be verifiable with automated tools. We can use the existing TD JSDON Schema as a basis and reuse the existing tooling (TD-playground)

Identification of profiles

There should be a mechanism to identify which profiles a TD satisfies. This mechanism should be intrinsic to a TD, i.e. be in-band.

Finite set of features and capabilities

A profile should limit the number of options, for example the set of possible protocols, to a finite set, so that a consumer can consume any TD in a given profile with a finite and static code base.