<kaz> Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#31_August_2020
<kaz> scribenick: FarshidT
https://www.w3.org/2020/08/24-wot-discovery-minutes.html
No objections. Published.
endpoint will remain mandatory in TD 1.x. They can be changed for TD 2.0 if there are valid use cases.
<kaz> wot-security issue 181
PR: Move requirements to Architecture (https://github.com/w3c/wot-discovery/pull/59)
<kaz> related to issue 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.
McCool: Add additional security schemes to directory TD (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: 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: Add description of notification API (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 (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> Preview - 8.2.2.4.3 Semantic search: SPARQL
McCool: we can go with MUST for GET and MAY for POST
Cristiano: agrees
McCool: TPAC planning in next meeting
<kaz> [adjourned]