- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 09 Sep 2020 20:01:10 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/08/31-wot-discovery-minutes.html
also as text below.
Thanks a lot for taking the minutes, Farshid!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Discovery
31 Aug 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#31_August_2020
Attendees
Present
Kaz_Ashimura, Michael_McCool, Kunihiko_Toumura,
Christian_Glomb, Andrea_Cimmino, Farshid_Tavakolizadeh,
Tomoaki_Mizushima, Cristiano_Aguzzi
Regrets
Chair
McCool
Scribe
FarshidT
Contents
* [3]Topics
1. [4]Minutes
2. [5]Mandatory oauth2 endpoints
3. [6]PR 59
4. [7]PR 50
5. [8]PR 51
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<kaz> Agenda:
[11]https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#31_
August_2020
[11] https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#31_August_2020
<kaz> scribenick: FarshidT
Minutes
[12]https://www.w3.org/2020/08/24-wot-discovery-minutes.html
[12] https://www.w3.org/2020/08/24-wot-discovery-minutes.html
No objections. Published.
Mandatory oauth2 endpoints
endpoint will remain mandatory in TD 1.x. They can be changed
for TD 2.0 if there are valid use cases.
<kaz> [13]wot-security issue 181
[13] https://github.com/w3c/wot-security/issues/181
PR 59
PR: Move requirements to Architecture
([14]https://github.com/w3c/wot-discovery/pull/59)
[14] https://github.com/w3c/wot-discovery/pull/59)
<kaz> [15]related to issue 57
[15] https://github.com/w3c/wot-discovery/issues/57
McCool: centralizing requirements make sense. But need to
discuss if it would be useful to keep them inside index.html
... requirements are placed in requirements.md file
Kaz: will these requirements be included in architecture
requirements?
McCool: yes, we are still debating if they should be as part of
wot use cases or part of the architecture document itself
(possibly the consolidated "WoT Use Cases and Requirements"
document at some point).
No objections. Merged PR.
PR 50
McCool: Add additional security schemes to directory TD
([16]https://github.com/w3c/wot-discovery/pull/50)
[16] https://github.com/w3c/wot-discovery/pull/50)
Farshid: initially thought of an invalid use case which didn't
require the oauth2 endpoints.
... this is now clear.
MCCOOL: commented regarding the scopes
Farshid: added an issue regarding vocab that need to be added
to context: [17]https://github.com/w3c/wot-discovery/issues/54
[17] https://github.com/w3c/wot-discovery/issues/54
McCool: better change "combination" to something else to avoid
using scheme name for definitions
... will change that after the merge
no objection. Merged PR.
McCool: changed "combination" to "combo_sc" on master branch
PR 51
PR: Add description of notification API
([18]https://github.com/w3c/wot-discovery/pull/51)
[18] https://github.com/w3c/wot-discovery/pull/51)
McCool: the query parameter should be described in TD to tell
client if the feature is provided.
Farshid: should providing diff be a mandatory feature provided
by servers?
Cristiano: i don't think so
McCool: agrees, it is nice to have
Farshid: so the event will have at least "id"
McCool: need to clarify what is the identifier of TD and
whether it differs from TD's ID
Cristiano: the id should be same as the identifier used to
retrieve the TD
McCool: Updated index.html with semantic search
([19]https://github.com/w3c/wot-discovery/pull/47)
[19] https://github.com/w3c/wot-discovery/pull/47)
Andrea: needed to do a git rebase to start from latest changes
... will add TD changes to directory.td.json and remove the
other json file
... still no clear about the endpoints, whether /search is the
best option
... no normative reference for JSONPath
McCool: for xpath, we can pick the particular version which has
JSON support
... IETF is working on JSONPath
... references can be from respec database or local
Andrea: XPath and JSONPath as a MUST, SPARQL as a MAY
McCool: my recommendation is to pick one syntactic approach as
a MUST and another as a SHOULD
... it may take time to get JSONPath as a standard, so I
recommend XPath as MUST, JSONPath as SHOULD, SPARQL as MAY
Andrea: I suggest JSONPath a MUST and XPath as SHOULD, though I
understand about the standardization issue
McCool: okay, we can do that for now and check the progress of
JSONPath in future.
Andrea: 200 response type will be a complete TD or set of TD
elements
McCool: it won't be "application/td+json" technically.
Andrea: we can use "application/ld+json" if they are partial.
McCool: yes if we can insert the context file for jsonld
Farshid: the context file may not be relevant anymore because
the JSON structure may be different, i.e. different key name,
array of objects
... I suggest "application/json"
McCool: perhaps the safest option for now is
"application/json", and we can contact JSON-LD people to ask
how they deal with such situations
... need to include the query param inside the href template
... some terms such as "JSON Path" and "SPARQL" don't need to
be in code formatting.
Andrea: simplified the SPARQL text, removed normative protocol
details.
... need to decide HTTP method, or allow both GET and POST
McCool: shouldn't give too much flexibility
... either require just one method, or require both
Farshid: i think having both are not technically necessary
... GET will allow caching, POST will hide the query from
server logs
McCool: POST may be convenient because it doesn't need URL
encoding
<kaz> [20]Preview - 8.2.2.4.3 Semantic search: SPARQL
[20] https://pr-preview.s3.amazonaws.com/AndreaCimminoArriaga/wot-discovery/pull/47.html#search-semantic
McCool: we can go with MUST for GET and MAY for POST
Cristiano: agrees
McCool: TPAC planning in next meeting
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [21]scribe.perl version ([22]CVS log)
$Date: 2020/09/07 07:18:54 $
[21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[22] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 9 September 2020 11:01:15 UTC