Meeting minutes
Minutes
Cristiano: (goes through the minutes)
approved
Calendar
Kaz: (mentions DST changes)
PRs
PR 561
PR 561 - Extended return type of invokeAction()
Daniel: (gives summary)
… addition around ActionInteractionOutput
… InteractionOptions for query is optional
… also for cancel
… (shows index.d.ts)
… the change here is minimum
… (also revisit his comments last week)
Daniel: inline with the comments above
Cristiano: mixed feeling here...
… what is the use case?
… wondering why we get errors
Daniel: good point
… if I query something, that can fail
Cristiano: we can remove it then?
Daniel: ok
Cristiano: let's see others' comments too
… having InteractionOptions optional itself is fine, but what about input?
Daniel: there is InteractionInput as well
… originally started with InteractionInput
… and was wondering if we need both
Cristiano: that surprises me too...
… we should be consistent
… why do we want to have query, etc.?
… (goes through the Editor's Draft)
WoT Scripting API Editor's Draft - 8.12 The InteractionOptions dictionary
Daniel: not sure if we really need both
… two possibilities here...
… was not really sure which way would be better
Cristiano: anyway, the API should be consistent with the other APIs
Jan: also wondering about that
… this InteractionOptions for query()
… we can indicate which form to be used
Cristiano: you're right
… but something is missing by the TD spec
Daniel: on one hand, we have formIndex
… at the moment, we don't need the status
… both query() and cancel() are optional
Jan: ok
Cristiano: can afford with the same algorithm
… we don't know about the actual protocol, so wondering about cancel()
Daniel: maybe to be aligned with stop() from Subscription
… here, InteractionOptions for stop() is also optional
Cristiano: we have to review the method carefully
… can you check it for the TD spec as well?
Daniel: let me see...
Web of Things (WoT) Thing Description - Next (Editor's Draft)
Cristiano: open issue there
Daniel: issue with the data model to me
Cristiano: let's double check the issue with the TD TF
TD spec (Editor's Draft) - Table 7: Vocabulary Terms in EventAffordance Level
Cristiano: this could be an issue for TD as well
Daniel: the name is also being reused, e.g., for stop()
Cristiano: right
… this is a bug or missing feature of the Scripting API spec
Jan: wondering about the interface
… data can't be defined for the properties
Cristiano: right
Daniel: maybe we could split it
Cristiano: possibly could use sub interface?
Jan: wondering if we should use the same mechanism for both
Cristiano: it's rather an issue of the TD spec, I think
Kaz: what should be the next step then?
… should we bring this to the TD TF?
Cristiano: yeah, would create an issue for TD
Kaz: ok. tx!
Daniel: will update the PR based on the feedback today
Cristiano: and then I'll create an issue for TD
Issues
Issue 566
<cris> Issue 566 - [Use-case] WoT in the Browser
Cristiano: we should support WoT in the browser in general
Daniel: we all agreed based served as an external library (at the beginning)
… if browser vendors are interested themselves in native implementation, that would be great, though
Cristiano: right
… also would be nice for us to capture problems with the Scripting API beforehand
Kaz: agree
… we should clarify what to be done as the WoT WG as a whole
Cristiano: (adds some more comments to the issue)
… we're aligned with Ben's comments
… the question is not just about the WoT Scripting API but the whole WoT including TD and Discovery
Issue 567
Issue 567 - [TD] Consequence of contentType being optional
Cristiano: we need to handle this for TD 2.0. right?
… after clarifying what to be done for TD 1.1
… let's wait for TD updates
Daniel: maybe we need to add some statement about our stance
Cristiano: (adds some comments about that to issue 567)
Daniel: the PR Jan created is only about response at the moment
TD PR 2081 - Make contentType optional in ExpectedResponse and AdditionalExpectedResponse classes
Jan: there is no schema for Discovery
[adjourned]