Meeting minutes
Agenda Review
Ege: (picks a scribe from the list)
… today, we will be talking about the TPAC planning and the use case process
… and a little bit about the breakouts
… but not too much
… then there will be a little report on the toolchain and some other things
… but expect more discussion about the TPAC
Minutes Review
<kaz> Sep-11
Ege: With that out of the way, we can talk about the minutes from last week
… everyone should have received the link
… I will go through them slowly
… let me know if anyone is concerned about anything here
… (scrolls through the minutes)
… okay, it seems it was a very short meeting, are there any remarks?
… not seeing any, we can approve the minutes
Minutes are approved
Ege: Regarding the agenda, tomorrow we will look more at tooling and refactoring aspects
… (updates the wiki)
TPAC
Use Cases and Requirements extraction
<EgeKorkan> TPAC 2024 WoT wiki
Ege: So, let's go to the TPAC wiki
… I pasted the link
… we are focusing on the Thing Descriptiong, Profile, and Binding aspect today
… what we discussed in the use case call today is that we are going to discuss this with Michael McCool as well
… (has some technical difficulties for a moment)
… this was something that Daniel and Jan have done so far
… could only look at it yesterday
… so the point is that there are some improvements needed for the use case template
… some aspects are a bit too technical
<kaz> TD Issue 2039 - Using the New Use Case Template and Gathering Experience
Ege: this was also mentioned by McCool, we need to improve the template a bit, we need to get to the problem faster
… the introduction needs to give examples, but they need to be non-technical
… both use case introduction given in the issue are a bit too technical
… they should be more like "As a TD developer I want device that is operating securely"
… needs to be closer to actual applications
… during TPAC, Michael McCool will give these examples but will reword them
Kaz: Agree, not objecting to Daniel's template submission itself, but we need to differentiate feature requests from use cases
… therefore, we should have use case descriptions as Markdown files and then give detailed feedback
Ege: Agree, also Daniel did nothing work, valuable to have the description here
Daniel: I think there is a very simple use case description
… I have something like Phillips Hue and want to access the data
… not sure if that needs be put in another bucket, but that is what I meant
Ege: Same thing goes for the example from Jan
… pretty simple use case
… we are trying to document the reason why we have a certain feature
… the fact that the features are so simple makes you question sometimes whether you actually need to document it
… I am a bit unsure how to turn these into use cases without doing "dogfooding"
Jan: I think I also focused a bit too much on the technical aspect, maybe there could be more guidance on providing user stories etc
Ege: I also wondering how to guide people towards user stories
… personas is also something that Michael McCool will use
… (shows McCool's TPAC presentation)
Kaz: Maybe if we could clarify feature requests and solution proposals that would be nice, but maybe we should not dive into the requirements too deeply for now and focus more on roles
… maybe it would be better what to be described in the solution proposal section
… not too technical, but more what to be expected from the submitter
Ege: Solution Proposal and expectations are optional in the template
… so this is more for people who already know how to solve the problem
Kaz: Maybe we can ask people to give more information regarding the overall use case description and focus less on the solution proposal
… then at a later stage a concrete solution proposal could be given
… but initially, the introductory sections and the problem statement should be more detailed
… maybe we need some more guidelines to describe this template
Ege: Luca, we should meet with McCool to do some concrete planning
<kaz> Ege's comments
Breakout reports
Ege: We are preparing some slides for the breakout reports
… JSON-LD is rechartering by the way to also support CBOR and YAML
… so this would mean that we could support more formats out-of-the-box
… (adds CBOR-LD, YAML-LD breakout to the wiki)
… with that, I think we are fine for TPAC
… Michael Koster, was that everything for the TPAC prep?
Koster: I think so
… since we also simplified it a bit and are not doing profile
TD
Toolchain Discussion
Ege: Over the course of the last months there has been a lot of work from Mahda and Luca
… there is now a package manager that simplifies working with Python
… better CLI, creation of python package
… there are also now post-processors that take care of some issues regarding JSON Schema, the JSON-LD context etc
… eventually, they will be upstreamed to the LinkMl project, to have these features natively
… some keywords are now reserved
… the README has also been improved, detailing our vision
… and how to use everything
… Mahda, do you have something to add?
Mahda: No, it was quite clear, thanks
Ege: Something I forgot: We meet every Tuesday at 14:30 CET (which is like the second half of the main call) now
Refactoring
Ege: I did an analysis before my holidays
… maybe some have already seen the comment
<EgeKorkan> TD Issue 1259 - Consider removing section 8.3.1 Protocol Binding based on HTTP in version 1.1
Ege: so one part of the refactoring is that there is going to be a registry that will be linked from the TD spec
… we were also discussing removing the HTTP binding as a default
… in the beginning, there was support for that
… in my analysis, I found a couple of things that we need to discuss
… for example, we would need to remove the HTTP binding from the TD context, which would be a breaking change
… there are also a number of defaults
… for example, the method names have defaults, I prefer the approach in the binding that gives defaults for certain scenarios
… there are other aspects, like sequence diagrams in the binding and the TD documet has an assertion regarding the HTTP binding
<kaz> TD spec - 8.3.1 Protocol Binding Templates
Ege: I think only the first point really needs discussion, the other ones should be quite straightforward
… I guess after TPAC, there should be some work happening here to get rid of this in the TD spec
JSON Schema VersionInfo Errata
<kaz> TD Issue 2012 - Errata Management Implementation
Ege: Mahda opened this issue, where Cristiano and Jan also commented so far
… this counts as an errata
<kaz> TD PR 2049 - Errata Management Update
Ege: there is also a PR already, that will fix it, but we still need to add the errata
… this is an opportuity to test out our errata management policy
… we passed in the main call three months ago
… I created a pull request that details the process of how to add a errata for a document
… so in the case of this PR, we would decide that this is indeed an errata and we would a label
… which would be added to an issue
… that issue needs a PR with the fix which will get another label
… then the PR can be merged after an official task force resolution
… does anyone have opinions on the Erra Mangement Update PR?
Kaz: We can quickly go through the changes
… if it is okay for the TF, we can merge this and report it back to the main call
Ege: Yeah, I will quickly show the rendered version of the errata report
Daniel: I was wondering if we need the same fix for the other files as well
Ege: Technically, it should not have an impact on other files
Mahda: I think we also need to fix the ontology
… currently, there is still an issue with the toolchain, however
… as this keyword is defined twice and we would only need to define it in one place and then reference it
… I am not sure if we can make that change now or whether it will break things if we do so
Ege: (summarises the discussion in a comment on the issue)
… technically, that would probably need another errata
… (shows the errata policy again)
… there has only be one update, the version that is mentioned in the text (changed from 1.0 to 1.1)
Kaz: Quite minor maybe, but it might be better to say "TD Taskforce of the WoT Working Group"
… maybe we can shorten it at some later point
… and use the longer name for now
Ege: I fixed it at the top
Kaz: At the bottom, there is also an author mentioned, that should also say "Working Group"
… (notices that it is his name that is written there)
… fine to put my name there
… but the working group should also be mentioned there, probably
… probably needs a bigger discussion, though
… but fine for now, as the text is generated based on our general policy
Ege: Fine by me, I will update the text with the usage of the task force and make sure that it is aligned
<kaz> HTML Preview for the proposed errata.html
Ege: alright, I will do this
… and we can merge this. Afterward I will also update the labels
Kaz: By the way, I've added the URL for HTML Preview for PR 2049 as above. If you'd add any more changes to the PR, we can use sn updated URL for HTML Preview.
Ege: Today, we are done then, tomorrow we will talk about the initial connection
AOB
No other business, meeting is closed
[adjourned]