Consider creating a Constrained Profile

[benfrancis]

The First Public Working Draft says the goals of the WoT Core Profile are:

• guarantee interoperability among all implementations of the profile.
• limit the implementation complexity for resource constrained devices.
• ensure that a thing description is also useful for a human reader.

Looking at this set of goals, I would suggest that the first goal has not yet been met by this draft of the specification and the second and third goals are causing conflicting requirements.

As mentioned in #24, it is not possible to guarantee interoperability between all implementations of a profile unless all implementations are required to support at least one protocol (and serialisation format). If a WoT producer only supports CoAP + CBOR and a WoT consumer only supports HTTP + JSON then the fact that they both share the same abstract data model is irrelevant, they will be not be able to communicate with each other. Not requiring implementations of the Core Profile to support at least one protocol therefore does not meet the requirement of out of the box interoperability as defined in the Abstract of the specification.

I would also suggest that the goal of making thing descriptions human readable and the goal of limiting implementation complexity for constrained devices cause too many conflicting requirements. On the one hand the Core Profile limits the length of strings in an attempt to reduce resource needs for resource constrained devices, but on the other hand it adds a large number of mandatory fields and human readable strings which add to those resource needs.

I propose that both of these problems could be solved by splitting the Core Profile into two separate profiles:

1. Core Profile - requiring support for HTTP + JSON, with a focus on human readability (replacing the current Protocol Binding based on HTTP section of the Thing Description specification, fixing #11)
2. Constrained Profile - requiring support for CoAP + CBOR, with a focus on reducing implementation complexity for resource constrained devices.

See also: https://lists.w3.org/Archives/Public/public-wot-wg/2020Dec/0025.html

[mlagally]

Arch call on 21.1.:

• profile spec is prescriptive vs. TD spec, which is descriptive
• we cannot add prescriptive constraints to the TD spec without breaking compatibility
• we will focus on the core data model for the next couple of calls
• agreed on limitation of depth of max 5 in the data model
• profile spec has conformance guarantees and rules that can be validated
• an implementable profile has at least one protocol binding
• we need to define a prescriptive protocol binding for HTTP (somewhere)
• constraints on protocol bindings for MQTT / CoAP + CBOR binding should be considered after we conclude on HTTP

[benfrancis]

I think this issue has largely been resolved at this point, because the "core profile" was split into different HTTP-based profiles which are not specifically targeted at constrained devices.

I'm going to rename the issue to keep the proposal for a dedicated constrained profile which uses CoAP & CBOR instead of HTTP & JSON.