<kaz> scribenick: kaz
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
Sebastian: (goes through the
minutes)
... any objections to approve them?
(none)
(approved)
Sebastian: (goes through the
minutes)
... any objections to approve them?
(approved)
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
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
Sebastian: "5.4" appears twice within the title of section 5.4
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?
(none)
(merged)
(Issue 1011 also closed)
PR 1012 which fixes Issue 1003
Sebastian: merged 1012
... and closed Issue 1003
Sebastian: (goes through the PR)
... (also quickly skim the preview)
... merges PR 995
... and closed Issue 950
Sebastian: (goes through the issue)
McCool: need to handle error response
Ege: got a comment from Ben Francis too
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
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?
http://json-schema.org/understanding-json-schema/reference/numeric.html
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
<kaz> 5.3.2.4 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 5.3.2.4,
5.3.2.5 and 5.3.2.7?
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
[adjourned]