WG Charter Draft (Round 1)

[mmccool]

Round 1: Still more work to do!

A PR for work on the WG Charter Draft. Done so far:

• Opening table (mostly)
• Introduction
• List of work items with one-line description for each
• First draft of detailed descriptions of each work item
• Coordination (eg with Accessibilty, Privacy, etc) - initial version cribbed from IG re-charter draft
• Deliverables (that is, mapping of work items to particular spec documents)

To Do:

• Dates in opening table
• Timeline
• Change Log

[mmccool]

DONE

• Peer-to-peer discovery could build on Introduction+Directory approach [Current text uses more abstract terms "Introduction" and "Exploration"]
• Identity Management topic should be in collaboration with Decentralized ID (DID) and Verifiable Claims groups (if they recharter; but most may move to DID group). [Just DID cited, but no URL yet, still in AC review]
• Work on discovery and identity management should also be in collaboration with Privacy group. [now says discovery and information lifecycle]

[mmccool]

For licensing, should use Document and Software license. [DONE]

[ashimura]

HTML rendered version for review: https://cdn.statically.io/gh/mmccool/wot/wg-charter-draft/charters/wot-wg-charter-draft-2019.html

[mmccool]

Might want to use the following instead, with the env=dev parameter, to make sure that updates are tracked (it's still WIP):
https://cdn.statically.io/gh/mmccool/wot/wg-charter-draft/charters/wot-wg-charter-draft-2019.html?env=dev

[ashimura]

Good point. Thanks a lot, @mmccool !

[mlagally]

This is an impressive piece of work.
Let me provide some initial feedback:

I added several comments to individual sections, here's just a summary:
Some of the descriptions are pretty long, and talk already about specific ways to implement them or put restrictions on the scope (e.g. home profile), which I feel is more at the level of first WG discussions.
We should consider, whether at the charter level, a more generic scope setting would be appropriate.

[mlagally]

I don't think this statement (and profile) should be limited to the consumer context, it is even more important in the industrial context, where typically the number of devices that need to interoperate is much higher.

We should try to involve more members from industrial manufacturers to the WG, to make sure their scenarios and use cases get addressed.

[mmccool]

One difference between my proposal and yours is that I am thinking of verticals (which have a specific set of protocols), you are thinking along the constrained/unconstrained spectrum. Both make sense...

[mmccool]

Anyhow, not saying industrial is not important, it obviously is. I was thinking of changing the deliverable name to simply "Profiles" and putting multiple vertical profiles into one document (assuming we do have vertical profiles).

[mmccool]

I reworded this, but it may not be completely in alignment with what you want. What I wanted to say is that "it just works" is ESPECIALLY relevant in the consumer use case, but is of course highly desirable in the industrial use case also. To discuss.

[mlagally]

Templates provide device abstractions, that can be implemented by various devices in different ways. Not having a protocol binding is the core concept of the template. Various devices that implement the same template (i.e. data model) can be managed, simulated and handled in the same way.
This is important for cloud platforms and gateways, that support various protocols, but manage the devices in a uniform way.

[mmccool]

There are places where it is useful to have a template without protocol bindings or security. However, as a developer, I would need to know what protocol and security schemes I need to support to use a device, so I really just want a template that has everything EXCEPT (a) an id and (b) the "server" part of the URLs. Anyway, let's discuss this point in the call.

[mmccool]

Although... profiles would constrain the protocols and security schemes that can be used, so that MIGHT be enough.

[mmccool]

I left this alone for now, we need to discuss more.

[mmccool]

@mlagally I generally agree that we should not be so specific that we paint ourselves into a corner, but I also think that we need to be specific enough that we are clear about what we are doing. We can always take out detail or move it to an explainer, but I do want to anticipate and address questions readers may have. I like the point-form approach you suggest to help generalize and simplify the presentation and will work through the above suggestions over the next couple of days to sharpen the proposal.

[danielpeintner]

At the moment there is no mentioning about Scripting API. While I agree that at the moment Scripting API must not become a normative deliverable I still think it should me mentioned in section "Other Deliverables"

[mmccool]

Regarding the Scripting API, it was left off in the discussion in Munich for the WG and we agreed to do so, and study it further in the IG first. But I looked, and it is not mentioned in the IG charter draft, and I also mention things like the Security and Privacy Guidelines and the Protocol Binding Notes in the WG draft under "Other". So sure, I will add it under "Other".

[benfrancis]

It's great to see a draft to discuss, thank you! I'm generally pretty happy with the content.

Some comments from my first reading are below.

Interoperability profiles
I would argue that the use case for profiles is not to define separate profiles for different application domains. Schema repositories (like iot.schema.org and iot.mozilla.org/schemas) already provide a mechanism for defining application domain specific metadata. The point of defining a core profile is to define a more prescriptive default protocol binding for greenfield WoT implementations, to enable ad-hoc interoperability between WoT clients and WoT servers. This should be applicable across application domains.

I wouldn't want to see a situation where my WoT client can talk to my smart home devices (using a smart home profile) but can't talk to my health devices (using the health profile) or smart city devices (using the smart city profile). That would be like having a web browser that can view shopping websites, but not news websites or weather websites.

The example given is that an industrial profile may be specified which uses the OPC-UA protocol instead of the default HTTP protocol binding. This sounds like a replacement for the Protocol Binding Templates concept. I would again suggest that a better approach in this use case would be to use a gateway which bridges OPC-UA devices to the Web of Things (e.g. using the core profile), rather than having the W3C standardise a separate profile which describes how to talk to a device using the OPC-UA protocol (which spans 14 documents and 1250 pages), such that only industrial WoT clients can talk to industrial WoT devices. Describing devices using the (non-web) binary version of OPC-UA should be completely out of scope for a WoT Thing Description.

Again, any WoT client should be able to talk to any WoT server at at least a basic level just by implementing the core WoT specification(s), with semantic annotations used to provide domain-specific information used as an enhancement.

Templates
It seems to me that the use cases described for Templates can already be fulfiled using capability schemas and server-side generation of Thing Descriptions.

Capability schemas (e.g. https://iot.mozilla.org/schemas) can be used to define common interaces/capabilities shared between devices. Multiple Thing Descriptions which differ only in their ID and API endpoint URLs can be generated on the server side from a common template. This seems like a better approach than doing the composition on the client side by splitting a Thing Description into multiple resources a WoT client must fetch and assemble together to form a full Thing Description. I would therefore argue that Thing Templates are an uncessary complexity of the Thing Description specification.

(Mozilla's gateway implementation does all of this already. It is common to have Thing Descriptions generated for multiple instances of the same model of device which share the same capabilities and differ only in their ID and URIs, and a user-defined title.)

Implementation View Specification

The only concrete requirement described here is defining error responses, which could be covered by a core profile.

Normative specifications

The WoT Architecture document could just be an informative note, it doesn't need to be a normative specification.

--

Protocol binding templates, schemas, thing description templates and profiles are all solving related and overlapping problems. I suggest that of these only a core profile (which should be part of the Thing Description specification itself) and capability schemas (for application domain specific metadata) are actually needed. Protocol binding templates and thing description templates are not really necessary.

I therefore recommend:

• The use case for profiles (specifically a core profile) should be described as being about cross-domain ad-hoc interoperability rather than defining separate profiles for separate application domains
• Thing Description Templates could be removed entirely
• The Implementation View Specification section could be removed
• Protocol vocabulary for non-web protocols (MQTT and at least the binary version of OPC-UA) should be out of scope
• The WoT Architecture document should be an informative note rather than a normative specification
• The core profile could be defined inside the Thing Description specification (as an expansion of 8.3.1 HTTP Protocol Binding) rather than creating yet another separate specification
• Discovery mechanisms for Thing Descriptions could be covered inside the Thing Description specification

If the above were true there need only be a single normative WoT specification, rather than four.

Edit: See additional comments below, in replacement of the crossed out comments above.

[benfrancis]

@mmccool Following discussions in the https://github.com/w3c/wot-profile repository where work has already started on a profile mechanism, I propose:

1. Replacing "2.3 Interoperability Profiles" with "HTTP Protocol Binding", including a mechanism to reference an external protocol binding specification from a Thing Description (instead of the profile mechanism)
2. Replacing the "Web of Things (WoT) Interoperability Profiles" deliverable in section 3.1 with a "Web of Things (WoT) HTTP Protocol Binding" deliverable which builds upon and replaces section 4.2.1 HTTP Protocol Binding of the Thing Description specification.

[mlagally]

Thanks @benfrancis for your suggestions, let me provide a few thoughts.

Profiles:

I agree that profiles for specific application domains would endanger the goal of cross-
domain interoperability.
We should not constrain the profiles to a single protocol in the WG charter at this point.

We are discussing to define a profile of a data model that could be bound to multiple protocol bindings. Constraining the profile work and deliverable to HTTP will not fulfill interoperability requirements across different protocols.
However I can clearly see the need of a HTTP binding, which shoudl be part of the profile work.

Templates:

The envisioned template mechanism goes beyond what you describe above. A single thing can implement multiple templates, i.e. you can build more complex devices based from simple building blocks, i.e. it is not a 1:1 relationship. We also should not assume a "single server" model, and an ecosystem where a single stakeholder provides a thing and a consumer. A server can manage multiple things from different manufacturers that implement the same thing template.

[benfrancis]

@mlagally wrote:

Profiles

I agree that profiles for specific application domains would endanger the goal of cross-
domain interoperability.

👍

We should not constrain the profiles to a single protocol in the WG charter at this point.

My assumption was that each profile would be constrained to a single protocol, the core profile being constrained to HTTP (the protocol which is currently ubiquitous on the web today).

I agree that the WoT charter in general should not be constrained to using a single protocol, because CoAP is arguably also a web protocol and new web protocols could be invented in the future (as far as I know these are currently the only two).

We are discussing to define a profile of a data model that could be bound to multiple protocol bindings.

My understanding is that the profile mechanism was proposed as a solution to the problem of ad-hoc interoperability or "plug and play" between WoT clients and WoT devices. If each profile is not constrained to a particular protocol, then ad-hoc interoperability can not be guaranteed and profiles are in fact just adding another dimension in which fragmentation can occur (i.e. making the interoperability problem worse rather than better).

If that is the case then I'm proposing the "profile" mechanism be replaced with a "protocol binding" mechanism where a Thing Description can refer to an external protocol binding specification by URI, as an alternative to a custom declarative protocol binding inside the Thing Description itself. A "WoT HTTP Protocol Binding" specification could then define such a protocol binding which is more explicitly constrained to a single protocol and does enable ad-hoc interoperability.

Templates

The envisioned template mechanism goes beyond what you describe above. A single thing can implement multiple templates, i.e. you can build more complex devices based from simple building blocks, i.e. it is not a 1:1 relationship.

A single thing can implement multiple capability schemas. A Thing Description which includes all of those capabilities can be generated on the server side, without the need for templating syntax in the Thing Description.

We also should not assume a "single server" model, and an ecosystem where a single stakeholder provides a thing and a consumer. A server can manage multiple things from different manufacturers that implement the same thing template.

I'm not making that assumption. Mozilla's gateway implementation manages multiple things from different manufacturers that use the same capability schemas and is agnostic to clients, which can request access to the gateway via OAuth.

I think I must still be missing something, because I still don't understand the use case for templates when the schema system already exists.