WoT Architecture

30 Jul 2020



Call 1: Kaz_Ashimura, Michael_Lagally, Tomoaki_Mizushima

Call 2: Kaz_Ashimura, Cristiano_Aguzzi, David_Ezell, Michael_Lagally, Michael_McCool, Sebastian_Kaebisch, Ryuichi_Matuskura, Michael_Koster, Ben_Francis, Tomoaki_Mizushima
kaz, cris


Call 1

scribenick: kaz

Prev minutes

<kaz> July-23

<inserted> scribenick: kaz

Lagally: approved


Doodle results

Lagally: the current marketing slot on Thursday would work for everybody

<mlagally_> proposal: Starting on Aug 6th the architecture call will take place at 2pm-4pm UTC. (EDT: 10am-noon)

RESOLUTION: Starting on Aug 6th the architecture call will take place at 2pm-4pm UTC. (EDT: 10am-noon)

<mlagally_> There will be no Architecture and Use Case calls between August 8th and Aug. 21st.


Lagally: Sebastian has volunteered
... how about you, Mizushima-san?

Mizushima: ok

Lagally: so will add your name to the Editor's list on https://w3c.github.io/wot-profile/

Mizushima: ok

Lagally: (adds Mizushima-san as the third Editor to https://github.com/w3c/wot-profile/blob/master/index.html)
... (also specifies "ED" as the specStatus)
... (applies same edits to wot-usecases as well)

WoT UseCases

Issue 4

wot-profile issue 4

Kaz: I'm not 100% sure what Daniel really means here
... does he suggest we make "4.2 Protocol Binding" a separate section 5?

Lagally: that's a possible solution, I think
... (goes through the related issue 8)

wot-profile issue 8

Lagally: (adds a comment to issue 8)

Lagally's new comment

Lagally: (also creates a new issue)

new issue

Lagally: we should define protocol constraints which are common across different protocols
... (going back to issue 4)

issue 4

Lagally: think now we can close this issue itself
... (issue 4 closed)
... (and adds an Editor's note to the spec draft too)

Constraints for additional protocols can be defined in a future version of this section "4.2 Protocol Biding" of the specification, or, already included in the current version.

[call 1 adjourned]

Call 2

<scribe> scribenick: cris

Minutes of the previous call

<kaz> July-23

Lagally: we discussed about WoT-profiles
... we defer also a couple of issues to next version
... we still have an open call for editors
... can we approve the minutes?
... ok approved

New architecture slot

McCool: I have conflict for the suggested schedule

<kaz> doodle results

Lagally: I am trying to accommodate every need

<mlagally_> proposal: Starting on Aug 6th the architecture call will take place at 2pm-4pm UTC. (EDT: 10am-noon)

RESOLUTION: Starting on Aug 6th the architecture call will take place at 2pm-4pm UTC. (EDT: 10am-noon)

Kaz: if McCool can resolve one of the his two conflict can we have normal call?

Lagally: is a two hour call so people can join

Kaz: just to be clear, we won't repeat the same discussion for the first hour and the second hour during the two hours, but will have agenda topics for two hours. Right?

Lagally: exactly is a two hour call with a fixed agenda

<kaz> ACTION: kaz to allocate a 2-hour call for architecture

Lagally: can you allocate the two hour call?

Kaz: yes, just added the action item for me

Lagally: we did some housekeeping of the wiki, now should be less confusing

WoT profiles

Lagally: let's look into the draft

<kaz> initial draft

Lagally: it is good to have an early initial draft to have feedback as soon as possible
... in this morning call we clean up a little bit the draft
... can you please became an editor?

Sebastian: yes, please

Lagally: anybody else want to join to the editor group?
... ok let's keep the call for editors open until the next week

Repo pull requests

Lagally: PR #20
... sebastian made some observations

<kaz> PR 20

Sebastian: the core term implies that the component should be always present
... however it is not what we should mention in the document
... we have to be careful with the "core" term

McCool: actually it means that the consumer must at least be able to consume core TDs.

(Cristiano leaves and Kaz takes over the scribe's role)

<inserted> scribenick: kaz

McCool: core does state the minimum set
... we need a kind of converse set
... maybe we need a core description for Thing for consumers
... so think the word "core" is appropriate here

Lagally: issue with naming question?
... there are several issues on the repo
... at least it's not exclusive

McCool: is that you could in TD use MQTT?
... guarantee the consumer could have interactions
... if a consumer is satisfied with a profile, that could be core
... we have some fundamental problem with "what profile is like" here

Sebastian: for me it's an issue with naming
... assumption of implementing system for a constraint device
... the core means I still need to implement that

McCool: profile is for interoperability

Lagally: there is one thing to think about separately
... the protocol chapter is still kind of weak

5.2 Protocol Binding - preview from PR 22

Lagally: we need to think about the same data model for different protocols

Kaz: would agree with McCool, and think we should clarify what we mean by "profile" and "core profile"

Lagally: should include a small set of protocols?
... HTTP could be the default one

Ben: agree
... interoperability is the main purpose
... HTTP could be the mandatory protocol
... am also wondering if "core profile" is appropriate
... more interested in constraint protocol
... if we agree we should have some profile, we can name it later

<sebatian> +1 to Ben's comment

Lagally: it's not possible create a generic consumer
... whole Internet is the target
... we have to consider constraint devices though TD is still open for various things

Ben: we should agree what the scope of the "profile"
... maybe a conflicting requirement there

Lagally: we've been discussing our requirements

requirements for profiles

Lagally: should we specify profile for HTTP
... and then MQTT with the same data model?

Ben: if we try some open-ended data model, the consumer has to support HTTP and MQTT

McCool: need to define implementation complexity too

Sebastian: agree with Ben
... we already have similar mechanism
... content type assuming JSON-LD encoding
... profile is a kind of guideline for implementation
... have to be careful about forcing the mechanism to all
... because many companies would not prefer that
... profiles should not mandatory

Lagally: profiles are not mandatory
... nobody must implement it
... if somebody wants to implement it, that's fine

Sebastian: ok
... but note that "core profile" implies all the implementers have to implement it

Lagally: people can do what they want

McCool: it's not forcing people to do that
... like the suggestion we think about the name later

Lagally: with respect to the naming
... would like to keep it healthy
... let's pick a good name later

McCool: btw, the requirement is not really strong
... we have to have a concept of interoperability
... need to go back to the requirements

Lagally: ok
... let's go back to the PR 20 itself

Lagally: would suggest we copy the comment to an issue

Sebastian: already created an issue

<McCool> McCool: need to say "out-of-the-box" interoperability
... we can't just have, for instance, data model interoperability, but not protocol interoperabilty
... the goal is that two things that satisfy the same profile should "just work" together

Lagally: so would suggest we merge PR 20 itself
... any objections?

McCool: ok

Lagally: (merged PR20)
... and another one

PR 22

PR 22

Lagally: adding a conformance section here

McCool: may need to add a script to highlight the RFC2119 keywords?

Lagally: ok
... (goes through the changes)

McCool: explanation on the RFC2119 keywords?
... boilertemplate, e.g., within the TD draft
... within the "Conformance" section

Lagally: already defined
... and duplication within Terminology section to be removed

McCool: ok

Lagally: basically saying everything is normative here
... we have to get Chapter 4 to be in a good shape
... have to agree to the content
... still a lot of homework there

McCool: yeah
... JSON Schema is normative here. right?

Lagally: should be normative

McCool: do we write assertions first or schema?

Lagally: would start with human-readable part
... suggest we add this conformance section
... any comments?

(no objections)

Lagally: (merges PR 22)
... btw, making changes to the images as well

Profiles.png WoT Profiles.png

Kaz: would be better not to include whitespace within the file name :)

Lagally: good point :)

Sebastian: should have naming discussion as well at some point

McCool: should get back to definition

Lagally: there are still 15 issues on the wot-profile repo

Sebastian: can close issue 18

Lagally: (close it)

Issue 18

McCool: might want to identify some of the issues as "retiring" and close them safely

Lagally: need to leave
... let's continue the discussion during the next call


Summary of Action Items

[NEW] ACTION: kaz to allocate a 2-hour call for architecture

Summary of Resolutions

  1. Starting on Aug 6th the architecture call will take place at 2pm-4pm UTC. (EDT: 10am-noon)
  2. Starting on Aug 6th the architecture call will take place at 2pm-4pm UTC. (EDT: 10am-noon)
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/08/02 15:01:09 $