Meeting minutes
Minutes Approval
<kaz> Sep-28
Ege: (adds a comment to the ScribeRoll page in the Wiki stating that people who haven't attended for a long time are "spared" from taking minutes the first time)
… (goes over the minutes from the previous meeting, which was two weeks ago)
<Ege> https://
Ege: under "Update Policy" there are square brackets around a citation, is that normal?
Kaz: That is normal as it is a quote
Ege: Any objections to publishing the minutes?
There are none, minutes are approved.
Binding Template PRs
PR #179
<kaz> PR 179 - Explain topicname and filter
Ege: About MQTT topic names and filters
… there was a comment by Cristiano
… TopicName is now used for subscriptions while TopicFilter is used for publishing since here, wildcards can be used
Cristiano: We can merge
PR is merged
PR #190
<kaz> PR 190 - Align protocol binding abstracts
Ege: This PR aligns the abstracts of Binding Template documents
… the PR takes the abstracts by Cristiano as a reference point
Kaz: I personally think it would be easier to manage the content if we took all of these protocol-specific documents into the main document. This would make separate abstracts obsolete
Ege: The current state is what we agreed on, since it should be easier to manage if we do it like this. But we can continue the discussion after this PR.
Ege: Jan left some comments, which I will incorporate. Two refer to the MQTT, which is not actually an abbreviation anymore.
Ege: In general, the template now includes a basic abstract structure which I adapted for the CoAP Binding Template.
Cristiano: I like the structure, I think we should go ahead
Ege: I also removed links from the abstracts since the abstract might appear in places like Google Scholar
Sebastian: It could make sense to include a reference to the main Binding Template document
Cristiano: We could have an additional link to the main document in the top/RefSpec section
McCool: Adding links to the abstract is not a good idea
Ege: Cristiano was referring to the ReSpec section
Kaz's question about the structure of the Binding Templates documents
Ege: Now we can come back to Kaz's point. I think I would disagree, since it is more comfortable for the reader since they can simply go the document that is of interest to them. Also, it is also easier to manage for us since individual Binding Templates can have their own specific Editor's who maintain it.
Kaz: Users do not really understand the current mechanism for using a Binding Template. We should better explain the mechanism in general and with regard to specific protocols like MQTT.
<Mizushima> +1 kaz
Ege: The actual protocol binding happens in the forms member of an interaction affordance. Maybe we should have a better guideline here.
Kaz: We could use Hyperlinks or include other documents via the merge approach that is also used in the HTML document
Ege: Separate documents would make it easier to follow changes and is easier to maintain in my opinion
Kaz: Version management can be done via GitHub and ReSpec
Ege: I am thinking more about the reader
Sebastian: I agree with Ege here
… we had everything in one document before and it was a confusing mess
… now we have self-contained documents
… keep also in mind that we will have additional protocols in the future, which would make the single-document approach even more overwhelming
Kaz: However, in the end, we would like to define protocol-specific vocabulary using those documents, and I thought we wanted to have a machine-readable data for that purpose as well.
… currently, there is a lot of redundancy as each document has its own header, abstract, status, etc., and probably it would be better to have the actual content as a section within the main Binding Templates document, and refer to machine-readable vocabulary outside, e.g., as an ontology.
Sebastian: Ontologies are additional documents
… We should only refer to existing definitions of terms
Ege: I will open an issue for recording additional opinions
Cristiano: I am also in favor of keeping separate documents
… the problem of repetition is dealt with by your PR, Ege
… furthermore, the protocols require specific introductions
McCool: I think we should move on and keep it as is if we don't have a good reason to revert it. Both approaches have pros and cons. As long as we have a single master document we can refer to, I am fine with the current solution
Kaz: I thought we wanted to use the Registry Track to define protocol-specific terms. However, it might make more sense to refer to protocol-specif terms defined by an ontology or registry from one consolidated Binding Templates document, which describes the mechanism of WoT binding clearly. I got a comment from PLH suggesting we look into the other group's approach on protocol-specific terms, e.g., Distributed Tracing WG's work on MQTT: https://
Issue #176 and PR #183
<kaz> Issue 176 - [Modbus] URI design for modbus+tcp URI schemes
<kaz> PR 183 - feat(modbus): move addres and quantity to URL components
Ege: This PR deals with the Modbus URI design
… the question here is how the href should be used. Matthias commented that if a protocol does not define a URI scheme we can define one ourselves
Cristiano: The URI now includes parameters such as quantity and unitID
Ege: I had some discussions with people at Siemens that said it makes sense in general (since it corresponds with the REST design) and that it also makes it easier for humans to read
Cristiano: This new design also makes it easier to use a base URL
… however, we are sacrificing some readability in this case
Ege: This also corresponds with MQTT where we could use a similar approach
Sebastian: I understand the motivation and I also support this approach also in contrast to the one we had before
… if we only use a URI-based approach, however, we would give up some readability
… we also run into problems with WebSockets
… we should be able to specify parameters both in the href and the TD
Daniel: I agree with Sebastian, having everything in the href makes things more consistent. However, we should focus on one approach
… href might be complicated for more complex parameters, but in general I would favor it over the TD approach
Cristiano: Currently we have a mixed approach, where we are not consistent between different protocols
… in general, I think we should be consistent with the HTTP approach
… this also brings us back to the problem we had with MQTT and the question of how to express topic names, for example
PR #188
<kaz> PR 188 - Define CoAP Content Negotiation
Ege: This is a PR opened by Klaus regarding CoAP Content Negotiation
Klaus: I am afraid 4 minutes are not enough to discuss it. I would really like to make progress here, since it is an open issue for several months now. Maybe we could have a separate meeting to discuss this.
Ege: I will organize a separate meeting so that we can discuss this in more detail
… I would postpone the rest of the topics to the next meeting
Updates to the TD editors list
Sebastian: The editors for TD version 1.1 have changed due to changes in company affiliation etc.
… we should update the list and add a new list for former editors
… I would also propose Ege as a new editor since he was very active and made a lot of contributors
<dape_> +1
<cris_> +1
Sebastian: we already discussed this in the chairs call and Michael McCool also agreed we this
+1
Sebastian: Should we make a resolution for this, Kaz?
Kaz: Yes, please go ahead.
… you could clarify the policy regarding Editors and former Editors in this regard
Sebastian: I would move Michael, Takuki, and Victor to the former editors list
McCool: Do we have a certain order?
Sebastian: I would propose me first, then Michael McCool, then Ege
Kaz: We should clarify the policy and then include the list of contributors
<sebastian> proposal: add Ege to the editor list. Move former editors to the former editor sections.
Sebastian: do you mean we should add cristiano
Kaz: do we want to add only Ege this time or think about other candidates as well?
McCool: we are looking at the contributions
Kaz: I don't object to adding Ege, but we should clarify our policy on how to manage the Editors, Authors and Contributors.
Sebastian: we should be fair with this. Ege seems to be over the "bar"
Cristiano: we should set up a policy. It is difficult to set such a bar
RESOLUTION: add Ege to the editor list. Move former editors to the former editor sections. We will discuss if we introduce a contributor list. list.
McCool: let's add ege and get that out of the way for now
Ege: respec has both options, author is needed for some SDOs
Kaz: the current solution is fine but we should continue discussion about policy
TD Issue 1722
Lagally: so there are two issues here
Lagally: first, we should not link to an informative note
… two, we should refer to binding only once, currently we have it in the informative references as well
Sebastian: i was mistaken to say that we had the same in 1.0, we extended here
Sebastian: you can look into td 1.0 to see how it is there
Lagally: we are referring to a definition in the architecture, which is an informative section
<kaz> WoT Thing Description REC - 8.3 Protocol Bindings
<kaz> WoT Thing Description 1.1 WD - 8.3 Protocol Bindings
Cristiano: actually, this resulted from a long discussion. So it is like reverting a bug fix
Lagally: I actually do not understand what is meant with this assertion
<sebastian> PR 1720 - update 8.3 Protocol Bindings section
Sebastian: This is explained in the Arch specification. Also, it is explained in the binding templates
Sebastian: what would be the way forward?
Lagally: to change the text so that is understandable
Sebastian: There is a PR linked in IRC
Lagally: this is looking good
Lagally: we should make sure that there is no reference to the binding templates document in a normative assertion. I was told it is only used in examples, but there are other occurrences. We have to do a thorough check of the entire document
Kaz: to be strict, we should review the references to the binding templates, and also clarify the relationship among related specs, e.g., TD vs Binding. Probably it's too late to add drastic changes from now, but we should think about how to improve the situation for the next Charter.
<McCool_> (sorry, I need to drop...)
Lagally: we should have a stable reference to the binding in the CR version
Ege: also we seem to have discovery as informative
<mlagally___> I have to leave
PR 1683
PR 1683 - Change to tm optional in validation
Sebastian: we have a PR to change td schema
Ege: we can close it, there is one that superseeds it
PR 1698
PR 1698 - style: align formatting for examples
Daniel: it became too verbose. I have another PR that does something a bit less that seems to be accepted
PR 1700
<kaz> PR 1700 - fix: syntax highlighting of example 4, 51, 52, 60, 61, 65, 66, and 71
Sebastian: so you have added a class attribute for json examples, nice
Sebastian: we can merge it
PR 1710
PR 1710 - Consistent code/example formatting w.r.t. ":"
Sebastian: there is a conflict?
Daniel: I will solve it
PR 1712
<kaz> PR 1712 - Add table numbers and captions using new respec
Ege: talked with ReSpec guys but still need more time
Sebastian: can wait until the next Charter period
PR 1715
PR 1715 - Add model and prohibit instance in tm schema
Ege: only changes to the json files, nothing for index.html
<kaz> (merged)
PR 1717
<kaz> PR 1717 - CoAP Content-Format number
Sebastian: for TMs, we have 433 coap content format now
… td is 432
<kaz> (merged)
PR 1718
PR 1718 - Update editors list and acknowledgements
Sebastian: let's discuss this next week
PR 1720
<kaz> PR 1720 - update 8.3 Protocol Bindings section
Sebastian: this fixes michael lagally's point on the issue 1718
Sebastian: adjourned