W3C home > Mailing lists > Public > public-wot-wg@w3.org > September 2020

[wot-discovery] minutes - 17 August 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 09 Sep 2020 19:59:43 +0900
Message-ID: <87bliffc68.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the minutes, Farshid and Zoltan!



      [1] http://www.w3.org/

                               - DRAFT -

                             WoT Discovery

17 Aug 2020


      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#17_August_2020


          Kaz_Ashimura, Michael_McCool, Christian_Glomb,
          Kunihiko_Toumura, Farshid_Tavakolizadeh,
          Cristiano_Aguzzi, Zoltan_Kis, Andrea_Cimmino,
          Christian_Kurze, Tomoaki_Mizushima



          Farshid, Zoltan


     * [3]Topics
         1. [4]Agenda
         2. [5]Minutes review
         3. [6]PR 52
         4. [7]Issue 51
         5. [8]Guest
         6. [9]PR 50
         7. [10]PR 49
         8. [11]PR 47
         9. [12]AOB
     * [13]Summary of Action Items
     * [14]Summary of Resolutions

   <kaz> scribenick: FarshidT


   <inserted> Farshid: (suggests we add Issue 34 on links section
   to the agenda)


     [15] https://github.com/w3c/wot-discovery/issues/34#issuecomment-668508701

Minutes review

   <kaz> [16]Aug-10 minutes

     [16] https://www.w3.org/2020/08/10-wot-discovery-minutes.html

   McCool: change "smart link" to LinkSmart from Fraunhofer

   no objections to publishing minutes.

   <zkis> scribe: zkis

   McCool: we have quite many PRs that need merging


     [17] https://github.com/w3c/wot-discovery/pulls

PR 52

   [18]PR 52

     [18] https://github.com/w3c/wot-discovery/pull/52

   McCool: I wonder should we have an extension field for error

   Farshid: could we add it to TD 1.1?

   McCool: back-compatibility is a problem
   ... one way is to extend the TD (ignored by previous TD version

   Farshid: I'm afraid this is not enough, since for some
   endpoints there are 2 different success responses

   McCool: okay, then we could have an array of responses

   McCool looking at TD Form response section

   Farshid: this is an old issue in the TD spec

   McCool: we should not break existing TDs
   ... response is a default response and then there are "other"
   responses that could be an array

   <FarshidT> related issue:

     [19] https://github.com/w3c/wot-thing-description/issues/617

   McCool: thinking about "alternateResponses" or something like

   McCool is adding comment to TD issue #617

   Farshid: that could work (referring to the comment)


     [20] https://github.com/w3c/wot-thing-description/issues/617#issuecomment-674911344

   McCool: if we put the error responses in a separate field, we
   can do an extension
   ... but we can merge this PR and do it separately

   Farshid: there is a "type" field we could use

   McCool: so the problem is the payload carried in the response

   Farshid: right

   McCool: so we should describe it

   Farshid: there is a content type for that "json+..."

   <kaz> [21]PR 52 Preview - 8.2.2 Directory Service API

     [21] https://pr-preview.s3.amazonaws.com/w3c/wot-discovery/52/97c2123...farshidtz:8299594.html#exploration-directory-api

   Farshid: we can have htv content type inside the response
   ... I will make a separate PR

   McCool: any objections for merging this PR?



   <kaz> [22]PR 52 is merged

     [22] https://github.com/w3c/wot-discovery/pull/52

Issue 51

   [23]Issue 51 - Notification API

     [23] https://github.com/w3c/wot-discovery/pull/51

   Farshid: events are handled via one op, with id's

   McCool: there is an issue with id's (local vs universal)
   ... maybe a directory-local id would be better

   Farshid: this applies to the whole document

   McCool: right, we need a separate PR for that
   ... SSE is fine


   Kaz: we have a guest for today

   McCool: anything to add to the agenda?

   Christian_Kurze: no, thanks

   McCool: will not merge this PR for now

   meaning [24]https://github.com/w3c/wot-discovery/pull/51

     [24] https://github.com/w3c/wot-discovery/pull/51

PR 50

   [25]PR 50

     [25] https://github.com/w3c/wot-discovery/pull/50

   McCool: we had a discussion about OAuth2 in the security call
   ... I agree we should make the flows optional

   Farshid: authorization is mandatory
   ... for token endpoint, it's necessary, in other cases not

   Cristiano: I can see some cases when clients can use auth
   ... a specific client may already know the authorization
   endpoint, but others not

   Farshid: there is only one entity that manages the data and
   that already knows the endpoint

   Cristiano: if you already managed it, indeed you know the

   Farshid: a browser (agent) will redirect, that URL needs
   following, and after authorization it can go back

   Cristiano: I see this as a violation of the code flow

   Farshid: I can pass a token to the Thing Directory, that is
   obtained by the device (doing the hard work)

   Cristiano: but the device acts as a proxy

   Farshid: the device is a HW and the SW is the actor here, which
   already has the endpoint

   Cristiano: we could discuss it in the Security call

   McCool: let's do that
   ... meanwhile let's collect more opinions on this PR
   ... the PR is adding these definitions in the TD
   ... also, the "combination" scheme might change
   ... I suggest keeping the PR open, as ultimately it is just
   adding the examples
   ... these could be clarified

   Farshid: agree to keep it open

   Cristiano: I agree, too

   McCool: let's think about OAuth2 mandatory and optional aspects

   McCool commented on the PR:

     [26] https://github.com/w3c/wot-discovery/pull/50#issuecomment-674920253

   Cristiano: there is an issue in the flow

   Farshid: there is a difference between TD and service

   McCool: yes, we use the header
   ... we need to read through the OAuth2 spec again
   ... there are 2 cases, one is easier, the other needs thinking
   ... let's leave this open

PR 49

   [27]PR 49

     [27] https://github.com/w3c/wot-discovery/pull/49

   McCool explains the PR through the preview.


     [28] https://pr-preview.s3.amazonaws.com/mmccool/wot-discovery/pull/49.html

   McCool: it could be refined

   McCool: I have a separate PR on use cases, so we could actually
   merge it

   Cristian: I can review this

   McCool: okay, we wait then for that

PR 47

   [29]PR 47 - Semantic search

     [29] https://github.com/w3c/wot-discovery/pull/47

   McCool: we got some feedback from Andrea
   ... there is no easy way to break sections of the TD
   ... we could semantically tag, though

   Cristiano: we can separate SPARQL
   ... and if we get an answer, it means the TDD supports it

   McCool: in general having a form for a URL is ok

   Cristiano: another question is how do we do XPath, with
   /xpath... or as a parameter of the TD

   Farshid: I prefer separate query parameter for SPARQL and other
   types, then the responses would differentiate by contant types

   McCool: should we have both/multiple, or just one? eventually
   ... this adds more complexity
   ... using "td?query=XXX" implies the query can be only SPARQL?

   Cristiano: but they could use prefixing like /td/sparql or

   Farshid: and for JSONPath we could follow the same convention

   Cristiano: had a problem with graph describe was not working
   ... the problem is that it seems to be optional and not
   everyone implements it

   Cristiano: I will do some tests on 3-4 TDs and see

   Cristiano: I in turn could try using Virtuoso


     [30] https://github.com/w3c/wot-discovery/pull/47#issuecomment-674933405

   Cristiano: or queries should be subsections? or one option?

   McCool: should we have a default style?
   ... one should be always present
   ... the other could be optional
   ... in sub-URLs
   ... we cannot make a decision on this now
   ... so we leave it open


   out of time, need to adjourn

   Farshid will be on vacation next week


Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [31]scribe.perl version ([32]CVS log)
    $Date: 2020/08/18 12:27:09 $

     [31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [32] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 9 September 2020 10:59:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 9 September 2020 10:59:49 UTC