Re: Call to discuss interop demo with OCF

> On 21 Apr 2016, at 07:58, Kovatsch, Matthias <matthias.kovatsch@siemens.com> wrote:
> OCF uses CoAP as primary protocol for thing-to-thing communication. And so far, IoTivity only supports CoAP.

I am told that the HTTP bindings are a work in progress.

> 
> I imagine creating an open source gateway that exposes selected  IoTivity resources as “things”. For this we would need metadata for describing the data and interaction models exposed to applications, for the choice of communications patterns, and for the information needed for interoperating with the platforms and protocols, including security settings.
>  
> Indeed, prototyping a gateway or proxy servient for OCF sounds like a great exercise to better understand how to complement other platforms and, furthermore, provides an awesome demo to encourage IoT consortia in generel to join.

Exactly!  It should also make it easier to build demos for integration with other platforms e.g. oneM2M, Brillo/Weave and OPC-UA.

>  Of course it would be good to collaborate with other members of the Web of Things Interest Group, e.g. on the initial work on Thing Descriptions, and if appropriate on coding the gateway itself.
>  
> Note that I have slightly different idea of the type system and representation of Thing Descriptions than given in the current draft of the current practices document. See my implementation report slides from the Montreal face to face. In particular, this should make it easier to support nested properties, late binding of things as properties and so forth.
>  
> I would be interested in this work (not sure if I have enough time before the next F2F). Unfortunately, your talk or the slides did not contain any concrete information about your approach for TD or type system. As already mentioned during one of the breakouts, it would be great to see your proposals in the form of TD samples or API descriptions. Could you maybe compile something in the style of the Current Practices document? It definitely does not have to be that verbose, but I would love to see concrete examples of how your solutions look like. I guess, this could also improve the discussion for the working documents and future breakouts.


Yes, I indeed plan to provide some, along with working software for experimenting with, since working code is definitely better than slideware. We could then include the details in the current practices document or a linked document as appropriate.

As food for thought, here is an example of a compound property involving a voltage reading with real and imaginary components:

“properties": {
    “voltage": {
        “type": {
            “real": “float",
            “imaginary”: “float"
        }
    }
}

If a compound type is used frequently, it will be desirable to be able to define it once and refer to that definition. This is a standard feature of most programming languages, e.g. C’s typedef. We could have the definition in the thing description, or defined by reference to an external definition. Such re-usable definitions would also be valuable for avoiding redundantly declaring type annotations.

One way to define types would use a top level “types” whose value is an object with the names of the types and their definition, e.g.

“types": {
    “complex": {
        “type": {
            “real": “float",
            “imaginary": “float"
        }
    }
}

The earlier example can then be rewritten as:

“properties": {
    “voltage": “complex"
    }
}

Note that a full example would include the context and other metadata. 

The challenge is to come up with some demo proposals that together cover the full range of data types envisaged.

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>