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

Re: WebIDL for Thing API

From: Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de>
Date: Mon, 4 Jan 2016 15:39:52 +0000
To: "Broering, Arne" <arne.broering@siemens.com>
CC: Claes1 Nilsson <Claes1.Nilsson@sonymobile.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <0912421F-D2AD-49A7-8ED6-4DBB0EA9AAB5@fokus.fraunhofer.de>
Hello Arne,

thx for your feedback please find my comments inline.

Best regards,
Louay
On 17 Dec 2015, at 16:27, Broering, Arne <arne.broering@siemens.com<mailto:arne.broering@siemens.com>> wrote:

Dear Louay,

Many thanks for your API draft! We discussed it today in the TF-DI call and some questions came up:

1.) An implementation of the API will map the call of 'request.start()' to a specific underlying technology (e.g., BLE, mDNS, CoRE RD, or a SPARQL endpoint). How can we manage the functional diversity of identified discovery technologies (see link<https://www.w3.org/WoT/IG/wiki/Discovery_Categories_and_Tech_Landscape>) in the ThingFilter?
Some ThingFilter attributes may be applicable only to certain technologies. E.g., the "server" attribute is relevant in case the underlying discovery technology is a SPARQL endpoint, while in case of BLE it probably isn't relevant.
Deriving technology specific extensions (subclasses) of the ThingFilter could be one direction to take, if we really want to fully support various discovery technologies with this API.

This is a very important question we need to answer in the group. There are two options from my point of view:
- Technology Independent API (Similar to W3C Presentation API): all filter parameters are technology independent. This means we need to define a set of abstract filter parameters that can be mapped to a specific technology in the implementation (of the Thing API). The API will be in this case easier to use from web developer perspective but on the other hand we may be not able to support complex queries  as in SPARQL.
- Technology dependent API as you suggested in 2)

2.) Another question was regarding the functionality of the ThingFilter: we would like to see the possibility of filtering for thing metadata (as specified in a Thing Description). You already have the 'type' attribute. We could now include multiple further thing properties, or we could come up with some sort of generic property filtering mechanism (maybe even including comparison, temporal, or spatial filtering).
In case the underlying discovery technology is a 'repository', a ThingFilter might also offer an attribute that defines a search query (and another one defining the query language format).

Yes of course the filter should also consider other metadata and not only the type parameter.
Finally, we'd be interested to know what you will be able to bring to the plugfest? Which underlying protocols will already be supported by your API implementation?

I will bring an implementation of the API on top of BLE and HomeKit. I will also try to support PhysicalWeb.
Again, many thanks for your work and triggering the discussion!

Best regards,
Arne

From: Bassbouss, Louay [mailto:louay.bassbouss@fokus.fraunhofer.de]
Sent: Mittwoch, 16. Dezember 2015 17:05
To: Claes1 Nilsson
Cc: public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>
Subject: Re: WebIDL for Thing API

Thx Claes for the feedback,  Please find my comments inline.

Thx
Louay
On 16 Dec 2015, at 14:57, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>> wrote:

Hi Louay,

Thanks for this API. My comments follow below:



·         dictionary ThingFilter {

    attribute DOMString? type;

    attribute ThingProximity? proximity;

    attribute DOMString? id;

    attribute DOMString? server;

};

So this is the address, URL, of a server containing a directory of "things", e.g. an IETF CoRE Resource Directory?
Yes server is the address of the directory where to search for things. We may need additional information to the end-point url like you mentioned below regarding security/privacy. If you have any recommendation please let me know.




·         Looking at security/privacy and access authorization aspects of this API is the assumption that the web application or server application (e.g. node.js) already has been authorized to access the “thing”. If not, is it assumed that, after a thing has been discovered, that an authorization session with e.g. OAuth will be executed before the web app is allowed to access the thing?
Security/Privacy is not considered yet in the current API. We need input/feedback from the Security/Privacy Task force.




Best regards

  Claes


From: Bassbouss, Louay [mailto:louay.bassbouss@fokus.fraunhofer.de]
Sent: den 14 december 2015 13:27
To: public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>
Subject: WebIDL for Thing API

Dear group members,

I just submitted the initial WebIDL draft of the Thing API [1] I demonstrated @TPAC in sapporo. It considers also feedback I received from some of you. It is just a draft to start with. Can we put an Agenda item to discuss it in the next phone call.

Regards,
Louay

[1]: https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thing-api-webidl.md



Received on Monday, 4 January 2016 15:40:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 4 January 2016 15:40:35 UTC