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:
  https://www.w3.org/2020/08/17-wot-discovery-minutes.html

also as text below.

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

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                             WoT Discovery

17 Aug 2020

   [2]Agenda

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

Attendees

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

   Regrets

   Chair
          McCool

   Scribe
          Farshid, Zoltan

Contents

     * [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

Agenda

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

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

     [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

     [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
   implementations)

   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

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

   McCool: thinking about "alternateResponses" or something like
   that

   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#iss
   uecomment-674911344

     [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?

   none

   (merged)

   <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

Guest

   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
   points
   ... 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
   endpoint

   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-6
   74920253

     [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
   configuration

   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/p
   ull/49.html

     [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
   optional?
   ... 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
   /td/xpath

   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

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

     [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

AOB

   out of time, need to adjourn

   Farshid will be on vacation next week

   adjourned

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