Meeting minutes
Agenda Review
Ege: We are going to have a look at Jan's PRs
… wanted to review, but a tool wasn't working
… there is also a small PR on PROFINET
… and the discussion on the binding registry
Minutes Review
<kaz> Feb-27
Ege: We only had one meeting last week
… you should have received the email already
… going to scroll slowly and see if there are going to be any remarks
… (scrolls through the document)
… okay, do we have any remarks?
… no seeing anything, then we can approve the minutes
Minutes are approved
PRs
PR 2082
<EgeKorkan> PR 2082 - Profinet Binding Addition to the table
Ege: This is a very, very simple PR
… (notices that there are a lot of unrelated whitespace changes)
… this is just adding the new PROFINET binding to the registry in the WoT TD specification
… in the diff, we can see that there is only one line added to a table
… therefore, it is mostly an editorial PR
… will check the whitespace changes
… but I guess we can go ahead with this one in the meantime
… there is a similar PR in the binding repository
… where I only added it to the README so far
… since the document is not supposed to be kept
… so the PR in the registry repository also only adds one line
… there is also one tiny unrelated change, but that was intentional
<kaz> Binding PR 416 - Profinet Binding Addition to Readme
Ege: I will merge the PR in the binding templates repository, but keep the other one open
PR 2080
<kaz> PR 2080 - fix: align JSON Schema with JSON-LD @context format
Jan: I did not change much. I investigated the question regarding contains field
… I have tested some examples
… this PR is necessary to ensure correct behavior
… if you remove the XXX in the first field, it will not be valid
Ege: so old schema validates the wrong one as correct
Jan: for some reason, the number value should not be valid
… we can still merge since it is an improvement
Ege: I will do a PR in playground to run a test
Cristiano: I am okay with merging this PR
… but I am a bit concerned with the current behavior
… as there are cases that pass that should not
… so maybe we should remove the lines that are not related to the issue at hand
… dealing with the TD context URLs
Jan: We can remove these lines and open an issue for that to deal with that problem after merging this PR
Ege: (adds a comment to the PR summarizing the discussion)
… (tries to validate some TDs with different TD context URLs, noticing issues with the context validation)
… so I see we definitely have a problem here, we can follow up on that
Daniel: So the changes the allOf and the contains seem to be required to apply the original fix
Ege: Will deal with the issue after the call
… generally need to apply contraints on contraints, it is difficult to model what we are specifying
PR 2081
<kaz> PR 2081 - Make contentType optional in ExpectedResponse and AdditionalExpectedResponse classes
Daniel: I think last time you, Ege, raised the question whether content type should be optional in general or not
Ege: Should we be able to express that there is no content in a response in general? Since we are not able to express that lack at the moment
Cristiano: I am just wondering
… I am okay with this change, also briefly discussed that in the Scripting API call
… but we want to express in general that there is not output, for example in the case of an action
… e.g., a void return value in TypeScript
… I am okay moving forward with this, however, maybe we want to express no content being returned in a different way
… currently, there is no way to explicitly state that there is not going to be a content type
Ege: I think the current way is only to use a data schema or leave it
Cristiano: Could be a good way to handle this
Ege: But the solution should be clear then, so if there is no schema then content type should not be present
Cristiano: By the way, this is related to TD 2.0, right? We do not need to backport this, right?
Ege: Exactly
Cristiano: My point of view is that we need to review this, but we need to start somewhere, so go for it
Ege: (adds a summary comment to the PR)
… what do others think? Any other remarks?
… Is everyone okay with removing content type from all levels?
… in general, data schema and content type need to be aligned
… although bindings can make them mandatory
… in specific cases
Ege: Let me know, Jan, if you need any assistance
Jan: Will try to update the PR until tomorrow, will ping you if I need feedback
Kaz: I am okay with the direction and the changes, but maybe we should test the feasibility in a mini kind of plugfest
… as there might be some impacts for existing implementations
Ege: Should probably bundle it with other changes, maybe 5-10 and then test them together
Kaz: checking several changes at once is fine
Binding Templates PR 414
<kaz> Binding PR 414 - Requiring implementation experience for bindings
Ege: This PR deals with the aspect of implementation experience as a requirement for the registry
Cristiano: I basically addressed the comments and a logical gap
… I added a part regarding a test report to address your comment
Ege: That addresses it
… there is a typo
… (splits the current assertion into two sentences)
Cristiano: I think it is a good starting point
… maybe the text needs to be put into better shape, but it is a good basis for getting feedback from other groups as well
Ege: There was another assertion that we wanted to change, regarding processing
Cristiano: Wasn't sure whether we wanted to rework this requirement later
… but we can also change it now, as you wish
Ege: I think this should also deal with the aspect of explaining the work in a non-technical way
… (adds a suggestion to the line in question within the PR)
… that is more or less what the idea was
… so if it that is okay, then I would commit both of them
… then we can have a look at the new changes
… will also resolve the comments I had
… let's see whether the conflict is something simple
… seems like git is failing a bit
Cristiano: Probably some whitespacing that got it confused
… also the discussion was removed
Ege: (resolves the merge conflict)
… alright, so now the discuss label has been removed, which is nice
… we now also have the requirement of testing experience, needing a consumer and a procuder, and that there needs to be a testing report
… that the submitter will make the transition but that it can also be made by the custodian
… if there is no additional feedback on this PR, then we can merge it
… I will squash and merge this PR
… no one is on the queue, then we can merge
PR is merged
Binding Templates PR 419
<kaz> Binding PR 419 - Unique Item Names
Ege: This PR deals with adding named anchors to the registry requirements document
… adding almost human-readable IDs/words to be able to reference sections
… works with the traditional markdown way of referencing section
… also works with the rendered version, where the labels will be underlined
… it is also easy to add new links
… clicking on a link will bring you to the respective place in the document
Daniel: It's great improvement, although of course there will be no check for dead links
Ege: There is a merge conflict, I will resolve it, then we can merge the PR
AOB
Ege: With that, we are almost out of time
… any other business?
<kaz> TD Issue 2085 - Add a schema for unobserve/observe property
Cristiano: Just wanted to mention that there are two issues that have been opened from the Scripting API call
Ege: I've seen them
… issue 2085 has also been bugging me as well
Cristiano: Maybe we can define a user story for that
Ege: Everything about consistency does not necessarily need a user story
… but here can't hurt, good to document the decision we will make it
[adjourned]