Meeting minutes
Agenda
Ege: Starting a bit late after the plugfest, have a full agenda for the two days
… picked the scribe, no guests today
… will look at the schedule and the content type PR
… also have binding template repo repo etc.
… if no time for that today, will postpone to tomorrow
Minutes Review
<kaz> Aug-6
Ege: As always, will go through the minutes slowly, let me know if you spot anything that should be changed
… any remarks for August 6?
… Seeing no one in the queue, propose to accept the minutes
Minutes for the 6th are approved
<kaz> Aug-7
Ege: Will do the same for the minutes for the 7th
… any remarks?
… seeing no remarks, minutes are approved
TD Publication
<kaz> WG Schedule
Ege: This is just a reminder that we are doing a document freeze of TD and Binding Registry next week (28th)
… so if you want to add stuff, you should start a PR before that
… once we freeze the document next week, we will make a group call for consensus in the main call to move to First Public Working Draft
… the same process applies to the Bindings Registry document
… the documents are the deliverables for this taskforce
… any remarks regarding the schedule until Sseptember?
… seeing none
Ege: Will reach out to people close to the implementations via the CG after the publication of the first public working draft
… not limited to them, let me know if you know other people that should be involved
Ege: I will now share the schedule for what we agreed on for the two documents
… (shows issue 2112 in the TD repo)
… we have a couple of ToDos/linked issues in the PR
… so far there has not been any new activity here
Registry Publication
Ege: There is a similar issue in the Bindings Registry repo
… (shows issue 12 in the wot-bindings-registry repo)
… there has been good progress here
Kaz: There was the question about the modification of submitted registry entries, right?
Ege: The whole wording is that we have a running registry when people are submitting bindings
… but we do not have the registry running yet. I will create an issue for that
Kaz: There are several related questions here, and the question you're mentioning now is how to deal with expected registry entries before the registry document is finalized.
Ege: (creates an issue)
… (mentions that the wording in the process and document our registry process assume a running registry and that the topic should be discussed with PLH)
Kaz: A related question is whether we can collect entries before becoming a W3C registry. My assumption was that this is possible. But that depends on the procedure in the document. We should clarify that and how to update the registry
Ege: For me, the main question is what happens before we have a registry at all and what happens if we change the entry in the running registry
<EgeKorkan> https://
Ege: (shows the table from the TTML profile registry document)
… they won't remove all the entries and ask people to resubmit, right? This is something that is not clear to me yet
… will assign the issue to you, Kaz, for talking to PLH, I can also join the call
Kaz: As I mentioned, you have two main questions: 1. How to deal with submissions before the document becomes a W3C Registry Document. 2. The procedure for the registration and updates
… we can manage this information via GitHub
Ege: But even on GitHub, we will need to create some kind of issue template
… we will continue this discussion with the process people
… (assigns the fpr-goals label to the issue)
Ege: We cannot use two mechanisms for the draft status and the final document, we need to agree on a single mechanism
Kaz: Since everything is managed via GitHub, we follow the precedence. We can make another proposal then
… there is no defined mechanism yet, we can refer to some of the existing mechanisms and then apply them as needed
Ege: What are the opinions in the group then? Should we define a process to accept entries before the registry becomes an official W3C Registry
Jan: I would be in favor, also to identify potential issues as early as possible. Would it be possible to still make changes before having the W3C registry though? I assume so?
Ege: I also think that accepting submissions before the finalization makes sense, also to avoid that the registry format changes later and we need to ask people to provide additional information
… so we would need to define a temporary mechanism, not making any guarantees, reserving the right to make changes
… but that might not make that good of an impression
… or we restrict ourselves to not make any changes
Daniel: I think we definitely have some pilots that check out whether the registry works as we expect it to work. But we should not accept too many. If we have people from the outside, we need to make clear that changes are still possible and should limit the number of external submissions
… otherwise we would have a lot of work changing the entries. But we definitely need a temporary registry, otherwise we will not get any feedback
Ege: (starts summarizing the discussion)
… so this should be mentioned in the registry definition in a note before transitioning
… we could disallow people from letting their bindings transition to the final state to indicate that the registry is temporary
Kaz: Agree with Daniel on the pilot approach
<kaz> AAC Symbol Registry
Kaz: also have existing documents (CoAP, HTML, ...), so we can start with them
… can deal with external submissions, for instance by ECHONET, later
… we also need to think how to manage the data
Ege: We already agreed that we will manage the submissions with GitHub Issues
Kaz: Right, and I think that kind of management aspect is more important here.
Ege: (amends his comment)
… any other opinions?
… Will also talk to Sebastian about this
… will probably not be happy that this will delay the OPC-UA submission
… (goes through his summary once again)
… if this is fine, then I think we do not need to talk to PLH in this case
Kaz: Of course, if needed, we can talk to PLH at some point
Ege: I think the process document needs to be improved
Kaz: I suggest you join the process CG :)
PRs
PR 2081
<kaz> TD PR 2081 - Make contentType optional in ExpectedResponse and AdditionalExpectedResponse classes
Ege: There are some changes to the PR needed, but I think we have a solution now
… Jan added the assertion that stated that if there is a content type at the form level, this a implies that there is a content type at the response level. But we cannot specify that there is not going to be a response then
… so Jan's suggestion was to set response to null
… another suggestion was to set the content type to null
… Ben Francis' suggestion was to use an empty object for the response to indicate that there is no body in the response
… Ben's solution was positively received by Jan and me
<dape> +1
Ege: so the way forward would be to take over this solution
… (no objections from the group)
… could also apply a similar concept to input and output data as well, but that can be another PR
Binding Templates PR 434
<kaz> Binding PR 434 - Retiring the main document
Ege: As we are short on time, but I wanted to quick overview
… will discuss/merge them tomorrow
… this one is about retiring the main bindings document, should be ready to merge tomorrow
… I think we will also need to update the WG schedule, will make PR for that
[adjourned]