scribenick: kaz
<kaz> July-23
<inserted> scribenick: kaz
Lagally: approved
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)
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)
Lagally: (adds a comment to issue 8)
Lagally: (also creates a new issue)
Lagally: we should define protocol
constraints which are common across different protocols
... (going back to 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)
[[
EDITOR'S NOTE
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]
<scribe> scribenick: cris
<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
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
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
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
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
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
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)
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
[adjourned]