W3C

– DRAFT –
WoT-WG - TD-TF - Slot 1

05 March 2025

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Jan_Romann, Kaz_Ashimura, Mahda_Noura, Michael_Koster, Tomoaki_Mizushima
Regrets
Sebastian
Chair
Ege, Koster
Scribe
JKRhb, EgeKorkan, kaz

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]

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).