Meeting minutes
Minutes
<kaz> Apr-11
Ege: any concerns regarding minutes?
(None)
Ege: minutes approved
Binding Templates
registry
<Ege> wot Issue 1188 - Incorporating TTWG work into the registry analysis
Ege: analyzing TTGW work in registry analysis
<Ege> wot PR 1189 - TTWG Boilerplate Analysis
Ege: went through the resources and documented in PR
Ege: the interesting this I observed is, who is managing the registires, for them 3C team is taking the responsibility
… The above case is only when the WG does not do this
<kaz> rich diff
Ege: they have a process defined where you can create an issue, when you want to add something to the registry
Ege: they talk about how an entry evolves over time
Ege: they also clearly define the different states of entry
Ege: and in the provisional state you can do modifications, but in final entries cannot be removed
Ege: regarding deprecation they are really specific, you cannot deprecate and create a new one with the same name
Ege: I also have added a custodian section
Ege: is there any question/remarks?
Kaz: thank you for your survey, the description itself is a good starting point, but maybe we should distinguish the basic registry track from the process document and from the other examples.
Ege: good point
Ege: any other points?
(None)
Ege: we can merge this PR
TD
Toolchain
Ege: this is a repository from Mahda
<Ege> https://
Mahda: modeling TD information model based on LinkML
… incorporating with the WoT Security ontology, etc.
… to automate the data processing
… I've not yet done everything, though
… (shows the tentative results of the generated data)
Kaz: Thank you for the work, I have some questions
… Does this imply we should have a separate repository?
Mahda: For now I have it there, but we can move it to TD
Kaz: if it is tentative, early work it is fine but we should discuss as a group
Kaz: We should clarify the goal of this effort and the status of the work
Mahda: The readme is in a draft state
Kaz: my expectation is, for other guys as well, to get an easy understanding of the goal and status of the work first., e.g., on the README at the top level.
Luca: I had a look at the current structure
… all in all it looks great. Ideally we can put everything in the yaml and use jinja templates to produce final documents
… we should also check if we can produce all the resources and artifacts we currently generate
… with bikeshed and linkml, combined with github actions, we should be able to produce everything
… we need to better document how to use LinkML. There are some pitfalls
… such as getting all the python dependencies
… what is shown so far looks like a best fit for what we need
Mahda: we should have some small rounds on deciding some small technical aspects
Ege: Mahda did this in another repo to keep it more flexible for now
Ege: we should not have anything in a personal repo, how do you think we should proceed?
Ege: because until we don't generate everything in our desired state, we cannot replace our index.html.
Ege: we could have a seperate branch and once ready we replace the main branch, could become complicated in terms of PR reviews
Ege: or for the other option a seperate repo
Luca: given that this toolchain would replace everything, we could consider a clean state, we could keep everything in another branch, and once we are happy with everything we replace them with the new system
Luca: the way it works, we will literally have to replace everything
Luca: we can have some transition commits
Luca: we feed everything on bikeshed, we could do a couple of commit that convert the HTML to markdown, and then to ninja templates
Luca: I would suggest, that Mahda would need some help, and then get some volunteers, for the bikeshed markdown conversion, to also parallelise the work
Luca: I am suggesting this mainly, because LinkML is able to produce a markdown through templates, but making so that we produce an HTML that is fitting completely, bikeshed is getting standard for W3C
<Ege> [ Luca's point: A separate branch and then replace everything by deleting the root and getting a clean slate.]
Cristiano: I sort of agree with Luca to go with a seperate branch
Cristiano: I would say it's clear for everybody that branches are created for different versions, we need to change the render
Cristiano: Are you sure we need to do a full cleanup of the repo or do we need some of the files?
Ege: I think the publication folder is important, and I think we cannot delete everything
Cristiano: If we do some experimentation in the branch that is also fine, we try to squash some of them, and i guess working in another branch is nicer
<Ege> [ Cris' point: Agree on a separate branch and we can configure the renderer to use that branch. Don't switch to main until that branch is "ready"]
Kaz: I also tend to agree with the direction, but the toolchain resource itself is not part of the specification itself, eventhough they are related, we still need some dedicated work in the toolchain area, my suggestion is that we we have a separate repository for the tool chain, e.g., wot-thing-description-toolchain, and once the content is finalized we move it or we just keep it for the wot toolchain like the wot-testing.
Ege: That would technically work, but what it will produce will go to the spec, spec+artifacts. There will be things that we have write by hand. I think it will mess up the commit history. I would tend to keep it in the TD repository
Kaz: I am proposing a seperate repository so that it's cleaner, safer and also easier to handle at least as a tentative starting point :)
Luca: As it is right now, we have a situation with a mix of scripts, artifacts produced by scripts, editing by hand, and this is one of the pain points we want to avoid. The one thing I would like to have a consensus, is that we don't want to have this situation anymore.
Luca: The main point is that it would be good to prevent manual edits on machine generated artifacts
<Ege> [ Kaz's point: Temporary separate repo ]
Ege: I would be reluctant to say that the index.html is not included in the repo
Luca: first we need to see if we can generate everything with this tentative toolchain, for now it looks promising
Ege: I would talk further with Kaz, to see if it's fine to not have the index.html in the repo. But for the rest I agree.
Luca: Every minute that we invest can be spent on something else
Ege: in previous cases, there were people changing the index.html page, and we should make sure this does not happen
Ege: Luca and Cris you mentioned a seperate branch, but are you fine also for a seperate repo
Luca: I would be fine
Cristiano: Ok
Kaz: I can help with creating the repo and installing the resources from Mahda's repo to the W3C WoT side
<Ege> proposal: Create a new GitHub repository that will house the new toolchain-based working mode. When the new work is ready, we will submit it to the TD repository with a PR.
Kaz: the repo name should be decided too
Ege: I would say something with thing description, but people should not be confused, and realize this is temporary. Toolchain implies that it will stay. Maybe with temp
Mahda: I think with the toolchain name will imply that we are generating something for the users, maybe confusing, maybe something with specification generation
Cristiano: can't we just fork the wot repo?
Ege: no, it should be under W3C
Luca: we should consider that if everything works as intended, we continue the same for the profiles. All in all, if we make everything as simplified as possible, any name is good in my opinion
Kaz: my point is that we should have wot-thing-description and dash and SOMETHING and tmp, but I am fine with anything for SOMETHING above
<Ege> proposal: Create a new GitHub repository named w3c/
Ege: any objections to this?
(None)
RESOLUTION: Create a new GitHub repository named w3c/
[adjourned]