<scribe> Agenda: https://github.com/w3c/wot-scripting-api/pulls, https://github.com/w3c/wot-scripting-api/issues
<scribe> scribe: zkis
https://www.w3.org/2020/08/31-wot-minutes.html
Past minutes approved.
Daniel: will review today
Looks good, merged.
Zoltan: this has a problem, mentioned in the PR
Daniel: we may init lazily, not in consume()
Zoltan: when to init then?
Daniel: when interactions are called, they could be init'd then
Cristiano: yes, that could work
... what we need to decide if we fail early, or during the
interactions (if they are not set up correctly, or there is an
error)
... I have no problem with consume() being a bit different than
constructor
Zoltan: consume() could fail early and constructor could use lazy init
Cristiano: this could work, need to think
Daniel: we should not fail for something implementations can correct
Cristiano: that's a valid point as well
Daniel: and this is also valid on
exposed things as well as consumed things
... so we should fail only when things cannot work
Cristiano: similarly, for security, we
should be flexible, e.g. if one of the schemes work, it should
be fine
... we could lazily push error
Zoltan: I agree, also because the
nature of these comms is async, over various protocols so we
cannot guarantee to fail early
... TD validation is only syntactic, not functional
Zoltan: there is a question about global consistency of Forms (e.g. every interaction has a CoAP form)
Daniel: we should be flexible here
Cristiano: we need the flexibility
... we have an open issue about ops and also about default
values
... TD issue 957
Zoltan: please put any ideas for the expose() algorithm in the PR
Daniel: again the vote goes for flexibility
Cristiano: we should not expose something we cannot handle
Zoltan: right, we could remove the constraint
Daniel: yes, a TD is not necessarily by this runtime
Zoltan: we can leave it generic - on
the other hand that step is very complex and we have no good
description of it
... but for now I will remove the sentence
Cristiano: architecturally we cannot enforce form existence or syntax
Zoltan: trivial change, done what the issue proposed
Cristiano: right
Daniel: looks good
merged
Zoltan: did we cover all issues
raised from the review
... I need to check that.
<scribe> ACTION: ZK to check if there are issues not handled from Ege's review
Zoltan: in the light said today, what should we do for this issue
Cristiano: right, we need to rething
that
... will comment later
Daniel: here as well we should apply the flexibility argument
Zoltan: if the TD designer specified these constraints, they should be respected
Cristiano: agree with the need of
checking
... at least with the convenience methods
... of the value() function
Daniel: had a similar problem in the past, sometimes schemas are too refined and restricted; often the implementations cannot be that rigurous
Cristiano: we should check what JSON Schema does
Zoltan: let's do that
Cristiano: propose an agenda to talk about TypeScript definitions
Daniel: we said we should have a spec before the plugfest, but we should at least solve subscribe/unsubscribe
Adjourned.