- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 20 Sep 2021 17:44:15 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/08/09-wot-script-minutes.html
also as text below.
Thanks a lot for taking the minutes, Zoltan!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
– DRAFT –
WoT Scripting API
09 August 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#9_August_2021
[3] https://www.w3.org/2021/08/09-wot-script-irc
Attendees
Present
Critiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura,
Tomoaki_Mizushima, Zoltan_Kis
Regrets
-
Chair
Daniel
Scribe
zkis
Contents
1. [4]past minutes
2. [5]quick updates
3. [6]publication
4. [7]open PR
5. [8]Issue 193: Should writeProperty() return a value
6. [9]propose closing issues
Meeting minutes
past minutes
[10]Aug-2
[10] https://www.w3.org/2021/08/02-wot-script-minutes.html
Daniel: any comments on the minutes?
Daniel: no, past minutes approved, can be published
quick updates
Daniel: might miss next call
Cristiano: not available either on the next call
Zoltan: so we can skip the call
Daniel: so the next call is on 23 August.
<Mizushima> +1
publication
Daniel: publication plan, we can make an update in September or
October
open PR
<dape> [11]https://github.com/w3c/wot-scripting-api/pull/329
[11] https://github.com/w3c/wot-scripting-api/pull/329
Daniel: approvals are there, can be merged (after fixing
conflicts)
Cristiano: we can mark package.json as private
Daniel: should we have the same name wot-typescript-definitions
in the repo
Zoltan: no, I don't think we have that constraint
Cristiano: it's fine as it is
Daniel: ok, comments resolved in the PR
Daniel: about version numbering, is that fine?
Cristiano: the TD schema used the same convention for version
… though a date in a version is not common
… we can add SNAPSHOT
Zoltan: it's like a note in the version string, so whether it
contains a date or snapshot it's private decision
Daniel: we can merge and try right away what happens when
publishing the npm
Issue 193: Should writeProperty() return a value
<dape> [12]https://github.com/w3c/wot-scripting-api/issues/193
[12] https://github.com/w3c/wot-scripting-api/issues/193
Daniel: whether writing a property should return a value
Daniel: we needed a feature to tell whether a value can be
returned by the write op
Daniel: I suggest the Scripting TF waits until this is
finalized
<dape> [13]https://github.com/w3c/wot-thing-description/issues/
875#issuecomment-892776550
[13] https://github.com/w3c/wot-thing-description/issues/875#issuecomment-892776550
Daniel: Sebastian commented
Daniel: there are 3 options, 1. no return, 2. return the same
data schema, 3. return a different data schema
Daniel: the Scripting API should model these
Cristiano: this will imply other changes to the Scripting API,
for instance DataSchema can be in a Form now
… this is a general issue
Daniel: there will be ExpectedResponse schema,
AdditionalExpectedResponse etc
Daniel: we can return InteractionOutput on writes again, we
need a way to indicate to expect something or not
Zoltan: we already have the schema in InteractionOutput, that
can be null
Cristiano: I understood the same way
Daniel: I thought this was optional hint, but ok
Daniel: so if the TD TF decided to support the use case,
Scripting might need little changes
Cristiano: may we can just add InteractionOutput and check the
use cases
… based on Sebastian's comment on ExpectedResponse, we might
need to re-check
… AdditionExpectedResponse was not defined well, therefore a
schema was put there
Cristiano: again the question is what makes a difference
between an Action and a property write
Zoltan: WoT inherited most problems from supported protocols
and provided very little generalization
Cristiano: have the same feeling
Daniel: it's because the many specific use cases
Kaz: agree with both sides but clarifying typical use cases
would be good
… for instance timeout with HTTP
… we should consider the exact use cases
Daniel: should we raise this with the TD TF?
Kaz: obviously this is a generic comment, to stick to use cases
Zoltan: we need more than just use cases, we need to be able to
generalize and make it usable
Cristiano: we need more applications (with a lot of use cases)
Kaz: yes, use cases mean also the complete scenario
Daniel: we do have one mash-up use case
Kaz: we can start from the Core profile (Ben Francis)
Daniel: anyway we don't decide there, Scripting follows the
decisions in the other tack forces
propose closing issues
<dape> [14]https://github.com/w3c/wot-scripting-api/
issues?q=is%3Aissue+is%3Aopen+label%3A%22propose+closing%22
[14] https://github.com/w3c/wot-scripting-api/issues?q=is:issue+is:open+label:"propose+closing"
<dape> [15]https://github.com/w3c/wot-scripting-api/issues/107
[15] https://github.com/w3c/wot-scripting-api/issues/107
Daniel: it's a lot of complexity and we don't have a use case
Zoltan: the TD TF should handle this first
Kaz: transferring issue is ok, but could go to the profile or
implementation guideline
… so we can raise that in the main call
Zoltan: yes, we should transfer this, not close this
Zoltan: check the Generic Sensor API how this could be dealt
with
[16]https://www.w3.org/TR/
generic-sensor/#concepts-sampling-and-reporting-frequencies
[16] https://www.w3.org/TR/generic-sensor/#concepts-sampling-and-reporting-frequencies
Kaz: warning to not add big features at this point given the
charter period.
Daniel: call adjourned
Minutes manually created (not a transcript), formatted by
[17]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).
[17] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 20 September 2021 08:44:20 UTC