[Scripting] minutes - 25 January 2021

available at:
  https://www.w3.org/2021/01/25-wot-script-minutes.html

also as text below.

Thanks a lot for taking the minutes, Cristiano!

Kazuyuki

---
   [1]W3C

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

                           WoT Scripting API

25 January 2021

   [2]Agenda. [3]IRC log.

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

Attendees

   Present
          Cristiano_Aguzzi, Kaz_Ashimura, Tomoaki_Mizushima,
          Zoltan_Kis, Daniel_Peintner

   Regrets
          -

   Chair
          Daniel

   Scribe
          cris

Contents

    1. [4]previous minutes
    2. [5]open PRs

Meeting minutes

  previous minutes

   <dape> Previous minutes, see [6]https://www.w3.org/2021/01/
   18-wot-script-minutes.html

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

   Daniel: we merge a PR from kaz and then discussed about the new
   term in architecture: PartialTD
   … it was a long discussion
   … and it is still open
   … we'll discuss today again. Cristiano made a PR about it
   … we discussed also about versioning. The issue is still open.
   We need more experience about the problem
   … any problem with the minutes?

   Crstiano: ok

   Zoltan: ok

   Daniel: ok, minutes published

  open PRs

   <dape> [7]https://github.com/w3c/wot-scripting-api/pull/291

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

   Daniel: minor issue
   … propertyReadHandler should return InteractionInput
   … previously it returned any
   … in the same PR I changed also any types in TS definition

   Zoltan: in web IDL we could use undefined and in TS use void

   Crstiano: I agree with Zoltan

   Daniel: I agree with you too, I'll change the PR accordingly.
   … ok issue resolved.
   … next PR is from Cristiano. It is about PartialTD

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

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

   Daniel: the changes are lager than I expected

   Crstiano: I changed the produce method and the ExposedThing
   constructor

   Daniel: zoltan commented that the PartialTD type could be
   renamed to init
   … from my side I'd a minor change. Basically, rename the
   argument and mention the details in the algorithm

   Zoltan: we can separate the type name from the validation
   algorithm.
   … I prefer a more web platform compliant term like
   ThingDescriptionInit
   … decuppling this two would improve the understanding

   Daniel: TD is used both as argument in construction for
   consumed and return type with the getThingDescription method
   … I'd like to reuse the returned object from
   getThingDescription as a produce argument

   Zoltan: it is part of the use case. We still could use thing
   Init with a better description

   Daniel: as I user I'd like to use the full TD returned by
   getThingDescription without any processing
   … quite similar to the algorithm defined in the PR

   Zoltan: my comment it's only about the name. I agree with the
   rest

   Daniel: ok. For sure we need the algorithm as presented in the
   PR

   Zoltan: my opinion is that the input is an object. We could use
   that type but the best practice is to name it differently to
   convey semantics.

   Zoltan: we should define also an algorithm to validate the
   output of the produce method
   … my point is that I don't like the name of the type. PartialTD
   is a bit confusing

   <zkis> CA: introducing a new term might be confusing

   <zkis> ... partial TD term is used in our use cases

   <zkis> DP: partial TD is only used in Scripting

   Zoltan: his proposing to remove the PartialTD from the
   architecture

   Zoltan: yeah it could be the right choice
   … we need a good name and we can move on.

   Crstiano: My last open point is weather if a partial TD will
   not ever used somewhere else

   Daniel: maybe it is closer to the ThingModel

   Zoltan: we could define a ThingDescription and add a new object
   called "input"
   … there we could even also accept a ThingModel

   Crstiano: let's start with ThingInit

   Zoltan: it is better ExposeThingInit

   Crstiano: right

   Daniel: so we need just to rename PartialTD to ExposeThingInit
   and then discuss the algorithms

   Crstiano: the algorithms need some more work

   Zoltan: the algorithms are fine IMO

   Crstiano: there are some TODOs

   Daniel: yes we could discuss that next time

   Crstiano: we could use JSON schema patch feature

   Daniel: yes it was proposed by Andrew
   … it would be much easier to have a external algorithm

   Kaz: adding this kind of algorithms is good. I think we should
   clarify the reasons why we are adding this capabilities, as I
   mentioned in other calls

   Daniel: the intent now is to remove partial TD from
   architecture, because we are the only one to use it

   Kaz: we're talking about partial TD, TD fragment and Thing
   Model during the Architecture call and the TD call. So in any
   case, we need to continue the discussion on this in the next
   architecture call.
   … we are on the same page.

   Zoltan: we need this concept also in other places. So it may be
   probably better to define it in the architecture

   Zoltan: for example in the node-red runtime they are probably
   using a similar concept

   Daniel: sure but it is up to them how to initialize an exposed
   thing

   Zoltan: but they should follow a common algorithm

   <zkis> CA: maybe not every client would accept the same
   algorithm for Thing init

   Crstiano: probably other implementations would not follow a
   common algorithm

   Zoltan: it is not like they can do whatever they want

   Daniel: how internally set up the whole exposed thing is not
   strictly specify. It is critical to provide the some outcome

   Crstiano: I agree

   Zoltan: so Why are we defining the algorithm in our spec?

   Daniel: it is difference it is for scripting consistency.

   Daniel: there're a bunch of details that would need to be
   specified in the exposing process

   Kaz: scripting api task force can define its terms. We should
   clarify why we end up with this decision. Examples could help a
   lot. Also how to use this partial TDs in applications

   <zkis> Summarizing, the TD spec specifies the expected outcome
   (TD), not how it is achieved when creating ExposedThing

   <zkis> In Scripting spec, we need to specify the interop
   expectations in the algorithms, for instance how to handle
   input for ExposedThing init

   Zoltan: we need to ask to the Architecture TF if they are
   interested on the PartialTD definition
   … later we can move the discussion to the architecture

   [9]https://github.com/w3c/wot-architecture/pull/577

      [9] https://github.com/w3c/wot-architecture/pull/577

   Crstiano: please add a comment about today dissussion in the PR
   above.

   Daniel: I'll try to report our point in there.

   Crstiano: I'll finish the PR, please check the alogorithms

   Daniel: Ok, there are some issues left
   … but we are overtime

   Zoltan: I could stay more
   … about implementation feedback you could raise an issue

   Daniel: I just felt that the new changes add a lot of
   complexity

   Zoltan: streams are widely used for handling generic data
   format
   … web platform is using it

   Kaz: out of time :)

   <kaz> [adjourned]


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

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

Received on Monday, 8 February 2021 11:36:46 UTC