- 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/ ¡V DRAFT ¡V 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 ¡K though a date in a version is not common ¡K 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 ¡K 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 ¡K based on Sebastian's comment on ExpectedResponse, we might need to re-check ¡K 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 ¡K for instance timeout with HTTP ¡K 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 ¡K 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