Re: Regular Web of Things call on scripting API

I made a simple diagram to illustrate the architectural layers (attached pdf).

Michael


> On Nov 2, 2016, at 10:42 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:
> 
> Hi,
> 
> This is a general comment to the present discussion.
> 
> I fully agree that REST and indeed hypermedia controls should be the architectural basis of a W3C Web of Things recommendation. Whether this group produces it as a priority deliverable or not is perhaps another discussion.
> 
> Further, I recommend that we adopt a transfer layer abstraction which supports REST and pub/sub models and maps to both HTTP and CoAP. There are well understood and compatible models, and pub/sub can easily be mapped to REST with asynchronous notification (CoAP, HTTP plus eventsource or some architected HTTP observe function using TE=chunked, or just use HTTP + pubsub for events)
> 
> The idea of such a transfer abstraction is in a contribution I made a few months ago in support of protocol bindings. OCF also have a transfer abstraction consisting of Create, Retrieve, Update, Delete, and Notify (CRUD+N). This is well understood in industry as an abstraction of the REST transfer layer.
> 
> Thing description could be more like the well known hypermedia controls we use on the WWW today, html links and forms. Links may describe and point to properties, and forms-like functionality is how actions may be described such that clients can adapt to server choices (like the web). We are already moving in that direction with TD, let's think about using JSON format links and forms and focus on defining how the semantic annotation works, where the RDF can really be put to work.  A lightweight dedicated function client like a light switch would only need to deal with the hypermedia controls, not the RDF.
> 
> If TD is structured more like hypermedia controls, we can add collections to enable composite things that have hierarchical structure (like automobiles as defined by Genivi VSS), repeating elements, and semantically differentiated components. Clients can discover the structure of things without schemas. This means schemas only need to be about describing simple types, and the complex types can be composed.
> 
> To summarize, I believe that a reference architecture based on a REST transfer layer abstraction, with an adaptation of conventional hypermedia controls, could IMO be a good basis for a W3C Web of Things deliverable. It would also make use of a lot of existing infrastructure and thinking. Scripting can very easily be built on top of this and we would have a solution that spans between wire protocol adaptation and application semantics (like the WWW).
> 
> Best regards,
> 
> Michael
> 
> 
>> On Nov 2, 2016, at 9:56 AM, Benjamin Francis <bfrancis@mozilla.com <mailto:bfrancis@mozilla.com>> wrote:
>> 
>> On 2 November 2016 at 11:04, Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> wrote:
>> You’re welcome to that opinion. For me, the Web in the Web of things is about employing the core Web architecture:
>> 
>>   1.  a means for addressing things
>>   2.  machine interpretable descriptions of things and their relationships (i.e. links, forming a web)
>>   3.  a suite of protocols for accessing things and their descriptions
>> 
>> There are already many IoT platforms and protocols, and defining one more competing platform won’t really help with addressing the fragmentation into an archipelago of incompatible solutions.  This is why it makes sense to learn from the success of the Internet as a means to enable end to end messaging across different network technologies. We need to define an abstraction layer that complements  rather than competes with the range of IoT platforms and protocols. I expect that HTTP will play an important role, but don’t see the benefit of excluding other protocols, and forcing them to the network edge as it were.
>> 
>> The vision of the Web of things as an abstraction layer is future proof in that it will scale to new requirements as different groups of people apply it to widely different application domains. For example, cyber-physical systems may impose real-time requirements for which HTTP is a poor fit. In other cases involving data streaming, where the loss of the occasional data point isn’t critical, then UDP based protocols may make the most sense.
>> 
>> So to move forward, can we agree to support HTTP, but not to rule out other protocols where those are needed to address requirements for which HTTP is a poor fit?
>> 
>> I think there's potentially an argument for defining a CoAP binding given that CoAP is so similar to HTTP but has benefits for resource constrained devices which are likely to be common on the Internet of Things, at least until it becomes more clear whether CoAP or HTTP/2 will dominate in this area.
>> 
>> CoAP is built on RESTful principles so it has URIs, a request/response pattern and GET, PUT, POST and DELETE methods just like HTTP. Trying to define bindings to other non-Internet non-web application protocols like ZigBee or X10 is probably futile.
>> 
>> I'd suggest the most likely outcome of trying to be application protocol-agnostic is that you don't actually improve interoperability because even if all existing application protocols adopt a new standard data model (very unlikely), everything is still using different protocols that need translating somehow. Even a REST API over CoAP using the WoT data model will need bridging to HTTP in order for a web application to call it from client-side JavaScript.
>> 
>> So yes, I agree the specification could allow for other protocol bindings for protocols which can support a REST API, but the focus should be on defining a REST API with a default HTTP binding and a default JSON encoding, possibly with additional notes describing a CoAP binding and CBOR encoding for example.
>> 
>> I don't think standardising a language-agnostic scripting API which calls the REST API is necessary.
>> 
>> Ben
>