Meeting minutes
Minutes
<kaz> Mar-8
Sebastian: would ask you all to think about joining the TF leader
… we need at least two leaders
Ege: check consensus for the past minutes
… minutes approved.
Task Force leader clarification
<kaz> I'd like to provide some clarification on the procedure first. TF leader is not part of the Charter discussion. Also TF leader is not appointed by the WG Chair./
Kaz: I'd like to provide some clarification on the procedure first. TF leader is not part of the Charter discussion. Also TF leader is not appointed by the WG Chair.
… Choosing TF leader(s) is to be discussed by the TF itself like we chose Cristiano as an additional TF leader for Scripting API. We can simply report back to the main group later. If needed, we can have 3 moderators, Ege, Sebastian, Koster
<dape> s/Ege, Sebastian, Koster
sebastian: The moderator requirements are to prepare the meeting and moderate them
Cristiano: Wouldn't be better to to nominate separate responsible for sections of the TD?
… e.g. 2 responsibles for the binding templates, 1 for profile, ...
Luca: We could have a list of topic first and then find moderators
… and possibly have rotation on moderation if the workload is large enough to warrant it
Kaz: we could discuss further when Koster is present
… note that from my viewpoint, it would not be fair to have two moderators from one specific company.
Charter-related topics
<kaz> Remaining issues
Ege: We do not have much left to say to discuss since most discussed already
… remaning items to discuss
PR 88
<Ege> PR 88 - Revised scope section, reordered, clarified language
Kaz: clarification on what's about the PR
Ege: The change is just 1 line in the Charter document
PR 78
<Ege> PR 78 - Define Streaming and RTSP work items in Details
<cris_> +1
Ege: The PR is about multimedia streaming, interested parties should comment on the PR
Issue 59
<kaz> Issue 59 - Add composed Things work items
Cristiano: What do we want to do, what are we missing?
one case we want to act upon the aggregate
… ... one case we want to just signal the relationship
<kaz> ek: (shows Example 30 from the TD spec Editor's Draft)
<kaz> Example 30 from TD
Luca: I'd like more clarification on this topic
Ege: We should see we have consensus on explore more on the next charter
Kaz: As already mentioned during the Charter call, this is not Charter issue but detailed work item for the next version of TD, so we should move this issue to the wot-thing-description repository
Cristiano: +1
<dape> DP: allowing "group" interactions based on composed things sounds too much to me. Suppose an electric vehicle has several motors and a stop() interactions which then would need to be forwarded to "linked" motors. I don't think the TD should do that. A tool might do that though
TD Testing
At-risk features
Ege: many at-risk items in the TD are security assertions
… we should have the discussion in the next security call
<Ege> https://
<kaz> items above
Ege: Also we should fill out the document with our at risk items above
<kaz> i/may at/subtopic: At-risk features/
Ege: The deadline is 27th March
… implementors are invited to participate
… we will review the document next week
Binding Templates
Issue 255
<Ege> w3c/
Ege: The patch has the diagram
… it explains the specific items of the Form
… and how the requests flow looks like
<cris_> +1 sebastian's comment
sebastian: looking forward to see the diagram
Luca: png vs svg as medium in the document
<kaz> related PR 262 - Explain core binding mechanism
<Zakim> dape, you wanted to quotes in TD snippet
<Ege> diagram preview
Ege: Shall we put the quotes in the snippet?
Cristiano: It is not a valid json to begin with, not strong preference
sebastian: Would be nice to have more diagrams like this one
Ege: We can make a requirement to add sequence diagrams in the protocol bindings
… we have some in the HTTP protocol binding
… we can make sure to get the detail level not too deep
Kaz: The TD snippet should be valid, we should add the quotes as needed
… the diagram should have a paragraph describing the use case scenario related to that
sebastian: I would leave it as-is
Kaz: I prefer the snippet being valid even if it is a fragment
Luca: +1
<kaz> ek: ok. will fix it
Issue 252
<kaz> Issue 252 - Mention that a binding is mandatory for a TD to exist
<Ege> related PR 261 - Update ReSpec in ontology template
Ege: Fix ReSpec warnings
Ege: Ok to merge?
… merged
(no objections)
merged
PR 260
<Ege> PR 260 - Use dct:creator instead of dct:author in ontologies
Ege: any objections to merge?
(none)
merged
PR 263
<Ege> PR 263 - Specifying terms influenced by different bindings
Ege: (shows the preview)
… (describes the text and table under Example 5)
Ege: this is still a draft, and would like to hear people's opinions
Luca: how are we going to specify which is correct href value?
Ege: if you see Modbus...
bf: that seems to be risky...
… how to validate it?
… it could be a starting point, but we need further improvement
… we have to figure out what socket to be used in this context
Ege: ideally the Consumer should pick one for their implementation
… if the choice was wrong, the configuration would be gone
Luca: would be better to specify the expectation
Ege: do you think asking the implementers to follow the ABNF notation is too much?
Luca: it would be risky
… asking this in the Ontology would make sense
Cristiano: agree
… don't see any Consumer implementations yet
… would be easier to follow the URL
… the other point around registry
Daniel: maybe you can show the table again...
… paragraph above the table says "keywords" and "terms"
… also "Assignment" within the table seems to be odd
Ege: copied from the TD spec...
Daniel: not sure about what term would be better, though
Kaz: we should collect developer experience for binding with Modbus, etc.
… maybe a good topic for the possible Dev Meetup on Binding
Ege: ok
… would like to create an issue to remember this
issue 264 - Get binding usage information from communities
Ege's comments on PR 263 based on the discussion
Ege: (then goes through section 4.3)
preview - 4.3 Platform Binding Templates
Kaz: just to make sure, is there any clarification about the difference between "Protocol Binding" and "Platform Binding"?
Ege: yes, some text within the Introduction section
Kaz: ok
… remember we agreed on that text the other day
… but maybe it would be better to have that clarification text withing section 4 "Binding Template Mechanisms" itself?
Ege: right. can understand your point
… (creates another issue about that; to be done later)
PR 259
<Ege> PR 259 - Rename CoAP blockwise parameters
Jan: some discussion about the position
related issue 256 - Rename cov:block2SZX to cov:block2Size
Jan: we could make this PR itself, and then I can add further improvement
(this is updates for coap/coap.schema.json and coap/index.html)
merged
Jan: will work on related PR 246
Kaz: we won't talk about PR 246 itself today. right?
Ege: right
Issue 232 - Next WD Path
Ege: our deadline is Mar 30
… would like to have more opinions around naming
Issue 243
Issue 243 - Changing the Payload Bindings to Content Type Bindings
McCool: "Payload Bindings" would be clearer, I think
… "Payload" is more specific term than "Content Type"
Cristiano: could you elaborate the background a bit more, Ege?
Sebastian: would agree with McCool
… "Content Type" sounds more generic to me
… "Payload" is to be exchanged for interaction
Ege: ok
… we should see what different platforms do
Sebastian: we should clarify what is expected here
Ege: should go for platform discussion
… if the data schema with HUE or OCF goes in platforms, this change would make sense
Sebastian: right
Luca: should be able to look up the binding
… we have to make sure our expectation
Ege: Consumers would need to pick
Kaz: would agree with Luca's viewpoint
… we should clarify our expectation for binding first at the top of section 4
… protocol part and content part to be handle how
… then we should be able to choose which term would be the best, content or payload (or something else)
Luca: how to look up the content type and validate it?
Cristiano: wanted to comment on the issue
… more aligned with what we started with
… we're now talking about how to serialize the information
… actual contentType content
Ege: would prefer making decision prior to the next publication
… McCool, do you still prefer "Payload Binding"?
McCool: if you all think "Content Type Binding", that's OK
Kaz: is what we want really binding of "ContenType"?
… it implies "MIME Type" to people
… so if what we want is rather binding of the content as a whole, maybe it would be better to say "Content Binding" as Daniel mentioned
McCool: right
Luca: do we have examples on this kind of Binding (ContentType Binding/Payload Binding)?
Ege: yeah
… (shows the examples at Appendix B)
Appendix B. Examples of Payloads and Data Schemas from IoT Platforms and Standards
Ege: this is an example of SenML Payload
<sebastian> I have to go
<sebastian> bye
Luca: what if a payload using CBOR is transferred?
Ege: (shows example 6)
Example 6 - JSON and CBOR media types in forms
Luca: what is the data schema for that?
Kaz: sorry but we're out of time
… so would suggest we continue the discussion next week
<Ege> w3c/
Ege: ok
… note that there is a related issue 226 on "Platform Binding" as well
[adjourned]