Meeting minutes
Binding Templates
Binding Registry Requirements
<kaz> wot-binding-templates PR 378 - Registry Requirements Update
<kaz> Rendered registry-requirements.md proposal
Kaz: we need to clarify what should be discussed in the main call
Ege: there are items labeled "DISCUSS" we can review
… there are seven items, 2 or three of them are easier to discuss
… start with the fourth item, the document may be a section of a larger document
… the link should point to the section of the document
… are there any divergent opinions?
… seeing no objections, we can remove the DISCUSS label
… next item, "how is the review decision communicated"?
… the proposal is for comments to be added to the issue when the status changes
Koster: does this show up in our PM?
Ege: we should create a view for tracking binding state in PM
Ege: (creates PM column headings and policy text)
Ege: there is also the higher level lifecycle to consider, from initial submission to final
Ege: any opinions on the suggested PM rubric?
Koster: this is what I was thinking about
Kaz: what are the lifecycle states to be used for this purpose?
… we have been discussing the PM aspect but need to think about the lifecycle terms more
… this is a good starting point and may need refinement
Ege: some of these terms come from the registry analysis document we prepared
… they were inspired by the TTWG rubric
Kaz: I'm OK with starting with this current best practice by the TTWG, and would suggest we explicitly mention we'd like to use this term set based on the TTWG's practice.
Ege: some of the state terms don't exactly describe the situation
… any opinions on the current set of terms?
Kaz: we can modify these terms ourselves if needed
Ege: (records the terms as we just discussed)
Daniel: deprecated is probably not the preferred term
… we may want to choose another one
Daniel: the W3C convention is to indicate that a newer version is available
Ege: the W3C warning uses the term "outdated"
… and points to the most recent version
… the most recent version is called "latest"
… (changes proposed terms) does this look good?
Daniel: LGTM
<kaz> https://
Kaz: As above, W3C Process Document also defines "superseded", "obsolete", "rescinded" and "discontinued" regarding "outdated" types for outdated documents
… we could think about which would apply more precisely to our binding registry
Ege: reviews the W3C process document, also includes "Obsolete"
Koster: why not just use these terms? "rescinded"might need some policy definition
Ege: "obsolete" makes sense
Kaz: we can refine the policy later as needed
Ege: we need to write down the definitions
Koster: how does this work with semantic versioning?
Ege: there is some discussion already
Ege: how does the state change from initial to current? What are the specific requirements?
… how do we determine implementability criteria?
… we should not require a face to face event
… how much interop testing should be done?
… we discussed on Tuesday and propose that there could be an event where a set of affordances are tested and examples of usage scenarios are provided
… this can be VPN or face to face, and should include at least two entities
… ideally there would be a well attended plugfest
… does anyone have opinions?
Sebastian: the problem is that we don't in general have experience with specific protocols
… if we don't know about a protocol, how do we procees
Ege: it's done by the submitters and we need to have good faith since we don't do our own testing
Cristiano: there could be a playground for evaluation of bindings, and we could let the market/community of users to decide
Ege: it could be as simple as two companies doing the testing and providing us with the result
Cristiano: there could be some well-formatted way to manage the process and some public recognition
Daniel: interop testing should require two parties involved, what can we require?
Ege: we expect to require two entities
Daniel: this seems a bit strong because it requires a second company and there may be some simple corner cases that only involve one company. Is there a requirement we could set up for these cases?
Ege: maybe require two code bases or some other diversity factor
Ege: any opinions, or should we continue the discussion?
Sebastian: it depends on the implementations
Ege: maybe we should require more than one codebase
Sebastian: that may even be too restrictive. In some cases there are not many different codebases
Sebastian: we could provide comments to go with the bindings and explain the situation to potential users of the binding
Ege: any other business for today?
… adjourned