Meeting minutes
Agenda
Ege: Only until 5:30 pm (CET) today
Minutes Review
<kaz> Nov-30
Ege: (goes over last meeting's minutes)
… we had a guest regarding the BACnet binding
… dealt with CoAP PRs, Content negotiation will be resolved today
… we had Modbus PR, not sure why we didn't merge it
… we merged a PR regarding codeowners in the binding templates repository
… in the TD call, we looked at the CR transition and missing features
… new charter items
… deal with the order of assertions
… and closed a number of old issues
… looks quite good to me, full meeting, any objections to approving the minutes?
There are none, minutes are approved
Binding Templates PRs
PR #198
<kaz> PR 198 - Overview of the binding templates documents and relationship with others
Ege: We discussed this last time, Cristiano wanted to review it, are you fine with the changes?
Cristiano: Changes look good to me
Ege: (Merges the PR)
Merged
PR #193
<kaz> PR 193 - Alternative proposal for handling CoAP Content-Formats
Ege: Last week, there was some feedback from the group to Jan
… in the meantime, there has been some discussion which has been resolved
… so we can go ahead with merging
… are there any remarks or objections to merging?
… not hearing anything, then we can merge the PR
… (merging)
Merged
Ege: With this merged, we can also take content negotiation to the HTTP binding
PR #183
<kaz> PR 183 - feat(modbus): move addres and quantity to URL components
Ege: Coming back to the Modbus redesign PR
… we had some discussion which seems to be resolved
… would propose merging, are there any more comments?
<cris_> +1 for mergining
Ege: Okay, then we can merge
… (merging)
Merged
Ege: With this we are done with the current PRs
… the rest are more for discussion in the future
Binding Templates Issues
Issue #213
Ege: Kaz opened this issue after last call
… this issue consolidates a number of others
<kaz> Issue 213 - Need for improving the description within the Binding Templates document
Ege: the first deals with the ambiguity of what a Binding Template actually is
… the second one deals with the relationship to the ontologies
… I commented yesterday
… we are currently linking to the HTML version of the ontologies, so I would propose naming them ontology documentation
Cristiano: There are a lot of points, can we split the issue into multiple ones?
… not sure if it is more of a discussion issue
… we could also create a checklist
Kaz: Before creating this issues, I actually read all related documents and sub-documents
… and got really confused
… I don't understand what you want to describe for binding purposes
… for example, if we want to create a liason we would use the existing documents as a basis. These should better explain how to bind existing SDOs and protocols to the WoT
Ege: I understand your question, I think the main problem is that we are explaining how to create a binding template but not what a binding is
… however, this is more an issue with the architecture document, in my opinion
… (shows the architecture document)
… there is an explanation in the document, that might not be that easy to understand
… however, the binding templates should also be able to work standalone
… the explanations need to be clarified in general
Kaz: I suggested a clarification already a year ago. We should clarify the relationship and the role of bindings/binding templates before going into the next charter period
Ege: But is the current explanation really that unclear?
… if so, then the explanation in the architecture document might need a refinement
… or the explanation needs to be included in the binding templates document
Kaz: If there is a redundancy between the architecture and the binding templates, then we need to think about whether the latter is actually needed
… before creating new bindings, there is a clarification and a better explanation needed
… if the description is already included in the architecture, then the core document could be removed
… bindings are very important for the next charter period
… and is the basis for further cooperations with, e.g., BACnet, NETCONF, or OPC UA
Ege: I think everyone agrees on that, the way is not that clear yet, though
Kaz: As I mentioned, I read the core document carefully again and what you are providing is not a guideline for how to create a binding but for how to create a document
… but that is not the most important point from an industry viewpoint
Sebastian: I can understand you, Kaz
… we need to take this into account to improve the clarity of the documents
… however, we also need to take developer feedback into account
… and I never heard that there are any problems
… or got bad feedback
… so we need to ask the developers again for feedback and what we need to improve
Kaz: That is correct
… also consider that this is an optional document for which we haven't provided an update yet
… therefore, the document has not been relevant for some implementors
Sebastian: You are right, we need to publish an update here
Kaz: I think the old version was also clearer than the current one
… maybe because some text has been removed
<Zakim> kaz, you wanted to react to kaz
Kaz: we should reconsider the document based on the industry feedback
Sebastian: I would propose reaching out for feedback and to ask them if we should take the old direction or the new one
<cris_> +1 for asking feedback
Kaz: I agree, this is also why I asked Mizushima-San to invite implementors such as ECHONET or Takenaka
Sebastian: Maybe we should create a special issue where people can give feedback on their preferred style of document
mjk: I agree that we need to develop the industry viewpoint
… we need to provide more than two options, though
… the actual way of surveying the developers needs some more thinking
… the description/guidelines should be on a high-level
… that could be used by developers to create a binding, after reading the architecture document
… we also haven't discussed how the governance for new bindings should work
… how should the artifacts be maintained?
… we probably need two documents for bindings
… 1. operational document with state-machines etc.
… 2. a document for the vocabulary
… sometimes, they could probably be combined
… the ontology might not be published by the W3C
Ege: This is actually already the case for some bindings, e.g., HTTP
Ege: we didn't remove some parts they are moved to a dedicated orphaned section
… we have a todo item to bring it back
Cristiano: think the current structure is good
… the previous one is referring to the old TD 1.0 version
… so simply comparing the current Binding Templates doc to the old doc is a bit dangerous
Kaz: I am not asking to revert to the previous status
… but rather I'm asking to think more about the structure before moving on with the updates
… I understand the complicated relationships with the other documents like WoT Architecture
… but the document structure is important and it should be improved based on the feedback from industry implementers
… that would make the document nicer
Ege: the architecture document should give an abstract information about binding templates.
… on the other hand Protocol binding templates document should give an in depth and concrete explanation
… I've created two issues
… please consider them due to next week
… we have also to consider if the input can be anonymous or not
Koster: I think when we do the survey we have to look for what we are missing
… we can get inputs to next work items
… as a starting point
… first we have to be sure that the current document have the state that we want it to be
… then we can ask feedback about what is missing and asking suggestion for improvements
… it should be clear that we are asking for gaps in the understanding
Kaz: I completely agree with Michael
… That's why I also asked Mishusima san to explain what we expect from protocol binding templates and how concrete protocols can be mapped to WoT when he organizes an event to get feedback from industry implementers.
… we should ourselves improve our understanding of protocol binding mechanism
… and then ask feedback
Ege: my suggestion is to label issues that we have to be done before asking for feedback
… I can do it
… I already have some issues in mind
… core document should be prioritized
Thing Description
Ege: welcome Elodie
Ege: we have 67 types of labels
… what should we do?
… is it a problem?
<kaz> (Elodie's self intro to be moved later :)
Elodie: hello, I'm working on behalf of siemens. We did a prototype of a TDD. We had some questions about TD
Ege: she is an expert of Semantic web technologies
… it is good that we have her on board
Issue labels
Ege: back to label issue
… many of them have no assigned issues/pr
McCool: do we have redundant labels?
… we should go one by one and understand if they are obsolete or redundant
Koster: I agree with Michael
McCool: don't delete them right away but open an issue to discuss.
Ege: problem is some of this labels make sense for past issues
CR transition
<kaz> TD Transition Request
McCool: we had to add a label
… now is done
… and they will met on Friday
… so more news incoming
missing implementations
<kaz> TD Draft Implementation Report
Ege: apikey in body is missing, but it is important (it used by Amazon greengrass)
McCool: I would prioritize basic functionalities
Pull Requests
PR 1733
<kaz> PR 1733 - PR 1733 - Overview - all TD implementations
Ege: the pr provides a crosslink between implementations and results
… no problem with it
… the tool is called xref.py and it is in the wot-profile repo
McCool: tool has some limitations
Ege: I think he fixed it
… the line numbers are ok
McCool: does he take into account child assertions?
Ege: yes
… is it fine to merge it?
McCool: ok
<Ege> https://
PR 1684
<kaz> PR 1684 - Fix shacl, context and ontology
Cristiano: Thanks Elodie for feedback. I have made improvements but there are issues that I could not fix
Cristiano: I took some shortcuts and for example the renderer now force strings for some types
Elodie: it is difficult to make everything work
… I agree, but be careful that adding the language tag force it to be always english
… not against but it closes the standard.
… also there are things that still does not comply to the ontology
… it is also a bug in the jsonld
… we should push it
… they are trying to solve it
… but it is not going to be soon solved
Cristiano: I agree with the problem of the title
Elodie: having lang strings all around is annoying
… most of the problem is when you combine TD context with TD context
Kaz: I'm confused about talking about this PR. It is a big change... we have submitted our CR request
… you said it is an editoral change
… but it contains too many changes
… it is not good
Sebastian: agree with Kaz. Lets wait until CR is published
Kaz: if we are not getting any changes in the index.html it is fine to merge, but we have to be careful and check if it is really true. Also we need to explain that we added these changes without any impact to the spec itself within the CR Transition Request or the PR Transition Request.
Cristiano: I agree that the Pullrequest is contentious
McCool: we should wait for CR
… and who is merging this needs to double check this.
<kaz> Cristiano's comments
<kaz> [adjourned]