<kaz> scribenick: FarshidT
<inserted> Farshid: (suggests we add Issue 34 on links section to the agenda)
https://github.com/w3c/wot-discovery/issues/34#issuecomment-668508701
<kaz> Aug-10 minutes
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
https://github.com/w3c/wot-discovery/pulls
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: 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)
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> PR 52 Preview - 8.2.2 Directory Service 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> PR 52 is merged
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 https://github.com/w3c/wot-discovery/pull/51
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: 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
McCool explains the PR through the preview.
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
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: 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
adjourned