Meeting minutes
Minutes
Ege: (goes through the minutes)
… another subtopic for PR 193 to be added between "... I will tag ..." and "Jan: had discussion"
Kaz: updated
approved
Binding Templates
PR 198
PR 198 - Overview of the binding templates documents and relationship with others
Ege: already mentioned last week
Kaz: would be better to have two diagrams separately
… one for relationship among WoT specs within one of the earlier sections
… and the internal relationship here within section 4
… maybe I should have been clear about that point last week
Ege: ok
… btw, Mizushima-san, have you had discussion with the JP developers about the structure of the Binding Templates spec?
Kaz: he's planning to have an event next year
… so no concrete response yet
Ege: ok
… (adds comments based on today's discussion)
Matthias: originally we wanted to have an independent document for "Binding Templates"
… but this document doesn't really describe the templates themselves
Ege: actual binding is described by the Thing Description
Matthias: for example, Siemens has some specific binding
Klaus: agree with Matthias
… the current document doesn't match what people have been talking about
Ege: ok
… I'll open another issue on that
Ege: we can reopen Issue 143
… actually, it's still open
Issue 143 - "Protocol Binding" vs. "Binding Template"
Klaus: our expectation is having a specific document named "Binding Templates" which describes the Binding Templates
Ege: ok
Klaus: the core Binding Templates document should describe the mechanism of the WoT Binding Templates
Ege: ok
Kaz: agree with Matthias and Klaus
… the core Binding Templates document should have clearer description on the mechanism of "Binding Templates"
… and how to generate them
… Mizushima-san's point should be also similar
<Mizushima> +1 I agree with Matthias and Klaus, too.
Daniel: good to align the terminology with WoT Architecture as well
Matthias: multiple aspects to be considered
… so we use "Binding Templates" as plural
… both the concept of the Binding Templates and protocol-specific templates to be described
Ege: ok
… think the Terminology of the WoT Architecture specification is flexible enough
WoT Architecture 1.1 - 3. Terminology
Binding Templates A re-usable collection of blueprints that enable a Thing Description to be used with a specific protocol, data payload format or an IoT platform that combine both of them in specific ways. This is done through additional descriptive vocabularies, Thing Models and examples that aim to guide the implementers of Things and Consumers alike.
Ege: the description of the Binding Templates Note should be inline with the above terminology definition
PR 188 and PR 193
PR 188 - Define CoAP Content Negotiation
PR 193 - Alternative proprosal for handling CoAP Content-Formats
Klaus: let's look at the detail here
Ege: (shows the preview for PR 193)
Klaus: contentFormat 60 is used as a hint
… the question is if we need another member to show the expectation explicitly
sk: TD brought the contentType as mandatory feature
… what is our assumption here?
… you can skip it if needed
… in that case, the default is application/json
Klaus: application/json to be 50
… should we even more explicit?
Ege: accept to be included also
Klaus: what content option to be included here?
… must we put the information explicitly?
Matthias: my argument within the issue as well
… if you need to set the accept option, additional term on what would be accept to be specified
… there two different cases
Kaz: what is really needed for binding?
Ege: the way to give hints itself might not be necessary
Kaz: it's kind of redundant to have both contentType application/cbor and contentFormat 60
Matthias: right
… should be processed outside of the object
Klaus: may need it for compatibility purposes
Matthias: ok
jr: regarding the set of options
… my understanding is around multiple forms
… if we have another form object
… you could select the form
… by providing a set of options
Matthias: you wouldn't need to use CoAP-specific term for that purpose
… can be handled by an upper-level process of the application
… by setting an acceptable option
Kaz: time check
… we're at the top of the hour
… but will we continue this discussion?
Ege: yes, 15 more minutes
jr: consumer to select the option
Matthias: 2 forms with 2 options JSON/CBOR
… we need to set Accept option
Ege: Jans proposal seems fine then
… we might need to add such a 2 form example
Klaus: +1, looks good with this new example
Jan: what about HTTP?
… accept header needed there as well?
Klaus: Yes, exactly the same thing
Jan: makes sense
Ege: in the case contentType is not describable one must put accept
… e.g, PDF under same resource ...no dataSchema possible for it
Klaus: w.r.t. HTTP protocol binding
… should we have similar example ?
Ege: Yes, agree
Jan: will update PR 193
PR#204
<kaz> PR 204 - Move Coap Ontology
Ege: decision, move ontology to archive folder
… Klaus approved PR
… merging
Kaz: if we remove this notation ... how to deal with vocabulary?
Ege: issue #97tracks this issue
Kaz: what would document describe ?
Ege: explain how to use... default mapping
Kaz: It would be easier explaining the binding in core document
Ege: I think we would loose people
Kaz: I suggest to include content in core document
Ege: issue#191 ?
… we are looking for additional arguments
… need people's opinion
Kaz: Not about single vs. multiple documents
… need to think about machine-readable and human-readable part
Sebastian: I prefer splitting the documents
… core should explain basic concepts
… details about protocol binding should be in its own document
… makes it also independent
… new protocol would require to touch core document
… DID takes similar approach.. core and link is provided
Kaz: My core point is: we need to clarify how to bind protocol
… w.r.t. DID: DID is different
… would mean binding needs to change to registry
… structure/description of binding mechanism is the problem
… the concept needs to be properly described
Ege: I think I understand
Kaz: Issue should #97 should change the title and the content
Ege: will create a new issue
Kaz: I will create a new issue
… should clarify other questions as well
TD
status of the TD wide review for CR transition
Sebastian: I am still waiting for feedback
… some horizontal issues are solved
… a problem that makes it show up "needs resolution" might be a GitHub label issue
Sebastian: Not sure if this actually an issue
… Ralph just asked for exit criteria.. which we provided
… maybe Kaz can ping Ralph and PLH
Kaz: as mentioned during the Chairs call 5 hours ago, I'd suggest you ask PLH for help. I'll try to talk to them if we don't get any response
Sebastian: Thanks
… would be just good to know if we missed anything
Missing Implementations
<kaz> draft implementation report
Sebastian: We should start implementing at risk features
… I think Ege has some good news
Ege: played with multilanguages
… since playground is in browser it works out of the box
… a single assertion is still misisng
… editdor supports the same
… McCool run tools to generate report
… we might need to wait for new implementation report
Sebastian: Anyhow, good news
… 2 assertions are fixed
Ege: I think even 3 of them..
Sebastian: PlugFest planned from 12-16
… since Kaz is not available on 16 we will stop Dec 15
Ege: I will check OAuth from sayWOT
PRs
Ege: same set as last time
… I suggest to wait till we have released CR
… to avoid confusions
Issue#1747
<kaz> Issue 1747 - Add a warning about the "other" Thing Model specification
Ege: about member submission
… googling brings up out-dated documents
… people look at it and see W3C.. looks official
… what can we do about
Sebastian: Web thing model shows older date
… Agree it is confusing to see this document on Google being a sub-document
Kaz: I suggest we ignore Google results
… member submission is just a member submission
… not part of W3C Recommendation
Ege: We can not do anything?
Sebastian: Can we ask W3C system people to lower rank certain entries
… we cannot influence Google
Kaz: we cannot avoid this kind of similar entry to be searched
Sebastian: Maybe system folks have ideas
Ege: I can try to ask
… btw, do member submission expire ?
Kaz: all documents will remain. This is W3C policy
Ege: member submission changed?
Kaz: Yes, it can be updated
… work items from 2015, before WoT started
Issue#915
<kaz> Issue 915 - Vocabulary term "scheme" not defined when used inside securityDefinitions
Sebastian: old issue about RDF
… I think we solved it
… Hence, I suggest to close it
… -> closing
Issue#998
<kaz> Issue 998 - [security] API key and PSK security schemes are not referenced or explained
Sebastian: security-based issue
… McCool mentions and proposes closing label
… -> closing
Issue#1053
<kaz> Issue 1053 - Consider adding DataSchema to response and additionalResponses
Sebastian: Ege put propose closing
… Ben added defer 2.0
… Ben asks for schema for response container
Ege: I don't remember closing it.. it doesn't make sense
… it relates to query action in Profile
Sebastian: Shall we close this issue? Or revisit it in TD2.0?
Ege: I suggest to close it
Sebastian: discussed in query action topic?
Ege: Agree
Koster: Bigger question
… what if we have data schema ... in abstract fashion
… suggest we close.. if something remains we should open other issues
[adjourned]