[Scripting] minutes - 24 February 2020

available at:
  https://www.w3.org/2020/02/24-wot-minutes.html

also as text below.

Thanks a lot for takint the minutes, Zoltan!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                             WoT Scripting

24 Feb 2020

Attendees

   Present
          Kaz_Ashimura, Daniel_Peintner, Michael_McCool,
          Tomoaki_Mizushima, Zoltan_Kis

   Regrets

   Chair
          Zoltan

   Scribe
          zkis

Contents

     * [2]Topics
         1. [3]Accepting past minutes
         2. [4]PR 203
         3. [5]Error handling
         4. [6]Issue #201
         5. [7]Issue #193
         6. [8]Issue #204
         7. [9]AOB?
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: zkis

Accepting past minutes

   <kaz> [12]Feb-17 minutes

     [12] https://www.w3.org/2020/02/17-wot-minutes.html

   Past minutes accepted

PR 203

   <kaz> [13]PR 203

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

   Zoltan presented the PR changes: added formIndex as a hint for
   implementation, and clarified the use of write handlers

   Zoltan: the PR has been reviewed, approved and merged
   ... it fixed two issues, 199 and 202

Error handling

   Daniel introduces the issue #200

   [14]Issue 200

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

   Daniel: would say the table in Ege's comment should be
   informative

   Zoltan: agree that it should be informative
   ... we can include this into the algorithms

   McCool: we need to define what is the behavior if a non-mapped
   error happens

   Daniel: some errors indicate if an unspecified error occured
   ... showing "UnknownError" as an example
   ... in the basic use cases we do need a clear mapping
   ... but there might be error that could be classified in many
   ways

   Zoltan: what about the error data?

   Daniel: we could use the error code, but no lengthy error
   messages or error data
   ... up to the implementation to harden that part

   Zoltan: nevertheless, the spec should have some guidance on
   what data to include with errors

   Daniel: is there an issue with privacy if we don't specify in
   the spec?

   McCool: we should maybe have guidelines and good practices, but
   implementations can decide to follow them

   Daniel: need to check node-wot in this respect (what data is
   exposed in errors)

   Zoltan: we can make a note until we know exactly how to curate
   the error data

   Daniel: let this issue be the single place to contribute to the
   error mapping
   ... or create a PR?

   Zoltan: I can create a PR that can be left open, in order to
   experiment, but the primary place to discuss and contribute
   would be in the issue

Issue #201

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

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

   Daniel: we have an open PR in the TD spec that is related

   <dape>
   [16]https://github.com/w3c/wot-thing-description/pull/869

     [16] https://github.com/w3c/wot-thing-description/pull/869

   Zoltan: we could still describe the current way of how things
   are supposed to work
   ... and use the information from the PR

   Daniel: that is right; we should link the PR and the issue

Issue #193

   [17]https://github.com/w3c/wot-scripting-api/issues/193

     [17] https://github.com/w3c/wot-scripting-api/issues/193

   Daniel presents the issue

   Zoltan: there was a question which Form would be used for
   reporting the written value

   McCool: here as well it applies that implementations define the
   behavior and the TD should describe interactions correctly
   ... a safe assumption is to say writes never return a value,
   and you need to define an action if you want a value back

   Daniel: seems there is no consensus on this

   Zoltan: you can't figure out precision from the value
   (assumingly) reported by the write

   McCool: that would need an action with a defined output schema

   Zoltan: I agree

   McCool: I agree with the current spec that returns
   Promise<void> because it handles all cases correctly

   Daniel: looks like the discussion goes into the direction to
   keep the current way, because it gets tricky how to do the
   alternative correctly

   McCool: we need to log a design decision and an editor's note,
   in order to avoid duplicating the discussion

   Daniel: one possibility is to record the decision

   McCool: we need a separate document to summarize the key design
   decisions

   <scribe> ACTION: Zoltan make a PR with a note and explanation,
   and update the explainer

Issue #204

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

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

   McCool: I propose to discuss this in the Discovery TF
   ... and we would track Scripting related aspects in this issue

AOB?

   AOB?

   none

   [adjourned]

Summary of Action Items

   [NEW] ACTION: Zoltan make a PR with a note and explanation, and
   update the explainer

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [19]scribe.perl version 1.154 ([20]CVS log)
    $Date: 2020/02/24 23:50:49 $

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [20] http://dev.w3.org/cvsweb/2002/scribe/

Received on Monday, 2 March 2020 12:52:26 UTC