Re: Project Things by Mozilla and the Web Thing API

> On 13 Jul 2017, at 19:49, Benjamin Francis <bfrancis@mozilla.com> wrote:
> 
> Hi Zoltan,
> 
> On 13 July 2017 at 11:10, Kis, Zoltan <zoltan.kis@intel.com <mailto:zoltan.kis@intel.com>> wrote:
> 
> I agree with the goal of making TDs more Web-developer friendly, with core vocabulary and then extensions.
> 
> Great. To contribute to that discussion I've filed an issue on GitHub <https://github.com/w3c/wot-thing-description/issues/12> proposing "properties", "actions" and "events" members at the top level of the Thing Description.

Note that I am writing this on a personal basis and not on behalf of the WoT IG/WG or W3C.

There is current interest in work on both simple JSON and JSON-LD for serialising thing descriptions. I have proposed an algorithm for mapping simple JSON into Linked Data, thereby making it feasible to map to and from JSON-LD and any other serialisations that emerge. The data types and constraints are based upon a subset of JSON schema that is modelled as Linked Data. The subset is based upon a broad range of use cases including those covered by OCF, oneM2M, ECHONET, and Bluetooth.

I am also working with Darko on linking interaction models to semantic models as a basis for discovery, composition of services and adaptations to variations across devices from different vendors. As an example, consider the scenario where you plug smart lights into sockets around your home, and make use of a smart service to discover them and dynamically configure how they can be controlled from physical switches in the home and from your smart phone etc. This involves a means for services to discover the devices based upon the kinds of capabilities they expose, along with a means to model the context (the rooms in the home, and the devices in each room). We’re looking for the atomic building blocks to enable such smart services.

Note that much of this can be implemented at the application layer as virtual things that offer smart services, e.g. as agents that run on a home hub to register things and provide access to a repository of information about the things in the home along with the context. By implementing some proof of concept demos, we can validate the requirements for the core underlying standards. Additional complementary standards could be added later as market experience dictates, just as has happened for CSS for web browsers.

> 
> Also, the gateway concept looks sound. However, I'd be interested in how far can we go with protocol bindings. Packaged SW update is less of an issue for a gateway, but it's probably more difficult for an end device that needs re-flashing and it's already deployed.
> 
> I'm not sure I understand what you mean. What's the link between protocol bindings and over the air updates that you're making?

Good security practices call for secure means to apply updates as defects are discovered. Furthermore, to connect a new device to a gateway may involve installing a driver for a new protocol or communications technology. Each driver will be controlled via the corresponding metadata in the thing description.  My proposal is to include an identifier as a URI that can be dereferenced to obtain metadata for the required driver, for instance, implementations appropriate to different IoT platforms, along with the security credentials needed to verify the integrity of the driver as it is installed.

An IoT platform is likely to only need a few drivers to be installed in normal practice, for instance, Bluetooth, OCF, oneM2M, generic drivers for HTTPS and COAP, and for Web Sockets and Server-Sent Events.

> 
> 
> Scripting is an optional building block for WoT, and IMHO it's not in conflict with your goals about web interfaces and SW libraries. You could consider it as an example, rather than _the_ way to do Things.
> 
> I agree that it isn't in conflict, but if it's not intended to become a W3C recommendation of _the_ way to do Things then why does it need to be a W3C specification at all? Why not just implement pieces of software as demonstrators of how a scripting runtime could be created to talk to web things.
> 
> Implementations may differ, but the use cases and context stay the same. Therefore, IMHO it still makes sense to standardize a WoT Scripting API for JavaScript/TypeScript. They do work against a web interface (the WoT interface).
> 
> It's interesting that you describe it as standardizing a scripting API for JavaScript/TypeScript, because the charter <https://www.w3.org/2016/12/wot-wg-2016.html> makes no mention of those languages and actually says "APIs will be defined in ways that are independent of the choice of programming languages". This is one of the points I felt was unrealistic.
> 
> To be honest I still don't understand what the Scripting API actually is or what it has to do with the web. The web is made of resources linked by URLs, not function calls. All the terminology around runtimes and life-cycles reminds me a lot of the packaged app runtime <https://www.w3.org/TR/runtime/> the System Applications Working Group tried to create which also had nothing to do with the web and went nowhere.

The key deliverable for the WoT IG is the work on thing descriptions. The scripting APIs can be seen as good design patterns that will make it easier for developers to switch from one platform to another.

The idea of a manager thing is that we can re-use the core standard for thing descriptions and APIs rather than having to invent something completely new. This includes the means to (un) install applications, to (un) register applications, to securely update them and so forth.


> 
> Who would implement a standard JavaScript/TypeScript API?
> Browsers vendors? Have any browser vendors expressed an interest in this? Why can't web applications reference web things using URLs like any other web resource and communicate with them over HTTP & WebSockets using the DOM APIs that already exist?
> Server-side JavaScript implementations? Why can't web servers serve Web Thing descriptions like any other web resource and host REST & WebSocket APIs to communicate with them like any other web service? If HTTP or HTTP/2 aren't fit for purpose for IoT use cases for some reason then let's talk to the IETF and create an HTTP/3.
>  
> Also, it makes sense to work on and have examples on script deployment (Manager Thing), related use cases, functionality, vocabulary etc
> 
> What is "script deployment"? What is a "manager thing"? I can't find these concepts defined anywhere.
> 
> Similarly, the WoT interface concepts can be applied to access to system specific functionality. TD's can be defined for a wide range of functionality.
> 
> Security, privacy, access rights, policies, "manifests" (SW extensions), etc are work in progress where Mozilla's input would be beneficial.
> 
> I'm happy to try to get Mozilla input on any open issues. I'm not sure what you mean by "manifests (SW extensions)" though.
> 
> I'm sorry for all the basic questions but I'm still struggling to get my head around the vision of the Web of Things described in the current working group charter and the documents currently being produced. As a web developer it doesn't sound like anything I recognise as the web.

The fragmentation of the IoT is widely recognised as a problem.  However, the variation in requirements across use cases and application domains make it very unlikely that a single approach will win out.  We’re therefore trying to standardise a basis for describing things as a basis for decoupling apps from the underlying protocols and communication patterns. These descriptions form a Web of things, analogous to the existing Web of pages supported by Web browsers. Thing descriptions may include references to other things, e.g. where one thing depends on the services provided by other things.

Web pages are executed by Web browsers. Applications for the Web of things are executed by application platforms that map the thing descriptions into objects that forms part of the application execution space. Application platforms may support multiple protocols, e.g. HTTP for Web pages and access to thing descriptions, and CoAP and Web Sockets for messaging. Web developers will be able to use familiar technologies such as JSON for descriptions, and JavaScript for programming, but we want to avoid the need for a developer to have to master the details of myriad different IoT standards, for which the effort can be delegated to IoT driver developers.

> 
> Ben
> 

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C champion for the Web of things