[Scripting] minutes - 11 January 2021

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

11 January 2021

   [2]Agenda. [3]IRC log.

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

Attendees

   Present
          Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura,
          Tomoaki_Mizushima, Zoltan_Kis

   Regrets
          -

   Chair
          Daniel Peintner

   Scribe
          zkis

Contents

    1. [4]last minutes
    2. [5]issue#285
    3. [6]issue#284 and #278
    4. [7]Architecture Terminology, see https://github.com/w3c/
       wot-architecture/issues/574
    5. [8]validating Thing fragment
    6. [9]discovery-related updates
    7. [10]versioning

Meeting minutes

  last minutes

   <kaz> [11]Dec-14

     [11] https://www.w3.org/2020/12/14-wot-script-minutes.html

   Minutes approved.

  issue#285

   <dape> [12]https://github.com/w3c/wot-scripting-api/issues/285

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

   Daniel: addressed most points, we could close it

   Zoltan: yes, we can close it

   Daniel: any open topic remained?

   Cristiano: we can close it

  issue#284 and #278

   <dape> [13]https://github.com/w3c/wot-scripting-api/issues/284
   and [14]https://github.com/w3c/wot-scripting-api/issues/278

     [13] https://github.com/w3c/wot-scripting-api/issues/284
     [14] https://github.com/w3c/wot-scripting-api/issues/278

   Daniel: mostly about the links updated for the publication

  Architecture Terminology, see [15]https://github.com/w3c/
  wot-architecture/issues/574

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

   Daniel: M.Lagally brought it up about the Thing fragments.

   Cristiano: we should define what is the minimum content of
   Thing fragment
   … Thing Model vs Thing fragment is a bit open and confusing, we
   should clarify

   Zoltan: we need a private concept in Scripting, meaning a
   simple dictionary for initialization
   … and if we can align, we can define a term in Architecture
   … if there is a minimum required content, we should spec it

   Daniel: the minimal content is the empty object
   … it is not clear what is the difference in Thing Model vs
   Thing fragment
   … a Model is like a typical description, a fragment is more
   like a JSON
   … instance

   Zoltan: implementations can override the provided dictionary

   Daniel: they should be able to do that even with models

   Zoltan: still think we should have separate definitions for
   Scripting and Architecture

   Cristiano: but it's not just a normal dictionary, since it has
   to conform certain requirements
   … like syntactic issues

   Zoltan: so you'd like a formal definition and also a validation
   algorithm

   Daniel: the problem is the JSON schema instance for validating
   would fail if you'd provide just a property name without and
   href
   … so it is difficult to come up with this
   … and it has to be the same for every implementation, so it
   should not be private

   Cristiano: we also need to consider the directory use case as
   well
   … like searching for Things similar to the ones passed

   Zoltan: so a Thing should pass as a model

   Cristiano: probably yes
   … but mainly a separate entity, copy some stuff and then throw
   it away

   Daniel: for a JSON schema validation, we should pick what we
   have now and mark the rest as optional

   Cristiano: then it's just a fragment, if things are optional

   Daniel: the "required" stances could be made optional, then it
   becomes usable for model/fragment

   Zoltan: we should use "arbitrary fragment", rather than model

   Cristiano: I agree here
   … every model should have id, title, ... at least

   Daniel: I hear the Thing Model is more restrictive, but IMO
   it's generic
   … need to look into this

   Zoltan: we could go by examples, then definitions

   Daniel: we can have a simple definition: take JSON schema and
   prune all "required" stances

   Zoltan: this is a necessary step, maybe also sufficient

   Cristiano: agree

   Daniel: we need to attend the Architecture call with this
   agreement

   Cristiano: I can do that

  validating Thing fragment

   Daniel: we need to spec this, based on today's discussion as
   well

   Zoltan: should that be in the TD spec?
   … if there are any constraints, we should have an algorithm in
   the Scripting spec

   Cristiano: I agree with Daniel's proposal for validation

   Daniel: so in node-wot, if there is a "required" stance, we
   just ignore that it is required, i.e. the href can be there,
   but it can be overridden

   Zoltan: why not creating an explicit JSON schema then for
   fragments?

   Cristiano: I agree

   Daniel: we do it on the fly currently
   … not sure if there are more restrictions on the Thing model?

   Daniel: we should wait on what others will say from the other
   task forces
   … we leave the issue open
   … in the best case we can assume model == fragment, but let's
   see

   Cristiano: we should track it in an issue

   Daniel: will do that after the call

  discovery-related updates

   Daniel: need to wait on the Discovery TF

  versioning

   Daniel: in the issue we say it's good practice to not break

   Zoltan: but we need to track API changes somehow

   Cristiano: an impl should be able to tell during runtime which
   semantic is used
   … what if I want a script to work both with old and new ABI
   … a version number would allow that

   Zoltan: looks like we move more towards a REST API style

   Zoltan: the question is what do we need to spec so that every
   impl respects it
   … is it enough if we track version on node-wot level, or I want
   all impls behave the same way?

   Cristiano: looks like we need at spec level, across all
   implementations, need to check

   Zoltan: it's easier to have a version in the spec, than not
   having it, but what text we put in the spec

   Daniel: it's not straightforward in the implementations, though
   - it must be updated, otherwise useless
   … so I like more that the implementations are clear about
   versions

   Zoltan: so we can stay with the current status-quo

   Daniel: yes, but CA might have use cases for a spec version

   Zoltan: I am not sure if other web APIs have versions any more

   [adjourned]


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

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

Received on Tuesday, 19 January 2021 09:37:18 UTC