[Scripting] minutes - 30 August 2021

available at:
  https://www.w3.org/2021/08/30-wot-script-minutes.html

also as text below.

Thanks a lot for taking the minutes, Zoltan!

Kazuyuki

---
   [1]W3C

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

                           WoT Scripting API

30 August 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#30_August_2021
      [3] https://www.w3.org/2021/08/30-wot-script-irc

Attendees

   Present
          Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura,
          Tomoaki_Mizushima, Zoltan_Kis

   Regrets
          -

   Chair
          Daniel

   Scribe
          kaz, zkis

Contents

    1. [4]Minutes
    2. [5]PRs
         1. [6]PR 332
         2. [7]Label Table, https://github.com/w3c/
            wot-scripting-api/pull/333
    3. [8]issues discussion
         1. [9]Separate ExposedThing API, https://github.com/w3c/
            wot-scripting-api/issues/303
         2. [10]TypeScript - Type DataSchemaValue circularly
            references itself, https://github.com/w3c/
            wot-scripting-api/issues/301
         3. [11]error handling

Meeting minutes

  Minutes

   [12]Aug-23

     [12] https://www.w3.org/2021/08/23-wot-script-minutes.html

   Daniel: (goes through the minutes)

   Daniel: approved and will be published

  PRs

    PR 332

   [13]PR 332 - fix: links *new* typescript folder

     [13] https://github.com/w3c/wot-scripting-api/pull/332

   Daniel: the PR fixes a small issue with links

    Label Table, [14]https://github.com/w3c/wot-scripting-api/pull/333

     [14] https://github.com/w3c/wot-scripting-api/pull/333

   Daniel: updates the labels we use in github
   … and documents it

   Daniel: there are a lot of unused labels (without any issues
   using them), propose to remove them.

   Zoltan: makes sense

   Cristiano: I would keep some labels, like bug and duplicate,
   they might be still useful
   … I've seen them in other repositories as well

   Daniel: we don't use them right now

   Cristiano: I think that is not a problem with such generic
   labels

   Daniel: should we also include these in the Readme?

   Cristiano: yes, why not

   Zoltan: a table in a readme needs maintaining, syncing with the
   real labels

   Daniel: we could also link to the github generated list

   Zoltan: and include descriptions there

   Kaz: I'm fine with keeping several unused labels
   … we should be consistent across the whole WG how to use labels
   … propose to discuss this in the main call
   … it's fine to remove unused labels, and to use github
   descriptions to explain the labels

   <kaz> [15]GitHub labels for wot-scripting-api repo

     [15] https://github.com/w3c/wot-scripting-api/issues/labels

   Daniel: OK, things are converging, we can do this way

   Cristiano: +1 for discussing within the WG

   Daniel: so I will modify the PR to just link to the label list

  issues discussion

   Daniel: we can talk about discovery and TD
   … the discussion about writeProperty() was discussed in the TD
   TF, but many calls were canceled and we should wait on that
   … any preferred topics?

    Separate ExposedThing API, [16]https://github.com/w3c/
    wot-scripting-api/issues/303

     [16] https://github.com/w3c/wot-scripting-api/issues/303

   Cristiano: trying to implement the separate ExposedThing API in
   node-wot

   Cristiano: do we have consensus about this change?

   Daniel: it's a bit scattered over issues

   Cristiano: should I experiment in node-wot about this?

   Zoltan: I think yes

   Daniel: we dropped ExposedThing extending ConsumedThing

   Zoltan: and they are in separate conformance classes already

   Cristiano: so the issue is something more, right?

   Zoltan: it was mainly to separate ExposedThing to a different
   spec (client-server API separation)

   Cristiano: so it's about split implementation, and maybe split
   spec?

   Daniel: I am not sure this is where we should head towards
   … we do have 3 conformance classes already
   … splitting the doc doesn't seem necessary

   <kaz> [17]wot-scripting - 3. Conformance

     [17] https://w3c.github.io/wot-scripting-api/#conformance

   Daniel: asking ZK to take a look at the issue and eventually
   rename it

    TypeScript - Type DataSchemaValue circularly references itself,
    [18]https://github.com/w3c/wot-scripting-api/issues/301

     [18] https://github.com/w3c/wot-scripting-api/issues/301

   Daniel: checking to close/remove it
   … it's solved already, so removing it

    error handling

   <dape> Error Handling, [19]https://github.com/w3c/
   wot-scripting-api/issues/200

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

   Daniel: this is a bit unclear, also raised in the WoT Profile
   TF
   … it's not easy to detect which binding the issue appeared in

   Zoltan: should WoT abstract not only the positive protocol
   outcomes, but also the negative ones?

   Daniel: in some cases it would be good to know about the
   bindings error info
   … we already have some way to select a form index

   Zoltan: it has privacy reasons to hide that information from
   web pages

   Daniel: Ege provided an error mapping list, but I think it gets
   very nasty with more protocols added
   … so what should we do with this issue?

   Zoltan: this is a runtime issue, we could use log levels

   Cristiano: log levels make it inconvenient to use from
   application logic
   … it would be better to standardize the list of errors
   … if we can do mapping, it will be the best option
   … but even if not, developers should be able to do something
   about the errors from the proper code
   … not only for debugging, but for alternative business logic

   Zoltan: let's leave this open then, it's important because it
   may affect the API shape

   Daniel: we could have the mapping, and for each method list the
   errors

   <kaz> [20]see also the Issue 200 - Error Handling

     [20] https://github.com/w3c/wot-scripting-api/issues/200

   Zoltan: we already have that in the algorithms

   Daniel: we still miss e.g. NotFoundError

   <kaz> [21]e.g., 7.4 The readProperty() method

     [21] https://w3c.github.io/wot-scripting-api/#the-readproperty-method

   Zoltan: then let's make a separate issue about that

   Daniel: OK, creating an issue

   Cristiano: we should re-read the spec, looking for things that
   can go sideways
   … not sure we are covering all the use cases

   Daniel: we do use NotFoundError in node-wot

   Daniel: also, we may use multiple security levels, global level
   and form level

   Cristiano: right now we just have global security, e.g. you can
   either read or not a property

   Daniel: time out, we continue in the issues

   adjourned


    Minutes manually created (not a transcript), formatted by
    [22]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

     [22] https://w3c.github.io/scribe2/scribedoc.html

Received on Monday, 20 September 2021 09:00:46 UTC