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

[wot-architecture] minutes - 17 September 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 30 Sep 2020 00:49:38 +0900
Message-ID: <87o8lofur1.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/09/17-wot-arch-minutes.html

also as text below.

Thanks a lot for taking the minutes, Michael McCool!

Kazuyuki

---
   [1]W3C

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

                            WoT Architecture

17 Sep 2020

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda

Attendees

   Present
          Kaz_Ashimura, Michael_Lagally, Michael_McCool,
          Sebastian_Kaebisch, Ryuichi_Matsukura,
          Tomoaki_Mizushima, Zoltan_Kis

   Regrets

   Chair
          Lagally

   Scribe
          McCool

Contents

     * [3]Topics
         1. [4]Minutes review sept 10
         2. [5]Export/legal restrictions
         3. [6]Legal compliance
         4. [7]Link relation types
         5. [8]Contributions and new requirements
         6. [9]Profiles
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

   <scribe> scribenick: McCool

Minutes review sept 10

   <kaz> [12]Sep-10

     [12] https://www.w3.org/2020/09/10-wot-arch-minutes.html

   presentation by Matsukura-san on ITU-T home use case

   need for discovery section; McCool mention tool now used for
   sequence diagrams in Discovery doc

   and need to improve language in that section

   discussed CHIP, agriculture-greenhouse use case

   discussion of components

   Lagally: shall we approve?

   all: no objections

   Lagally: minutes are approved

Export/legal restrictions

   Sebastian: new regulations that has impact on standards work

   forbidden to get involved in projects with non-public
   technology discussion that has use in US

   McCool: for example, we have non-public (Member-only) mailing
   lists

   so can't have technical discussions on those non-public mailing
   lists, but github is ok

   proposal: not use non-public mailing lists for technical
   discussions or meeting minutes, draft minutes included

   RESOLUTION: do not use non-public mailing lists for technical
   discussions or meeting minutes, draft minutes included

Legal compliance

   in general, for people complying with the law... it's obvious
   and implied, do we have to say anything?

   eg compliance with auditing, privacy, safety, etc. requirements

   my preference is to declare it out of scope

   we could declare it out of scope, or add a disclaimer under
   conformance

   something like "We do not specifically address any legal
   requirements that may apply to your application or location."

   I think we should check with W3M if this is a reasonable thing
   to do.

Link relation types

   McCool/Lagally: let's brainstorm, link them to use cases later

   Lagally: describe a topology; relationships between entities

   McCool: suggest we list relations we want first, later on look
   for names or a spec we can adopt
   ... and even if we adopt an existing set of definitions, we
   should identify particular ones that should be used for
   specific purposes in WoT

   Lagally: right, we have to be a bit more selective
   ... and there are some overlaps

   McCool: and in a profile we also need to limit link relation
   types to a finite, static subset

   <mlagally__>
   [13]https://www.iana.org/assignments/link-relations/link-relati
   ons.xhtml

     [13] https://www.iana.org/assignments/link-relations/link-relations.xhtml

   Sebastian: there is also a possibility of when to use a link
   relation type and when to use a semantic relation

   Lagally: when you think about how you model things in UML:
   inheritance, implementation, aggregation

   McCool: let's also list the entities we care about
   ... thing model, thing description, directory
   ... what we want to know is where a TD was sourced from, so
   that (for example) a consumer can subscribe to update it
   ... also need to deal with bidirectional links
   ... "implements" may also have inclusive and exclusive variants
   ... eg can a TD implement more than one TM (for sub-APIs)
   ... need to clarify when to use links and when to use semantic
   relations; suggest to use "dereferenceable"

   Lagally: aggregation

   McCool: is aggregation "member of a set"

   Lagally: same or different types?

   McCool: "like" is a fuzzy concept

   Sebastian: do we need explicit entity types or will
   contentTypes cover that?

   McCool: I was thinking of entity types more as a way to
   structure the requirements discussion

   Lagally: note that inheritance etc. raises various naming
   issues

   McCool: another general category of link types is "metadata"
   ... manufacturer, author, documentation, etc.

   Lagally: let's review iana spec...

   <mlagally__> [14]https://www.iana.org/go/rfc8288 Link
   relations:
   [15]https://www.iana.org/assignments/link-relations/link-relati
   ons.xhtml

     [14] https://www.iana.org/go/rfc8288
     [15] https://www.iana.org/assignments/link-relations/link-relations.xhtml

   Lagally: (group looks at iana spec, update docs)

   <mlagally__>
   [16]https://github.com/w3c/wot-architecture/edit/master/REQUIRE
   MENTS/link-relation-types.md

     [16] https://github.com/w3c/wot-architecture/edit/master/REQUIREMENTS/link-relation-types.md

Contributions and new requirements

   Zoltan: made a PR

   <mlagally__>
   [17]https://github.com/w3c/wot-architecture/pull/539

     [17] https://github.com/w3c/wot-architecture/pull/539

   Zoltan: reviews diff
   ... added introduction, background of work, state names
   ... didn't want to make this section too long
   ... this section however is mostly interested in state names,
   data that is involved
   ... separate section for data (information lifecycle)
   ... also system, thing lifecycles
   ... need to explain why we have three, what the use cases are
   ... eg. using devices that are already provisioned,
   provisioning new devices directly to work with WoT, etc.
   ... "provisioning service" may or may not be a concrete
   service, is handled in different ways
   ... similar to T2TRG model, but we need to add some more
   detail, "opening up" some of the T2TRG states
   ... eg. we add more detail to "bootstrapping"
   ... there are also examples mapping terminology to other specs
   that call these states by different names
   ... e.g. bootstrapping/onboarding/initial provisioning
   ... is this normative or informative?
   ... can make the names normative, but hard to make transitions
   normative
   ... different in different systems

   Lagally: can't really mandate that certain transitions are
   supported by different devices

   Zoltan: feedback that came up what that other people have
   worked already on this
   ... so why should we be different?

   Lagally: some states are not defined in other systems, eg.
   maintenance

   Zoltan: some always appear, some are optional

   Lagally: can we use end-of-life?

   Zoltan/McCool: have to ensure that definitions are equivalent
   though

   McCool: I also want to note that you can always destroy
   something, the question is whether you can do it through the
   protocol

   Lagally: example of cash card that used flash so you could only
   burn cells to decrease the value; once discharged, cannot be
   recharged; eol
   ... suggest that we keep it as a PR and everyone does a review

   Zoltan: would like to create pictures, need to use the same
   terms

   McCool: (I really wish we could use SVG rather than
   software-specific files like ppt or drawio but whatever)

   Lagally: let's use SVG as the master; drawio can read and write
   SVG, so...
   ... need to not have both svg and drawio in github, confusing
   which is the master, so will remove .drawio file

   Zoltan: is there a style guide?

   (Sebastian leaves)

   McCool: for the record I do like the simpler style that Michael
   brought; lots of detail in each state gets pretty confusing,
   and it's harder to edit; we can put that detail in the text

   Zoltan: suggest we take the current diagram and take out the
   detail and create a simpler version
   ... what about actors, etc?

   Lagally: I would put that in text too

   Zoltan: ok, then we agree, let me go and draft something

   Lagally: everyone, then please review

Profiles

   <kaz> [18]wot-profile issues

     [18] https://github.com/w3c/wot-profile/issues

   Lagally: several issues for standardized capabilities, units
   etc

   <inserted> [19]Issue 30

     [19] https://github.com/w3c/wot-profile/issues/30

   McCool: all subsets of "limit to specific extension
   vocabularies"

   Lagally: want to discuss more specific issue of organizing PRs
   to address each issue

   McCool: suggest we add a single paragraph that just says "you
   are allowed to use these semantic extensions and ONLY these"

   Lagally: probably should go in to section 5.1.1, at the top,
   discuss vocabulary

   <kaz> [20]WoT Profile draft - 5.1.1 General

     [20] https://w3c.github.io/wot-profile/#general

   McCool: I think we should also specify the prefix, it will make
   parsing easier
   ... may also need protocol vocabulary; but we still need to
   discuss how to handle/mandate protocols
   ... but WHEN we allow use of a specific protocol, also need to
   allow those protocol's vocab

   <kaz> [21]Newly created issue 34

     [21] https://github.com/w3c/wot-profile/issues/34

   Lagally: for units...

   McCool: issue #29

   <kaz> [22]Issue 29

     [22] https://github.com/w3c/wot-profile/issues/29

   McCool: units mandatory vs. use of unit system is mandatory
   ... most of the discussion was around the latter
   ... pretty hard to make units mandatory, some things are
   unitless
   ... probably just a strong requirement

   Lagally: could make them mandatory, but provide an
   "unspecified"

   McCool: and since "cm" is easier to type than "unspecified"
   it's easier to do it right...

   <kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

    1. [23]do not use non-public mailing lists for technical
       discussions or meeting minutes, draft minutes included

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [24]scribe.perl version ([25]CVS log)
    $Date: 2020/09/29 15:47:45 $

     [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [25] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 29 September 2020 15:49:43 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 29 September 2020 15:49:45 UTC