W3C home > Mailing lists > Public > public-wot-ig@w3.org > July 2016

Re: AW: [FYI] WWDC 2016 Apple Homekit

From: fd <fd@w3.org>
Date: Tue, 05 Jul 2016 12:15:23 +0200
To: "Hund, Johannes" <johannes.hund@siemens.com>
Cc: Scott Jenson <scottj@google.com>, Dave Raggett <dsr@w3.org>, ??? <hollobit@etri.re.kr>, public-wot-ig@w3.org
Message-ID: <e19cd67daabf0e1c51b2389ecfa5b580@webmail.sophia.w3.org>
Hello Johannes,

On 2016-06-28 10:24, Hund, Johannes wrote:
> Hello Scott,
> 
>> Apple is doing much more than just "metadata description and 
>> discovery":
>> • A *limited* set of device categories
>> • Clear and *limited* functional schema for each category 
>> • A fairly limited app to find and control these devices
> 
>> We need to appreciate interoperability comes from hard decisions: by 
>> having a strong, if limited set of devices and functions.  I realize 
>> this is a more business strategy comment than an engineering one. 
>> However, I'm fearful we're just > going to recreate another "32 
>> Bluetooth profiles" mess all over again. 
> 
>> Is there any proposal to have the concept of a required base set of 
>> functionality? There can also be an optional set but taking a hard 
>> stand on required, as Apple as done, goes a long way in providing 
>> interoperability.
> 
> exactly a good point – I can answer by paraphrasing my viewpoint of
> the current state of discussion and specification:
> 
> -> The limitation of complexity is rather on the level of
> functionalities than on the level of device types.
> 
> Meaning: rather having a BT GATT approach than having 32 profiles or
> relying on REST rather than a plethora of message types.
> 
> -> We agreed that you can model the things using a limited set of
> “interactions”: properties, actions and events – we might add
> something like collections and maybe more, but in I  general there
> will be well-known set of interactions.
> -> Those interactions are expressed as resources with a limited set of
> verbs that can be applied to resources. These verbs make it easy to
> map them against an protocol.

I let Scott comment from his perspective. My feeling is that the above 
is useful to create a WoT platform but that it still does not provide 
the initial set of concrete "products" that implementers could support 
in an interoperable way.

One vision may be that providing the WoT platform is enough, in other 
words that the information it will convey (typically through thing 
descriptions) will be enough for user agents and applications to 
construct powerful user experiences without requiring user agents to 
include specific code to support different types of Things.

That may work up to a point, and the on-going developments in the Device 
and Sensors Working Group on the Generic Sensor API are very interesting 
in that regard. However, even there, the experience suggests that 
concrete specification instances and implementations are still needed to 
convey additional information and ensure interoperability (parameters 
values, meaning of readings and events, expected behavior, additional 
privacy and security considerations, etc.).

I think that the first step towards developing such concrete 
specifications is for stakeholders to agree on an initial restricted set 
of classes.

Francois.
Received on Tuesday, 5 July 2016 10:15:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 5 July 2016 10:15:35 UTC