- 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