[Scripting] minutes - 1 February 2021

available at:
  https://www.w3.org/2021/02/01-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

01 February 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#1_February_2021
      [3] https://www.w3.org/2021/02/01-wot-script-irc

Attendees

   Present
          Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura,
          Tomoaki_Mizushima, Zoltan_Kis

   Regrets
          -

   Chair
          Daniel

   Scribe
          zkis

Contents

    1. [4]previous minutes
    2. [5]PR 289
    3. [6]implementation feedback

Meeting minutes

  previous minutes

   <kaz> [7]Jan-25

      [7] https://www.w3.org/2021/01/25-wot-script-minutes.html

   No objections, approved.

  PR 289

   <dape> [8]PR 289 - Add definitions for partialTD

      [8] https://github.com/w3c/wot-scripting-api/pull/289

   <dape> [9]related with wot-architecture issue 574

      [9] https://github.com/w3c/wot-architecture/issues/574

   Daniel: related to the issue discussed in Architecture

   Daniel: the PR was merged, so we have a definition for the
   Partial TD
   … since it may be useful for other use cases as well
   … so now we have the PR from Cristiano
   … we decided last time to rename PartialTD to ExposedThingInit

   Cristiano: yes, it's been a minor update, just a name change

   Zoltan: usually we don't make separate sections for
   dictionaries

   Cristiano: but we have 2 algorithms

   Zoltan: ok then it makes sense

   CA presents the PR

   Discussing structuring of the ExposedThingInit section into the
   produce() section
   … as subsections of produce()

   Cristiano: another thing, what to do with the table for
   generating the partial TD
   … and how to deal with possible differences in implementations
   … in order to be interoperable
   … also, take care of mandatory definitions (like security,
   context, ...)

   Daniel: if someone specifies a scheme that is not supported, it
   should replace or handle it

   Zoltan: usually we need to specify in the algorithms how to
   handle these

   Daniel: for instance, could href point to another Thing?

   Zoltan: do we do syntactic or semantic check?

   Cristiano: syntactic
   … the app might not want the impl to replace the href

   Zoltan: the TD should give us possibility for that

   Cristiano: we could use relative URI here

   Daniel: the problem is that e.g. node-wot uses the input to
   generate a full href, and the app cannot have that knowledge

   Cristiano: the input from app should be respected up to the
   level of definition: name, partial URI, or full URI
   … if it cannot be respected, then an error would be reported
   … but the parts not specified should be completed by the
   runtime
   … also, understand that we cannot use other URIs than the ones
   we own

   Daniel: need to check this

   Daniel: impls should not allow other origins in the input
   … but rather use the handlers for accessing external URLs

   Cristiano: also have a use case that the address generated by
   node-wot is not what was expected by the app
   … anyway, I agree, make it simple and don't accept other
   origins here

   Zoltan: also need a default handling for security input (e.g.
   no-security)

   Daniel: difficult to provide the right credentials for the
   exposed Thing

   Cristiano: will try to propose something and discuss in github

   Zoltan: it would be nice if the TD TF would define the exact TD
   producing

   Daniel: the TD TF is concerned only about the decoding, not the
   encoding
   … the only thing to make sure is that everyone decodes the same
   way

   Zoltan: so you say it's application's domain to describe the
   encoding

   Daniel: well, yes

   Zoltan: we should separate the pure syntactic checks from the
   semantic checks and transformations by impl
   … and feel it's a gap if we don't specify the transformations

   Cristiano: agree with that

   Daniel: so let's start with syntactic and then decide

  implementation feedback

   <dape> [10]Issue 292 - Simplification of interface
   InteractionOutput

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

   Daniel: InteractionOutput is too complex

   Zoltan: we need to support other content types than DataSchema
   … the TD permits that and it was a gap

   Cristiano: I also wonder why can't we have streams

   Zoltan: we could raise up in the main call if we want to stick
   to DataSchema

   Daniel: just not sure about this in real life
   … this will be a problem in many implementations

   Cristiano: but streams is optional, the value() function can
   throw

   Zoltan: I think any impl based on http or coap library can do
   it out of the box

   Daniel: ok, let's discuss further

   adjourned


    Minutes manually created (not a transcript), formatted by
    [11]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

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

Received on Monday, 15 February 2021 07:07:07 UTC