Re: [WoT WG] Release of WoT WG Charter Draft extendend until next week

Hi Matthias,

On 20 October 2016 at 12:53, Kovatsch, Matthias <
matthias.kovatsch@siemens.com> wrote:

> Anyhow, I hope this bilateral discussion continues, since it also helps to
> better understand the viewpoints within the group. The past two years in
> the WoT IG had a big share of learning from others to get Web companies and
> thing companies on the same page.
>

Absolutely, I hope so too.


> In this regard, it is quite surprising to me and others that you call the
> Current Practices “nebulous”. Several members have implementations of that,
> tested them at multiple of our PlugFests, and presented the Current
> Practices in a live demo at the recent TPAC. There, I unfortunately did not
> meet anyone from Mozilla to learn more about open issues.
>

I don't mean to play down those efforts. But as a (so far) outside observer
trying to comprehend the Web of Things model my observation is that the
"current practices" so far appear over-complex and are trying too hard to
be everything to everyone for real interoperability to emerge. Perhaps I
lack the understanding of the problem space needed to realise why such
complexity is necessary, but it seems there are lots of opportunities for
simplification.

As an example, why is there a need to standardise both a protocol-agnostic
"WoT Interface" with direct bindings to HTTP/CoAP/MQTT/BLE and a
language-agnostic "Scripting API" for running on a "runtime
environment—similar to the Web browser" where every device is modelled as a
"servient"? It seems like a single REST+WebSockets API on a web server
(running on a device/gateway/cloud with CoAP/MQTT/Bluetooth/ZigBee/Z-Wave
or whatever else on the back end) called from any web client (a web
application or native application or another service) could suffice.

I don't think standardising a "Web of Things" around HTTP is unreasonable,
especially given Weave, HomeKit, SmartThings, EVRYTHNG, AWS IoT, Azure IoT,
IoTivity, AllJoyn etc. all appear to be using REST APIs in some way
already, mostly with JSON, albeit in non-standardised ways. HTTP doesn't
have to be used directly on resource-constrained Things (that's where the
gateway and cloud integration patterns can be useful), but at some point
web apps in particular are going to expect to talk HTTP.

Unfortunately history tells us that a hard dependency of RDF is also a sure
way to prevent widespread adoption.


>
> I agree that the Web Thing Model Member Submission is a nice and easy
> starting point. When integrating actual things and taking a stab against
> fragmentation, however, the simple MUSTs (in particular HTTP/1.1) and
> global conventions (enforcing a specific resource structure on all servers)
> directly become a contradiction.
>
For this reason, the IG expanded on that model to overcome the limitations
> (see https://lists.w3.org/Archives/Member/member-wot-ig/2016Jun/0012.html).
> The hardest task is to find the right presentation of the content, so that
> everyone in the wide spectrum of stake-holders can relate to something they
> already know and see how IoT/embedded technology comes together with Web
> technology.
>

Do you think the ubiquitous World Wide Web of documents we have today would
exist if people had insisted that the web be application protocol and
markup language agnostic?

Perhaps I misunderstood but I didn't think the Web Thing Model required a
particular URL structure. Sub-resources are meant to be discovered via
links in the Thing Model using a HATEOAS approach.

I definitely don't think the Web Thing Model member submission is perfect.
(The MUSTs for particular HTTP methods raised some eyebrows at Mozilla
too!). But I'd argue it is a much more concrete starting point on which to
build a standard which creates real interoperability between IoT systems,
by using the web (with URIs and HTTP) as a unifying application layer
protocol for IoT.

I'm looking forward to hearing the results of those discussions and I'm
keen to help move things forward if I can.

Ben