Meeting minutes
Minutes
<kaz> Jan-30
Cristiano: minutes looks good, just one minor issue with Jan names
<kaz> fixed
Cristiano: minutes looks good, any issues?
… ok minutes accepted
Cancellations
Cristiano: I'm not going to be available next week, should we cancel the meeting?
Daniel: it should be possible to have the meeting
… but I might be late
Cristiano: we can start 10 min later
Kaz: please record the decision on the Scripting API wiki and the main wiki (cancellations section)
Daniel: we should also mention it during the main call
Publication schedule
Kaz: when do you think we will publish an updated note? middle February?
Daniel: the sooner the better
… we are already collecting complex changes
Cristiano: I agree
Zoltan: we basically have agreed to do two publications: one first with just fixes and the other with bigger refactors
Daniel: we should also discuss about next charter proposal
Kaz: end of July is the deadline of the extended Charter, but the WG would like to finish our work by the end of May.
… so we should carefully think about by when we should do what.
… my suggestion is clarifying questions one by one and deciding a concrete dealine
Cristiano: ok I think we can start from clarifying the issues that we want to tackle in the first publication
Issue organization
<kaz> wot-scripting issues
Cristiano: we already have a label for easy fixes of the apis
Zoltan: exactly
Cristiano: should we add more issues?
Zoltan: 430 might fall in that category but I think we can do it as part of the next big publication
Kaz: I agree with Zoltan, and also would suggest some more. Clarifying relationships between spec documents is very important for the future
… how to use protocol binding from scripting API and how to send parameters and action between the peers (also error codes) is very important
… we need an additional categorization for issues
… across all WoT repositories
Cristiano: I agree
… maybe it is better to talk about it in the main call and define a common approach
… as suggestion for the next call we should fix the issue list and define the concrete dealine for the pubblication
… is that ok?
Kaz: ok
Daniel: ok
Issues
Issue 422
Daniel: PR is ready to be reviewed
… see w3c/
… I added an item on the charter document
… a concise summary of our goals
… in the old charter we linked to the last published document
… now I'm linking to a very old published Scripting API document
… we should keep this in mind
… and update it
<dape> old charter: https://
<kaz> add scripting api as other deliverable to 2023 wg charter
Kaz: As a mentioned last week, I have already copied the PR 1068 to the dedicated wot-charter-drafts repo as its PR 11.
Daniel: just a quick note, the PR is in draft mode until we approve it
Kaz: We as the Scripting API TF can provide any proposals for the new Charter, but the WG as a whole is in charge of the Charter discussion.
… the discussion should happen on charter specific meeting or main call
… most important things to be noted in the charter are: what is normative and whant is not and liasons
… the question should be: would we like to make the scripting api normative again?
Cristiano: We can talk about that topic in the next call
Cristiano: should we also mention onboarding or managining ?
<dape> w3c/
Daniel: we already decided that Scripting API should be a Normative Note
Zoltan: there was a formal objection against Scripting API being a normative document
Zoltan: so if we want to change it we should address those comments
Zoltan: managment api can happen on scripting API but usually they are tackled as a different security level
… my personal opinion is that it should be published in another document
… we can talk about configuration API
Zoltan: but it is important to discuss it
Zoltan: please kaz check if w3c/
Daniel: Just one comment, currently we are not aiming for a normative scripting api document
… this means that we didn't open the pandora box about formal objections
<Zakim> zkis, you wanted to ask if in issue 449 the filer, who is not member of the group, makes a non-substantial contribution and to comment on the charter items
Kaz: basically regardless of the document type, we should not have ideas from no-members
… getting inputs for use cases is fine
… but for the wg work is complicated
<Mizushima> +1 kaz
Kaz: we should start from an use case
… we can work together with the user to define a complete use case
[adjourned]