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

[Scripting] minutes - 27 January 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 05 Feb 2020 14:29:12 +0900
Message-ID: <87v9olk3fb.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/

                               - DRAFT -

                           WoT Scripting API

27 Jan 2020


          Kazuyuki_Ashimura, Daniel_Peintner, Michael_McCool,
          Zoltan_Kis, Tomoaki_Mizushima, Ege_Korkan





     * [2]Topics
         1. [3]review 2 previous minutes
         2. [4]issue discussion
     * [5]Summary of Action Items
     * [6]Summary of Resolutions

   <scribe> Agenda: issues discussion

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

   <scribe> scribe: zkis

review 2 previous minutes

   <kaz> [8]Jan-13 minues

      [8] https://www.w3.org/2020/01/13-wot-minutes.html

   <kaz> [9]Jan-20 minutes

      [9] https://www.w3.org/2020/01/20-wot-minutes.html

   <inserted> scribenick: kaz

   Zoltan: any problems?
   ... can we approve those minutes?

   <inserted> scribenick: zkis

   Minutes approved

   They can go public.

issue discussion


     [10] https://github.com/w3c/wot-scripting-api/issues/198

   Zoltan: introduced issues 198 (closed in favor of issue 201). 2
   ways forward on how to handle content in the Scripting API


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

   Ege: the discussion seems reasonable, both arguments make
   sense. When mentioning fetch(), didn't mean explicit

   Zoltan: text() and json() only handle 2 media types and we
   still cannot avoid a generic opaque DataView

   Daniel: agree that some content apps want to parse themselves

   Ege: right

   Zoltan: we could explore both paths by creating code examples
   ... for instance like this:

     [12] https://w3c.github.io/web-nfc/#write-and-read-json-serialized-and-deserialized


     [13] https://w3c.github.io/web-nfc/#read-data-from-tag-and-write-to-empty-ones

   Daniel: this is similar to node-wot content handling

   Ege: how can the consumer choose the Form?

   Zoltan: yes, we have that gap now

   Ege: issue 201 might cover it

   Daniel: currently we just get back the raw data, and we can
   parse it according to the Form

   Ege: node-woth just chooses the first Form

   Daniel: if the Property is reachable via CoAP and HTTP, the
   client is not interested how it gets the data, it just picks
   the first one

   Ege: there is an internal assumption to pick the first Form
   ... it should be based on op, security, content type etc - and
   currently there is no decision made on the content type
   ... in Scripting we could make the simplification that JSON is
   picked if available
   ... based on Scripting level requirements; developer puts the
   type as an option

   Zoltan: should we mix scripting options and interaction

   Daniel: an additional optional dictionary could be used

   Looking into InteractionOptions possibilities in the TD spec

   Zoltan: we could use the TD for the app specified the order of
   the Forms that implementation should use
   ... we could have sensible defaults: if app does not specify
   Form, then the implementation should choose

   Ege: right, and each implementation should document which is
   their default

   McCool: the TD itself needs to indicate the priority in the
   list of Forms (that implementations should try until succeed)


     [14] https://github.com/w3c/wot/blob/master/testing/tests/2019-05/inputs/Intel/intel-camera.json

   Ege: implementations should then figure out if they are in a
   local network, or can reach the Internet etc
   ... so once the TD is consumed, during consuming is there a
   reordering of Forms according to local context?

   McCool: this is a decision we need to make in the spec

   Zoltan: we should aim for stateless Scriping implementations:
   if there is a choice, give it to the app

   Daniel: if there is a Property reachable by CoAP and HTTP, how
   can the app choose?

   Zoltan: yes, by passing the object describing the Form

   Daniel: sound complicated since the impl has to identify the

   Zoltan: so what is the simplest way to identify a Form?
   ... is the href + other field enough, or should the impl
   generate a hash when consuming, then app provide the hash?

   Daniel: that is simplest
   ... to use an index

   Daniel: we should define the InteractionOptions dictionary for
   used inside Scripting, not the TD

   Ege: right

   Zoltan: we should maybe file an issue about defining

   <scribe> ACTION: ZK create issue about InteractionOptions

   <ege> [15]https://swagger.io/specification/#requestBodyObject

     [15] https://swagger.io/specification/#requestBodyObject

   Ege: linked OpenAPI definition of various content types

   Zoltan: time is up, but next time we continue, and also take
   the rest of the issues
   ... AOB?

   Next time, first thing is to approve these minutes, so please
   take a look in advance. Thanks!


Summary of Action Items

   [NEW] ACTION: ZK create issue about InteractionOptions

Summary of Resolutions

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [16]scribe.perl version 1.154 ([17]CVS log)
    $Date: 2020/02/03 01:21:33 $

     [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [17] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 5 February 2020 05:29:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 5 February 2020 05:29:18 UTC