Feedback on WG Charter Draft

[benfrancis]

Following up on the discussion in #856.

Observations:

• My understanding of the "interoperability profiles" topic was that it was proposed in order to provide a solution to the ad-hoc interoperability problem by defining a default common protocol binding that greenfield implementations could use, instead of declaratively defining a custom protocol binding in each Thing Description.
• The current wording of the charter and the WoT Profiles draft by Oracle have expanded this into something more complex where different profiles would be created for different application domains, each with their own data model variations and set of supported protocols. In my view this simply adds another unnecessary layer of abstraction and risks making the interoperability problem worse rather than better by fragmenting the Web of Things into multiple webs of things for different application domains which are not interoperable with one another.
• The "implementation view spec" topic seems to be trying to solve the same problem as "interoperability profiles", but from a different angle.
• "Thing Description Templates" seem like another unnecessary layer of complexity as from what I can tell its use cases can already be fulfilled by capability schemas (e.g. iotschema.org and iot.mozilla.org/schemas) and server-side generation of Thing Descriptions.

Recommendations:

1. The "Interoperability Profiles" and "Implementation View Spec" deliverables could be replaced by:
   1. A "WoT HTTP Protocol Binding" deliverable which builds upon and replaces section 4.2.1 of the Thing Description specification
   2. A mechanism in the Thing Description specification to denote that a given device conforms to an externally defined protocol binding like the one above (e.g. through the @context annotation)
2. The "Thing Description Templates" section could be removed
3. The WoT Architecture document should be an informative note rather than a normative specification
4. Discovery mechanisms for Thing Descriptions could be covered inside the Thing Description specification
5. "Protocol vocabulary" (section 2.10 of the charter) for non-web protocols (e.g. MQTT and the binary version of OPC-UA) should be out of scope

If these recommendations are followed, the Web of Things could be reduced down to just two normative specifications:

1. Thing Description - a file format for describing the capabilities of devices
2. HTTP Protocol Binding - a protocol for communicating with devices

Additional concrete protocol bindings (e.g. a WebSocket sub-protocol or CoAP protocol binding) could be explored through the Interest Group or Community Groups.

[sebastiankb]

The intentions of Ben’s input is to have a (default) subprotocol that follows pre-defined behavior such as for actions with hypermedia content. This is ok if such protocol is specified in a separate document with group consensus and may be called “WoT HTTP Protocol Binding”. The Thing Description document itself should be flexible for multiple protocols (HTTP, MQTT, CoAP, etc) and may propose a default (sub-)protocol like the “WoT HTTP Protocol Binding”. Use cases like Thing2Thing or Thing2Edge (also see WoT Architecture) may override the default by optimized protocols like CoAP, MQTT or industry-based protocols.

[mmccool]

After discussion at 10/10 mtg, main issues have been addressed, closing.