AW: Capabilities & Schemas

Von: Benjamin Francis [mailto:bfrancis@mozilla.com]
Gesendet: Donnerstag, 24. Mai 2018 17:54
An: Michael Koster
Cc: Public Web of Things IG
Betreff: Re: Capabilities & Schemas

On 16 May 2018 at 03:57, Michael Koster <michael.koster@smartthings.com<mailto:michael.koster@smartthings.com>> wrote:
Currently, we are biased toward flexibility and not having mandatory compositions. We expect the documents that carry the annotation to be self-describing and clients to be able to adapt to what is offered. This is borrowing from a fundamental REST and Hypermedia design style.

It is an interesting tradeoff to discuss, as there is admittedly more work in making a client that adapts. This can be traded off against the long term benefit of less coupling between server and client, making them separately evolveable. This is a benefit which accrues over time, where the cost of client adaptation must be paid up front.

What do you think? What are the constraints of your economic analysis that motivate one design style versus the other?

The main constraint is a requirement for ad-hoc interoperability and the feasibility of implementing a client which is adaptable enough to variation in data representation.

It's true that REST allows complete flexibility in data representation, but in practice that also usually requires a client implementation per API. By defining a Thing Description format with its own MIME type and a set of schemas which specify data constraints for a shared repository of capabilities, we hope to enable ad-hoc interoperability such that a client which implements support for those schemas can consume any Thing which implements that schema, without modification. Otherwise, what have we gained over the current situation where every IoT cloud service provides its own incompatible REST API?
The goal we want to achieve is to agree on TD and iot.schema.org (for a shared repository of capabilities). With that we hope to avoid the need for the integration at the API level (i.e., integration of incompatible REST API, development of multiple clients for multiple APIs etc). Since we see that the integration at the API level does not work, the approach to standardize semantics (TD+iot.schema.org) looks appealing.
This is also very much in line with what you wrote above.
Darko
Ben