W3C home > Mailing lists > Public > public-wot-wg@w3.org > September 2020

[Scripting] minutes - 14 September 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 28 Sep 2020 18:23:34 +0900
Message-ID: <87lfgui7ah.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the minutes, Zoltan!



      [1] http://www.w3.org/

                           WoT Scripting API

14 Sep 2020


          Kaz_Ashimura, Zoltan_Kis, Cristiano_Aguzzi,
          Tomoaki_Mizushima, Daniel_Peintner





     * [2]Topics
         1. [3]past minutes
         2. [4]https://github.com/w3c/wot-scripting-api/pulls
         3. [5]PR 263,
         4. [6]PR 260
         5. [7]PR 244,
         6. [8]PR262:
         7. [9]PR 261,
         8. [10]Ege's review
         9. [11]issue 258,
        10. [12]issue 242,
        11. [13]next call
     * [14]Summary of Action Items
     * [15]Summary of Resolutions

   <scribe> Agenda:

     [16] https://github.com/w3c/wot-scripting-api/pulls,
     [17] https://github.com/w3c/wot-scripting-api/issues

   <scribe> scribe: zkis

past minutes


     [18] https://www.w3.org/2020/08/31-wot-minutes.html

   Past minutes approved.


     [19] https://github.com/w3c/wot-scripting-api/pulls

PR 263, [20]https://github.com/w3c/wot-scripting-api/pull/263

     [20] https://github.com/w3c/wot-scripting-api/pull/263

   Daniel: will review today

PR 260 [21]https://github.com/w3c/wot-scripting-api/pull/260

     [21] https://github.com/w3c/wot-scripting-api/pull/260

   Looks good, merged.

PR 244, [22]https://github.com/w3c/wot-scripting-api/pull/259

     [22] https://github.com/w3c/wot-scripting-api/pull/259

   Zoltan: this has a problem, mentioned in the PR

   Daniel: we may init lazily, not in consume()

   Zoltan: when to init then?

   Daniel: when interactions are called, they could be init'd then

   Cristiano: yes, that could work
   ... what we need to decide if we fail early, or during the
   interactions (if they are not set up correctly, or there is an
   ... I have no problem with consume() being a bit different than

   Zoltan: consume() could fail early and constructor could use
   lazy init

   Cristiano: this could work, need to think

   Daniel: we should not fail for something implementations can

   Cristiano: that's a valid point as well

   Daniel: and this is also valid on exposed things as well as
   consumed things
   ... so we should fail only when things cannot work

   Cristiano: similarly, for security, we should be flexible, e.g.
   if one of the schemes work, it should be fine
   ... we could lazily push error

   Zoltan: I agree, also because the nature of these comms is
   async, over various protocols so we cannot guarantee to fail
   ... TD validation is only syntactic, not functional

PR262: [23]https://github.com/w3c/wot-scripting-api/pull/262

     [23] https://github.com/w3c/wot-scripting-api/pull/262

   Zoltan: there is a question about global consistency of Forms
   (e.g. every interaction has a CoAP form)

   Daniel: we should be flexible here

   Cristiano: we need the flexibility
   ... we have an open issue about ops and also about default
   ... TD issue 957

   Zoltan: please put any ideas for the expose() algorithm in the

   Daniel: again the vote goes for flexibility

   Cristiano: we should not expose something we cannot handle

   Zoltan: right, we could remove the constraint

   Daniel: yes, a TD is not necessarily by this runtime

   Zoltan: we can leave it generic - on the other hand that step
   is very complex and we have no good description of it
   ... but for now I will remove the sentence

   Cristiano: architecturally we cannot enforce form existence or

PR 261, [24]https://github.com/w3c/wot-scripting-api/pull/261

     [24] https://github.com/w3c/wot-scripting-api/pull/261

   Zoltan: trivial change, done what the issue proposed

   Cristiano: right

   Daniel: looks good


Ege's review

   Zoltan: did we cover all issues raised from the review
   ... I need to check that.

   <scribe> ACTION: ZK to check if there are issues not handled
   from Ege's review

issue 258, [25]https://github.com/w3c/wot-scripting-api/issues/258

     [25] https://github.com/w3c/wot-scripting-api/issues/258

   Zoltan: in the light said today, what should we do for this

   Cristiano: right, we need to rething that
   ... will comment later

issue 242, [26]https://github.com/w3c/wot-scripting-api/issues/242

     [26] https://github.com/w3c/wot-scripting-api/issues/242

   Daniel: here as well we should apply the flexibility argument

   Zoltan: if the TD designer specified these constraints, they
   should be respected

   Cristiano: agree with the need of checking
   ... at least with the convenience methods
   ... of the value() function

   Daniel: had a similar problem in the past, sometimes schemas
   are too refined and restricted; often the implementations
   cannot be that rigurous

   Cristiano: we should check what JSON Schema does

   Zoltan: let's do that

next call

   Cristiano: propose an agenda to talk about TypeScript

   Daniel: we said we should have a spec before the plugfest, but
   we should at least solve subscribe/unsubscribe


Summary of Action Items

   [NEW] ACTION: ZK to check if there are issues not handled from
   Ege's review

Summary of Resolutions

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [27]scribe.perl version ([28]CVS log)
    $Date: 2020/09/21 14:12:49 $

     [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [28] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 28 September 2020 09:23:40 UTC

This archive was generated by hypermail 2.4.0 : Monday, 28 September 2020 09:23:41 UTC