02 Dec 2020



Kaz_Ashimura, Daniel_Peintner, Michael_McCool, Taki_Kamiya, Sebastian_Kaebisch, Ege_Korkan, Tomoaki_Mizushima
kaz, Ege


<kaz> scribenick: kaz

Plans for the next calls

Sebastian: we'll have a call on 9th and 16th
... then may skip 23rd

Daniel: Scripting do the same

Sebastian: Dec 30 and Jan 6 will be cancelled

Prev minutes


Sebastian: (goes through the minutes)
... any objections to approve them?




Sebastian: (goes through the minutes)
... any objections to approve them?


Defer issues to TD 2.0

possible issues to be deferred to 2.0

Sebastian: those are the issues can't be solved for 1.1
... would break the compatibility with 1.0
... for example, issue 803 should be deferred

Issue 803

Sebastian: if you think some of them should be addressed for 1.1, please let me know
... will continue to review the remaining issue and identify which to be deferred to 2.0

Issue 1011 and PR 1013

PR 1013

Issue 1011

Sebastian: "5.4" appears twice within the title of section 5.4

PR 1013

Sebastian: PR 1013 fixes the Issue 1011

Daniel: there was a section number of "5.4" directly put there, so removed it

Sebastian: any objections?



(Issue 1011 also closed)

Issue 1003 and PR 1012

Issue 1003

PR 1012 which fixes Issue 1003

Sebastian: merged 1012
... and closed Issue 1003

Issue 950 and PR 995

Issue 950

PR 995 which fixed Issue 950

Sebastian: (goes through the PR)
... (also quickly skim the preview)
... merges PR 995
... and closed Issue 950

Remaining issues

Issue 890 - Consider adding keyword to describe synchronous actions

Issue 890

Sebastian: (goes through the issue)

McCool: need to handle error response

Ege: got a comment from Ben Francis too

Ben's comments

Kaz: would agree Ben and think adding synchronization capability to TD would be too much
... maybe we could reuse the existing synchronizing mechanism

Ege: this use case itself is just discussing synchronous invocation vs asynchronous

Kaz: if we use asynchronous mechanism, we need to manage the time synchronization of each data communication

<McCool> (note that "synchronous" just means that response happens only after action is complete, and can include success/failure in that response)

Kaz: I do understand the point "here" is not time synchronization
... however, if we provide asynchronous invoking of a Thing, we should provide additional time synchronization capability to mashup multiple Things in the end

McCool: it's important to think about the ordering of actions

Kaz: yeah, at least we should provide some mechanism to manage the order of expected invocations

Sebastian: in that case, can you create another issue on that viewpoint, Kaz?

Kaz: will do

<scribe> ACTION: kaz to create another issue on management of the order of events/invocations (possibly time synchronization in the end)

Sebastian: your assumption is many IoT use cases would require asynchronous communication?

Ege: right

Sebastian: I asked about that because we need to see which communication pattern is really needed
... maybe we should ask Michael Lagally about Oracle Cloud as well

McCool: we should make asynchronous default

Kaz: but it depends on the protocols' capability
... UDP-based protocols would allow it
... but how to handle it with HTTP-based protocols?

Ege: would cause a timeout

McCool: we need to come back to how to handle the errors

Sebastian: seems it would be useful to have the capability of "asynchronous" itself
... but how to deal with it?
... Ege, can you work on a PR?
... maybe together with Lagally?

Ege: ok

<scribe> scribenick: Ege

Issue 1010 - https://github.com/w3c/wot-thing-description/issues/1010

Sebastian: Do you want to add exclusiveMaximum as well

Ege: not really, but they just exist in JSON Schema

Sebastian: They exist in XML Schema as well? but are not heavily used

McCool: Also mathematically, these terms are inclusive
... Not sure about how much exclusiveMin/Max are used
... We should update our definitions to be aligned with JSON Schema

Daniel: I think that the overhead from our side to add exclusive min max is not high

Sebastian: Not sure if there is enough interest in this

Daniel: But what happens when the models exist elsewhere?


at the end of this

McCool: I am for including this term

Sebastian: any objections to include it?

(no objections)

Ege: The older versions have boolean for exlusive min max

McCool: How do we handle versions of JSON Schema
... what if they include breaking changes

Ege: There is a breaking change regarding items

McCool: Could you create an issue?

Ege: yes creating now

Sebastian: So we should clarify this in the 1.1

Issue 1007 - https://github.com/w3c/wot-thing-description/issues/1007

<kaz> NumberSchema

<inserted> scribenick: kaz

McCool: we've been discussing canonicalization during the discovery calls
... wondering about if the framing discussion would be useful to this issue

Sebastian: what would be the concrete proposal here?

Ege: remove the word "Only" here

Sebastian: ok

Kaz: removing "Only" from all of "minimum", "maximum" and "multipleOf" here?

Ege: yes, all of them related to IntegerSchema

Kaz: but that means they would be applicable to the other types as well
... is that OK?
... also removing "Only" from all the definitions at, and

Ege: yes

Kaz: however, would it be really the right thing for us to remove "only" here for the Thing Description as a specification?

McCool: the generator should be strict and the parser should allow it
... technically, we should use different terms to avoid the problem with the parser

Kaz: yeah
... given the time, let's talk about this next week again

Sebastian: would like to see the backward compatibility too


Summary of Action Items

[NEW] ACTION: kaz to create another issue on management of the order of events/invocations (possibly time synchronization in the end)

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/12/16 08:19:16 $