[Scripting] minutes - 30 arch 2020

available at:
  https://www.w3.org/2020/03/30-wot-minutes.html

also as text below.

Thanks a lot for taking the minutes, Zoltan!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                             WoT Scripting

30 Mar 2020

Attendees

   Present
          Kaz_Ashimura, Daniel_Peintner, Ege_Korkan, Zoltan_Kis,
          Tomoaki_Mizushima

   Regrets

   Chair
          Zoltan

   Scribe
          zkis

Contents

     * [2]Topics
         1. [3]Past minutes
            https://www.w3.org/2020/03/23-wot-minutes.html
         2. [4]Issues, #208
            https://github.com/w3c/wot-scripting-api/issues/208
         3. [5]Issue_204
            https://github.com/w3c/wot-scripting-api/issues/204
         4. [6]Issue_201
            https://github.com/w3c/wot-scripting-api/issues/201
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: zkis

Past minutes [9]https://www.w3.org/2020/03/23-wot-minutes.html

      [9] https://www.w3.org/2020/03/23-wot-minutes.html

   past minutes approved

   Daniel: MMc also asked for approving the F2F minutes

   <kaz> [10]monday minutes

     [10] https://www.w3.org/2020/03/16-wot-minutes.html

   no objections, minutes approved

Issues, #208 [11]https://github.com/w3c/wot-scripting-api/issues/208

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

   Daniel: on the TD call the issue was acknowledged and more work
   is needed on the Event affordance

   Ege: we need some ideas from existing experience, e.g. M.
   Lagally

   Zoltan: does it make sense to expose subscribe id's or keep
   them private in the impl?

   Ege: usually not, except perhaps in few use cases
   ... subscription payload might make sense in certain
   application
   ... maybe we can say if there is a use case, we come back to
   this

   Zoltan: so until then we identify events by names in Scripting

   Daniel: the implementations needs to keep them as a state
   ... today we don't expose the subscriber id's
   ... we don't fully support yet any filtering on events

   Zoltan: do implementations understand subscription data or is
   it opaque?
   ... in the current bindings?

   Daniel: at most we pass subscription data along in node-wot

   Zoltan: the Oracle use case would need that node-wot passes on
   the data

   Daniel: yes

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

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

   DP made a semantic layer prototype in
   [13]https://github.com/danielpeintner/thingweb.node-wot/commit/
   844e199357d84494030549dadd655d20fe8a0706

     [13] https://github.com/danielpeintner/thingweb.node-wot/commit/844e199357d84494030549dadd655d20fe8a0706

   Daniel: this is a layer built on the top of the existing
   Scripting API
   ... enables fetching e.g. a semantic Property
   ... supported for ConsumedThing
   ... this is for experimenting

   Zoltan: I like it's a layered approach, like a library; not
   sure we should standardize yet

   Daniel: it would be good to standardize

   Ege: would not oppose this, and should be standardized

   Zoltan: the standardization could happen in a new spec, like
   Generic Sensor vs Accelerometer specifications

   <kaz> [14]6. The ConsumedThing interface

     [14] https://w3c.github.io/wot-scripting-api/#the-consumedthing-interface

   Zoltan: it could be separate conformance class

   Daniel: it makes sense to do it in other spec that extends the
   current API
   ... we should get M. Koster and other and experiment with it in
   plugfests etc
   ... for instance about parameters etc
   ... we should look into semantic extensions

   Zoltan: what are next steps? plugfest PoC?

   Daniel: will work on implementation in node-wot, but need input
   and feedback from M. Koster and others

   Zoltan: so first part of the work will be in node-wot

   Daniel: there will be the plugfest call, any plans for the
   virtual plugfest?

   Ege: there was the VPN tool proposed and needs to be tested
   ... so that we could make virtual plugfests easiers

   <kaz> [15]Mar-25 PlugFest minutes

     [15] https://www.w3.org/2020/03/25-wot-pf-minutes.html

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

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

   Zoltan: should we introduce a Scripting-specific data
   description type that would merge mediaType (contentType from
   Forms) and DataSchema?
   ... otherwise in order to extend the algorithms, we'd need to
   define everything the TD spec defines

   Daniel: going with Value would be fine, we don't even need
   DataSchema there
   ... it's repetitive

   Zoltan: that is true also for mediaType

   Daniel: we need the mediaType because we don't know which form
   was used
   ... app can look just at the mediaType

   Zoltan: we can get DataSchema by property name from the TD

   Daniel: right
   ... we need this both on input and output
   ... we still need the formIndex in InteractionOptions

   Zoltan: I can create an experimental PR for this

   Ege: makes sense to me, too

   Daniel: the only fear is to break existing implementations

   Zoltan: that requires some thinking
   ... should we include API version in the spec?

   Daniel: never seen a good solution with a version

   Zoltan: let's continue in the issue discussion

   <kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [17]scribe.perl version 1.154 ([18]CVS log)
    $Date: 2020/04/07 05:52:31 $

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

Received on Tuesday, 7 April 2020 05:53:59 UTC