WoT Scripting API

Prev minutes

Feb-1

(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

Add definitions for partialTD #289

(shows the diff)

diff - 5.2.1 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

4.2 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

DataSchemaValue in TS should not be any #296

related PR - make TS definitions for DataSchemaValue more accurate #297

Cristiano: there was another PR as well

another PR - Simplification of interface InteractionOutput #292

Zoltan: it's already clear and implemented

(shows section 6.2.1 of the Editor's Draft)

6.2.1 The value() function - wot-scripting-api ED

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)."

6.1 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

changes within PR 297

(some more discussion)

(adds comments based on Zoltan's advice)

Daniel's comment

[adjourned]