Meeting minutes
Agenda
<kaz> agenda for today
Ege: we will discuss Bindings and registry requirements analysis
Minutes
<kaz> July-25
Ege: any remarks on the minutes of previous week?
Ege: minutes approved
Binding Templates
PR 337
<kaz> PR 377 BACnet protocol binding improvements
Koster: no comments
… I approved it
… we can merge it
Ege: merged
Ege: FYI Dogan started working on event support for bacnet binding
Thing Description
PR 1201
<kaz> wot PR 1201 - Initial Connection Figures
Ege: quick updated
… luca updated the pictures as requested
<EgeKorkan> Preview of usability-and-design.md
Luca: Are SVGs working?
Ege: it seems so
Luca: then we can convert them
Ege: yes
… just a minor issue, it seems that one of diagrams is duplicated.
… we will convert all the figure to svg
… but we can do it asynchronously
Kaz: there is also a broken link
Ege: ah right
<kaz> https://
Ege: I'll fix it too
Luca: I have the fix for the first problem
Ege: not fully fixed
… we will do it later
Luca: it should be a caching problem
Ege: yes, fixed
Binding Templates - revisited
Registry requirements
<EgeKorkan> wot-binding-templates PR 378 - Registry Requirements Update
Ege: we have different sections in the document
<kaz> Preview of registry-requirements.md
Ege: the entry format section has requirements for the document proposal submission
… we still need to define the status
… and the lifecycle
… the basic requirements will go in the entry format document or other part of the final document to explain our reasoning
… the final document should have just three major sections
<EgeKorkan> Entry format: what is put into the table and not what the binding should contain.
<EgeKorkan> Lifecycle of entries: how are they submitted, updated, deprecated etc.
<EgeKorkan> Submission Requirements: What the binding has to contain in order to go into the table
Ege: any comments on the document basic structure?
Ege: we now move the text contained in the Basic Requirements section to the new structure.
… we had a review about how the whole process should be as objective as possible
… but it is still to be defined
… we can build a sort of test suite
… uri schemes are still under discussion
… main thing we should decide today is the lifecycle of the entry
… as an example I can show the TTWG registry
<kaz> Updated preview
<kaz> Registry Mechanism Analysis (registry-analysis/Readme.md)
<EgeKorkan> TTWG Registry Boilerplate - "2.3.1.1.1 Provisional"
<kaz> TTWG Registry Boilerplate - "2.3.1.1.2 Final"
Ege: in TTWG there is a basic lifecycle where you start from provisional or final (note: if you start with final you can't update)
… if you need to change a final submission you have to deprecate the previous one
Ege: I personally don't want this (=final submission) for us but it is something we have to think about
… regarding URI scheme the summary of the previous discussion is to have a provisional registration in IANA and in the final document have the full IANA registration
Cristiano: TTWG workflow is not that bad
… we can re-use it
… provisional URI registration is not that bad either if some other version reaches the full registraiton by IANA we can deprecate the binding and move to its final version
Ege: another point is to discuss what is the objective mechanism to confirm the entry.
… draft status requires no check from us but just the correctness of the document
… for example: has a json schema and maps all the operations
… but in the final stage we should require some concrete expirience
Cristiano: virtual plugfests should be ok too
Koster: does this mean that we will have some assertions from the WoT side? is this practical? what we need to do to make it work?
… is more along the line of implementation experience not testing suite
… a good faith approach
Ege: +1
Jan: I was wondering if there should be some sort of interoperability requirement
Ege: valid point
… should we try to ask more than just the submission of a valid thing and consumer?
Kaz: W3C process does not require interoperability testing using actual multiple implementations, but of course it would be nicer to have that (if possible). We should be careful about how to deal with the "interoperability testing" within the ordinary implementation report (or possibly within a separate interoperability test report).
Cristiano: I like to have the initial draft not requiring any concrete implementation
… this should favor an open action to build the implementation of the binding.
Cristiano: it would be nice to keep discussion about implementation open
Ege: yes, but some companies or organizations might have stricter requirement
Ege: we got good progress for now
Kaz: should we add some label or note (discuss point) about what is the implementation experience to move from initial to final status?
Ege: yes, adding a discussion point in the document
[adjourned]