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

[Scripting] minutes - 1 June 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 09 Jun 2020 16:28:48 +0900
Message-ID: <87a71cvgsv.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

01 Jun 2020


          Kaz_Ashimura, Cristiano_Aguzzi, Tomoaki_Mizushima,
          Zoltan_Kis, Michael_McCool





     * [2]Topics
         1. [3]Prev minutes
         2. [4]PR
         3. [5]should we extend consume() to accept a URL in
            simple case?
     * [6]Summary of Action Items
     * [7]Summary of Resolutions

   <scribe> scribe:zkis

Prev minutes

   <kaz> [8]May 25

      [8] https://www.w3.org/2020/05/25-wot-minutes.html

   Minutes approved

PR [9]https://github.com/w3c/wot-scripting-api/pull/209

      [9] https://github.com/w3c/wot-scripting-api/pull/209

   Zoltan: reviewing the PR

   McCool: should add editor's note to specify how the spec will
   be evolving later, wrt Protocol Bindings

   Zoltan: question: should readMultiple fail is not possible with
   a single network request?

   McCool: yes

   Cristiano: yes

   Zoltan: some help will be needed on defining how to handle URI

   Cristiano: there is an RFC 6570

   Zoltan: maybe if there is anything in the Fetch Standard

   Cristiano: question about arrayBuffer()
   ... the function reads all the bytes
   ... does that include decoding?

   Zoltan: same as with the Body mixin, just providing the bytes
   ... value() now fails early if it can tell it has no chance to
   ... should we allow implementations to duplicate the stream?

   Cristiano: it would be overengineering
   ... we could leave it this was and change later if needed

   Zoltan: on "check data schema", if there is an external
   algorithm available, let's change
   ... on writing, if schema is a string and source is not, should
   we use JSON serialization?

   Cristiano: need to think about that

   Zoltan: let's create an issue

   Cristiano: yes and experiment

   Zoltan: OK, this was it. Still waiting on Daniel's input.
   ... will add the editor's notes

should we extend consume() to accept a URL in simple case?

   <kaz> [10]D. Full Web IDL

     [10] https://www.w3.org/TR/wot-scripting-api/#idl-index

   McCool: make sure it is clear it's a URL and not a string TD
   ... if it needs security info, the runtime needs to be

   Zoltan: right

   Cristiano: currently if we use Fetch we are limiting to HTTP,
   so we cannot use CoAP
   ... if we include URL then we could use other bindings
   ... so this is a welcome idea

   McCool: actually packet size limitations might be an issue with
   ... on short term it is likely that distributing TD's would be
   HTTP based

   Zoltan: that is great information

   McCool: we will study distributing via CoAP

   Zoltan: CoAP would work well with constrained devices that
   don't have HTTP stack but have CoAP support

   McCool: doubt we'll do distribution with CoAP, but with CoAPS
   ... CoAP over TCP could be a solution
   ... anyway, the Scripting API should be independent

   Zoltan: will create an issue or revive old issue to discuss

   [meeting adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [11]scribe.perl version ([12]CVS log)
    $Date: 2020/06/04 21:20:43 $

     [11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [12] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 9 June 2020 07:28:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 9 June 2020 07:28:06 UTC