- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 01 Mar 2021 15:16:06 +0900
- To: public-wot-wg@w3.org
available at: https://www.w3.org/2021/02/08-wot-script-minutes.html also as text below. Thanks, Kazuyuki --- [1]W3C [1] https://www.w3.org/ WoT Scripting API 08 February 2021 [2]Agenda. [3]IRC log. [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#8_February_2021 [3] https://www.w3.org/2021/02/08-wot-script-irc Attendees Present Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis Regrets - Chair Daniel Scribe kaz Contents 1. [4]Prev minutes 2. [5]Quick updates 3. [6]PR 289 4. [7]Issue 296 Meeting minutes Prev minutes [8]Feb-1 [8] https://www.w3.org/2021/02/01-wot-script-minutes.html (goes through the minutes) Kaz: (fixes the URLs and also adds the titles to Issues and PRs) Quick updates we're renaming the "master" branch to "main" PR 289 [9]Add definitions for partialTD #289 [9] https://github.com/w3c/wot-scripting-api/pull/289 (shows the diff) [10]diff - 5.2.1 Use an ExposedThingInit [10] https://pr-preview.s3.amazonaws.com/w3c/wot-scripting-api/289/ef9c211...relu91:66d5a75.html#use-an-exposedthinginit Cristiano: (explains the algorithm there) expanding the step 7 to search for missing required properties? what about the default values? Cristiano: we can assume empty as default but that would not be valid TD … see also section 4.2 [11]4.2 Expanding a Thing Description [11] https://pr-preview.s3.amazonaws.com/w3c/wot-scripting-api/289/ef9c211...relu91:66d5a75.html#expanding-a-thing-description Zoltan: can understand Daniel's point, but we need to specify the algorithm clearly here it's true we should be clear … but we should not be too restrictive Zoltan: we should add that kind of notes Cristiano: think it's specific enough but not too restrictive Zoltan: we could add some guidance on how to handle 'href' also 'title' (some more discussion) maybe the step 7 ( Search for missing required properties in td accordingly to TD JSON Schema) can be preserved asis … and the detail to be defined separately Zoltan: iterative approach to improve the description is fine Kaz: accepting this proposed algorithm is ok by me … but we should add some concrete example TD to be parsed here … also we should clarify which step handles which TD fragment or token because some of the steps lack the detail Cristiano: agree with both the comments right … we should add concrete TD example here Zoltan: the note for step 7 (TODO: possibly expand this step) could be added as an Editor's note yes Cristiano: totally agree … should have examples on "before the step" and "after the step" Kaz: maybe we can simply merge this PR 289 itself and then think about further improvement later Cristiano: would like to think about security portions as well we should consider proper security scheme as well … regarding the step 4 … "For each scheme defined in securityDefinitions check if it is supported by the Protocol Bindings . if not remove scheme" … it's OK to have only one Protocol Binding which supports some security scheme Cristiano: ok let's ask McCool for guidance too … how to make sure the users' suggestions are fulfilled? … (gives the comments to PR 289) … thanks, Cristiano! Issue 296 [12]DataSchemaValue in TS should not be any #296 [12] https://github.com/w3c/wot-scripting-api/issues/296 [13]related PR - make TS definitions for DataSchemaValue more accurate #297 [13] https://github.com/w3c/wot-scripting-api/pull/297 Cristiano: there was another PR as well [14]another PR - Simplification of interface InteractionOutput #292 [14] https://github.com/w3c/wot-scripting-api/issues/292 Zoltan: it's already clear and implemented (shows section 6.2.1 of the Editor's Draft) [15]6.2.1 The value() function - wot-scripting-api ED [15] https://w3c.github.io/wot-scripting-api/#the-value-function what is problematic to me is the step 2 at section 6.2.1 … "If the value of the [[value]] internal slot is not undefined, resolve promise with that value and abort these steps." Zoltan: the WoT Scripting API is for the implementer of the Scripting API developers … we need to check the algorithm to see who is generating what actually, section 6.1 states "DataSchemaValue is an ECMAScript value that is accepted for DataSchema defined in [WoT-TD] (i.e. null, boolean, number, string, array, or object)." [16]6.1 The InteractionInput type [16] https://w3c.github.io/wot-scripting-api/#the-interactioninput-type would like to think about how to fix the description … at DataSchemaValue definition Zoltan: the proposed change at PR 297 is fine [17]changes within PR 297 [17] https://github.com/w3c/wot-scripting-api/pull/297/files (some more discussion) (adds comments based on Zoltan's advice) [18]Daniel's comment [18] https://github.com/w3c/wot-scripting-api/pull/297#issuecomment-775135788 [adjourned] Minutes manually created (not a transcript), formatted by [19]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC). [19] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 1 March 2021 06:16:20 UTC