- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 09 Sep 2020 19:59:43 +0900
- 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