W3C home > Mailing lists > Public > public-wot-wg@w3.org > June 2019

Re: WoT Working Group Charter - Concrete Protocol Bindings

From: Benjamin Francis <bfrancis@mozilla.com>
Date: Thu, 6 Jun 2019 13:14:34 +0100
Message-ID: <CAKQmVV-EYAUFbys439PzdrLbNK_TLGQYiMsPcLGsgAXyNM_0=g@mail.gmail.com>
To: public-wot-ig <public-wot-ig@w3.org>, public-wot-wg@w3.org
Cc: Michael Lagally <Michael.Lagally@oracle.com>, Frank MATTHIAS KOVATSCH <matthias.kovatsch@huawei.com>

   - Mozilla's original
   - Web Thing Model
   <https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/> member
   - Mozilla's Web Thing API <https://iot.mozilla.org/wot/> proposal
   - W3C Thing Description HTTP Protocol Binding

On Thu, 6 Jun 2019 at 13:08, Benjamin Francis <bfrancis@mozilla.com> wrote:

> Dear WoT IG/WG,
> It was great to meet many of you in person at the WoT Workshop this week.
> I’ve been asked to provide a first draft of a sentence for a renewed
> Working Group Charter to address the issue of concrete protocol bindings
> vs. declarative protocol bindings.
> tl;dr: Here it is:
> *“Define a mechanism such that Things may share a predefined standard
> API/sub-protocol over HTTP/WebSockets for their full set of operations,
> rather than require each Thing to self-describe an API in its Thing
> Description.”*
> For some context, Mozilla’s original feedback on the current WoT Working
> Group Charter was that a more focused and prescriptive approach, along the
> lines of the Web Thing Model member submission (and now Mozilla’s Web Thing
> API proposal), with a standardised REST & WebSockets API, could be a better
> basis for a Web of Things. The advantage of that approach is that it would
> enable ad-hoc interoperability, such that any WoT client would be able to
> talk to any WoT device and would make possible an ecosystem of apps and
> services built on a common API. The disadvantage is that it would require
> the use of gateways to bridge existing IoT APIs and protocols to this
> standard WoT application layer.
> At the time the new Working Group instead chose to take the less
> prescriptive approach of creating a Thing Description specification which
> acts more like an interface description language, in describing a range of
> existing APIs and protocols, rather than creating a new one. The benefit of
> that approach is that it can be retrofitted to describe existing devices
> and services. The disadvantage is that it makes ad-hoc interoperability
> more difficult because WoT clients have to deal with an unconstrained
> number of protocols and content types and are expected to adapt to custom
> APIs at runtime. In practice this means that any given WoT client can only
> communicate with a subset of potential WoT devices.
> The above proposed section of a new Working Group Charter is an attempt to
> redress that balance a little by providing a mechanism such that web thing
> developers can choose to use a predefined standard API/protocol if they
> want to, rather than requiring each web thing to self-describe an API in
> its Thing Description. This will not guarantee full interoperability across
> the Web of Things, but could provide a happy path for greenfield IoT
> implementations.
> There has already been some work along these lines in the Thing
> Description specification in the form of some basic defaults for an HTTP
> protocol binding. Several potential broader solutions have been proposed
> for this problem so the above wording does not prescribe a particular
> solution.
> I am of course hoping for feedback so that we can get the wording right.
> Thanks
> Ben
Received on Thursday, 6 June 2019 12:15:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:52 UTC