Meeting minutes
Agenda Review
Kaz as you mentioned, we didn't have an official call yesterday, but had brief chat and got important opinions there
… so would suggest we record those points here on the minutes
… then we should review both the minutes from last week, Feb 21 and 22
Koster: Agree
… Today, we are going to focus on the registry and toolchain (?)
Minutes Review
Feb-21
<kaz> Feb-21
Koster: Just skimming over the minutes from last week
… does anyone think anything is missing there?
… think we had a more detailed discussion related to the toolchain yesterday
… I think we can then approve the minutes, does anyone object?
No objections
… then we can consider the minutes from February 21 approved
… then to the minutes from February 22
Feb 22
<kaz> Feb-22
Daniel: Just noticed that some of the commands from the script did not work
… some insertions by Kaz have not been processed
Koster: Oh, yeah, that is then only editorial, right?
Daniel: Maybe Kaz can fix that
Koster: Yeah, is that easy to clean up?
Kaz Technically, we have already approved the minutes from the 21st, right? And we are now talking about the minutes of the 22nd?
Koster: Correct
Kaz (checks the minutes of the 22nd)
Koster: There are also two comments that are out of place that are related to the CoAP topic
Kaz Please reload the file
Koster: (reloads)
… Yeah, that looks good, these issues have now been corrected, thank you
… there is a misspelling of IANA ("IAMA")
… there is a comment by Jan that has not been formatted, but that is probably a chat message by him
Kaz Correct
Koster: There is also an empty comment associated with Ege
Kaz We can remove that
Koster: Any other additions or objections to the minutes from the 22nd?
… then I would propose approving the minutes
No objections, minutes are approved
Yesterday's Meeting
Kaz Maybe we can quickly record the discussion from yesterday's meeting
Koster: So, to recap
… yesterday we had an informal discussion to brainstorm how to make progress on some of the areas we have been circling around
… the discussion focussed on three main areas
… one being the toolchain, as we already discussed in the meeting of the 21st
… then the ontology
… which is mostly about resources and versioning
… we should probably be specific that the main issue here is versioning
… and the third one was the registries
… a minor issue was also project management, but as that is going pretty well, we decided to focus on the first three topics
Koster: With the toolchain, the summary is that we better need to clarify what problem we want to solve
… we already know how to do it, but we want to solve the problem of complexity
… which built up over several years
… Mahda did a great job of documenting most of the process as a diagram
… but what we agreed upon was that we want to sort of put that aside for now and try to generate a simpler diagram focussing on the inputs and outputs
… we already know what the inputs are
… and we know what we want to produce
… and in the middle, we can consider that part as a blackbox which we can gradually improve
… we wanted to have a separate meeting for the toolchain rather than integrating it into the regular call
… which would allow us to do some deep-diving here
… we recognize that what we are doing is software engineering
… and should start with a new diagram
Koster: Regarding versioning, we had a contribution by David Ezell from Conexxus
… which we can use as a model
… for semantic versioning, we need to clarify what constitutes a minor or major changes
<kaz> Information about Semantic Versioning from David
Koster: Regarding the registries
… we kind of realized that we did not have all of the requirements
… and that the discussion might have gone a bit off track
<Ege> ok I have to leave but can someone send me via email the versioning document from David Ezell?
Koster: maybe we need to think about the requirements a bit more
… is there anything I got?
Kaz I think that was a great summary
… it was a casual, but a great discussion
… if everyone is okay with that direction, we can follow up on that discussion
Koster: Going forward, I think we need to be a little bit more careful. I think one thing to take away is that we can use the registry discussion as a template for other topics as well
Binding Templates
PR 352
<kaz> PR 352 - Min Polling Interval in CoAP
Koster: This one is still open
Jan: Ege wanted to make some improvement regarding the generation of the document
… still pending
Registry Analysis
<kaz> wot/registry-analysis/Readme.md
Koster: There is still some uncertainty regarding the requirements
… let's see if we have some requirements in the readme file
… (skims through the document)
… we have W3C registry analysis and the IANA registry analysis by Cristiano
… the whole point of IANA, from my point of view, is that there should be no conflict in the assigned names and numbers
… and that there are no duplicate registries
… the third thing is that they will check the work, but that might be the least important point, as there are differences in the thoroughness of the reviewers/experts
Koster: The requirements we have in the document are mainly about interoperability
… one main thing is also that we make the process transparent to experts
… it always been that way, but we can also decouple the process from the W3C a bit
… all while the binding documents themselves are actually non-normative
… in the W3C sense, with the main normative content coming from other SDOs like Ashrae or OASIS
… still an open question whether the review is part of the TD taskforce or whether there should be another group that reviews submissions
… bindings should be "webby", question what kind of document a binding should be
… in terms of requirements for the specification, we mainly need to think about documentation requirements, so the format of the submitted document
… versioning, deletion and deprecation are also requirements listed here
Koster: I think we had discussions already, so we are ready to start the work here
… I think we also talked about where to publish the registry, whether it should be a W3C or an IANA registry, for example
… so, for me, it is obvious that the registry should be a W3C one
… don't think we need to worry about that too much
… other aspects related to the internet and names and numbers would go to IANA
… we may need some more discussion regarding W3C registries and with the people involved
… then there are questions regarding the registration of URI schemes, whether they need to be registered with IANA or can be temporary
… so I would propose using a W3C registry and then using IANA when required
Kaz Thank you for the summary, Michael, I completely agree
… my understanding is that we should generate a document like DID
… using the registry track mechanism
… so we would create a document for registering binding template documents, although DID is still using a note document
<kaz> DID Specification Registries as an example of Group Note
<kaz> WebCodecs Codec Registry as an example of W3C Draft Registry
Kaz and look into our existing bindings and how they would fit into the new mechanism
Koster: We need a new document, a spec describing how the registry works
… is there an existing document (e.g., by DID) that describes how the process works?
Kaz I posted two examples above
… the content of the two specifications is quite similar, although the DID is currently on the Note track, only the style is a bit different
Koster: Even the style is not that different as both are from the W3C
… but styling according to W3C processes is another requirement
Kaz Yeah, and we need how to manage the process according to Cristiano's analysis
… regarding the design of the individual entries
… so, for us the question is, what kind of information from the binding documents we want the entry tables to be managed
… I think our preference should be to use the registry track
Koster: Ah, so the DID specification is not using the registry track, but the note track
Kaz Exactly, the registry track was not available then, but they are considering switching to the registry track
Koster: Is there any advantage of not starting as a registry track? I think we can just start as a registry track document, right?
Kaz Exactly, that would also be less confusing
Koster: So I think we can simply start with the registry track, unless we find any issues with it
… and create a draft registry similar to the Web Codec Registry
… so I think we can make the decision to use this kind of registry process
… and then make a small number of IANA registrations if needed
Koster: By the way, does this document manage any external registries?
… so for example, does it register something like a URI scheme?
… something like that would probably also go into the registry document
Kaz So if you look into the document, you have an "Audio Codec Registry" section linking to the individual specifications
… these is quite similar to our main Binding Template document
Koster: So, the Procotol Binding document will be a new document which is going to be a registry document
… as this is the way it is done in W3C, unless we find a reason to do it differently
… we should start generating this document
Kaz I also think that what we are doing is quite similar to what this document does
… so we could basically change the title to "WoT Binding Template Registry" (laughs)
Koster: Yeah, we can basically reuse their structure
… and use their document as a template for our own
… if we fill out this template, then we can answer all of our open questions
… if we write up the "Registry Entry Requirements", we will be able to answer how this process should look for us
Koster: I think we made some progress
… we can go from here
… next step will be using our project management approach and create the document
… and also review with Ege
… any other business?
[adjourned]