Meeting minutes
Scribe
<kaz> scribenick; erichb
<kaz> Kaz's slides on IRC, FYI
Minutes
<kaz> Oct-19
Ege: (goes through the minutes)
approved
Binding
PR 192
PR 192 - Aligning protocol binding template usage
Discussion on binding template description ongoing
Wording confusion regarding binding vs. binding template.
Sebastian: suggests to add a better description
Kaz: This PR 192 includes too many changes at once. It would be better to have a smaller PRs, one for the main Binding Templates document, and the others for the sub documents.
Kaz: also would suggest external WoT developers as well about their opinions if the current structure and description of the WoT Binding Templates Note is comprehensive enough. Maybe part of the discussion by the WoT CG and the WoT-JP CG.
Cristiano: Protocol Binding Templates are a way to describe protocols features in forms, they are not normative in how you use those terms. This is my understanding of the definition given by the group.
… Profiles, among other goals, wants to further specialize the rules defined in Protocol Binding Templates with stricter mapping between WoT operations and protocol keywords.
Koster: Agree with the idea that there needs to be a general binding template that includes the whole possible vocabulary, and either concrete templates that narrow this down to fixed choices or profiles that do the same. Additionally, more sophisticated clients can interpret options in the form, but we may not want to require all clients to have this capability.
(Klaus and Erich left)
Ege: any objections about the definition within this PR 192?
Sebastian: This clarifies the role of Binding Templates
… but would be better to split the PR into smaller PRs
… also as Kaz mentioned, getting feedback from the outside would be useful
… our purpose is providing a nice guideline for developers
Ege: ok
… will do so in the future PRs
… will ask Klaus as opinion as well later
merged
comment added to Issue 143 - "Protocol Binding" vs. "Binding Template"
PR 182
Ege: would remove the CoAP ontology link
… also resolve the merge conflicts
(will be merged after the above modifications)
<Ege> Issue 159 - CoAP Content-Format vs. contentType/contentCoding
<kaz> i|Issue 159|subtopic: Issue 159|
Ege: related to the TD PR 1564
wot-thing-description PR 1564 - explain contentType usage
5.3.4.2.2 Response-related Terms Usage
Ege: (skims the table on "Single contentType")
… would like to follow the approach here
Kaz: we should think about how to refer to this information from the Binding Templates side
Ege: agree
Cristiano: this PR looks fine
… but we should refer to this information from the Binding Templates
Kaz: btw, this change would not impact implementations. Right?
Ege: there is no normative assertions here
Ege: right
Kaz: from my viewpoint, this PR is very big and adds two big tables with one leading paragraph
… so probably we need a bit more detailed review to see if there is no assertion to be extracted here
Sebastian: agree with Kaz
… should not add this big change now
… to avoid potential confusions
… that said, would suggest we add this kind of clarification itself
… so let's revisit this later to add further improvement to the WoT Thing Description specification
… anyway, we should not merge this PR now
Ege: ok
Thing Description
CR Transition
Sebastian: the big news is that we made a resolution for CR transition during the main call
Resolution for CR Transition for TD
Features at-risk
Sebastian: (shows the SoTD section)
* Indicating location of security information in body of payload using JSON pointers. sec-body-name-json-pointer, sec-body-name-json-pointer-array, sec-body-name-json-pointer-creatable, and sec-body-name-json-pointer-type. * Indicating location of security information using URI template. td-security-in-query-over-uri and td-security-in-uri-variable. td-security-uri-variables-distinct. * Multilanguage content negotiation. td-ns-multilanguage-content-negotiation and td-ns-multilanguage-content-negotiation-no-multi. * TD Processor bidi isolation. td-processor-bidi-isolation. * TD Producer mixed direction scripts. td-producer-mixed-direction. * Text direction inferencing. td-text-direction-first-strong and td-text-direction-language-tag. * Support for OAuth2 client flow. td-security-oauth2-client-flow and td-security-oauth2-client-flow-no-auth. * Support for OAuth2 device flow. td-security-oauth2-device-flow. * Support for queryallactions operation. td-vocab-op--Form_queryallactions.
Sebastian: features at-risk above
… and most likely we would have another Testfest in December
PR 1730
PR 1730 - Update Implementation Report and Prep for CR
McCool: (explains the PR)
… fixed the bugs in the Implementation Report
… we still need to update the testimonials
… also be careful about the categorization by code bases
(merged)
PR 1733
PR 1733 - Overview - all TD implementations
Sebastian: need to continue to work on this
PR 1732
PR 1732 - Minor follow-up syntax alignments/fixes
Sebastian: would suggest we merge this
… but will keep this now
PR 1712
PR 1712 - Add table numbers and captions using new respec option
Ege: need to dig into the script a bit more
Sebastian: (adds a label of "by PR")
PR 1684
PR 1684 - Fix shacl, context and ontology
Cristiano: have not got much feedback yet
… why don't we revisit this next time?
Sebastian: next week?
… would talk about PR 1564 as well
PR 1564 - explain contentType usage
PRs with "Defer to TD 2.0" label
PRs with "Defer to TD 2.0" label
Sebastian: (quickly skim the list)
Issues to be closed
Issues with "Propose closing" label
Kaz: what about the issue on the dependency between TD and Binding?
Sebastian: wanted to keep it open due to your comments
Kaz: you can close the original issue and generate another editorial issue based on my comments
Sebastian: ok
Issue 1722 - Normative assertion points to informative binding template note which is WIP
Sebastian: (copies Kaz's comments within Issue 1722 to another new issue, and closes the original Issue 1722)
Issue 1735 - Minor editorial changes for PR
Sebastian: what about the other remaining Issues?
Issue 1702 - Section 8.2: Contradicting and unprecise normative behavioral assertions
Ege: design to be strict for the Consumers
… the Consumers should follow the WoT Thing Description specification
McCool: that means we're overlooking something
… a Consumer is not necessarily a Thing
… I'm fine with the current situation
(closed)
Kaz: just to make sure, Sebastian, you should check with Lagally
McCool: right
… you should mention @mlagally there so that he can reopen the issue if needed
Sebastian: (mentions @mlagally)
Issue 1674 - Mention that protocol bindings can also be defined in profiles
Kaz: maybe we can close this Issue itself, but this implies there are some descriptions on "Protocol Bindings" withing (1) WoT Architecture 1.1, (2) WoT Thing Description 1.1 and (3) WoT Binding Templates
… we should see the relationship among those descriptions to make sure
Sebastian: yes, so let's keep this open
… and revisit it again during the Architecture call tomorrow on Oct 27
Issue 1617 - [OracleReview] 6.3.4 securityDefinitions and security
Sebastian: there are no normative assertions now
(closed)
Issue 1613 - [OracleReview] 5.3.3.1 SecurityScheme
McCool: There were two assertions there
(closed)
Kaz: to make sure, who raised this issue?
Ege: Lagally raised a big issue including this
Kaz: in that case, we should ask Lagally about if it's OK to make sure, though I'm OK with closing those Issues with "[OracleReview]" title.
Sebastian: (mentions @mlagally within the Issue so that Lagally can reopen it if needed)
Next steps for CR transition
Sebastian: how to proceed with CR transition?
Kaz: as you did for TD 1.0, you need to submit an Issue for the transition repo
Kaz: make sure it would be better to provide the URL of the static HTMl version
[adjourned]