- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 30 Sep 2020 00:49:38 +0900
- 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