Meeting minutes
Agenda Review
<kaz> Agenda for today
Minutes
<kaz> Jan-16
Ege: We will first have a minutes review of the meeting two weeks ago
… you should have received an email, will go through it to just see whether there is anything that needs changing
… (scrolls through the minutes)
… meeting was mostly dedicated to the registry discussion
… where we made some progress, some as yesterday
… yeah, and we had this resolution
… okay, anything to be fixed?
… did anybody see something?
(No objections)
… okay, then the minutes are approved
Use Case Test
Ege: Okay, then I will start with the use case test
… we had a use case call yesterday
<EgeKorkan> w3c/
<EgeKorkan> w3c/
Ege: where we discussed two issues that could be used as a basis for trying out the use case template
UC Issue 319
<kaz> wot-usecases Issue 319 - Meta Operation Payloads and Semantics
Ege: first I had an issue that was a bit difficult, then I found another one that was easier to handle
… McCool commented on the issue 319, was regarding metaoperations, he was able to understand it on his own, although the term was not familiar to him, should be split into multiple issues/user stories since it is quite complex
UC Issue 320
<kaz> wot-usecases Issue 320 - Indicating how often a property changes physically or event is fired
Ege: 320 was a bit simpler
… generally a good test run to understand the process
Kaz: The discussion itself is nice
… and the direction of having actually test cases is also nice
… but probably the direction and plan should also be explicitly mentioned by McCool during the main call
… not necessarily by you, Ege
Ege: So we should also discuss issues like these in the main call?
Kaz: McCool as chair should present the current direction as a progress report
Ege: I actually also wanted to ask other people to have a test run
… as I was personally involved in the process
… so a "random" person doing the test would be better
Kaz: Agree, this should be handled by the whole working group and interest group
<EgeKorkan> https://
Ege: Exactly, that is why I wanted to ask the people present to test out the template with some of the issues that have already been labeled as a user story
… like this issue 320
… so if we want to do a test run, please select one of the issues labeled as having "use case potential" to collect more experience
Ege: and by the way, when you submit the issue, the rendering looks a bit different after submission
CoAP Confirmable Requests
<EgeKorkan> wot-binding-templates PR 392 - feat: introduce cov:confirmable vocabulary term
<kaz> Korkan
Jan: it relates to w3c/
Jan: a device may not be always turned on. In CoAP, there is a feature that can help with it
Jan: Klaus said that the Consumer can decide on its own.
… so we don't need to mention this as another vocabulary term
Jan: but we can describe when the device is available
Ege: if we describe the device turned on or off, it is not specific to CoAP anymore right?
Jan: yes true.
Ege: this can be relevant for use case submission
Jan: the interval can be described and for how long. The Consumer can use an algorithm to determine when the Thing is available
… maybe we can use an existing method for this
Ege: you can submit a user story. I think there are enough use cases to motivate this kind of feature
Jan: I will do that
Ege: Thank you for the summary, quite relevant since this was also discussed during WoT Week
Binding Registry Requirements Update
<kaz> wot-binding-templates PR 378 - Registry Requirements Update
Ege: TallTed did some editorial reviews, which I incorporated yesterday
Ege: will now go back to some of the aspects that still require discussions
… would like to discuss one of the final points
… regarding implementation experience
… there have been opinions already
… my opinion in the beginning was to have some implementation experience but no certification
… some lab testing would be nice, but no in-person even required
… then there was the question of how many implementations there should be
… Koster and I arrived at the conclusion that there should be some kind of event where the operation of the binding is executed automatically
… would need some level of trust, since we would not be able to verify that the binding actually works
… could be connected to a PlugFest
… Cris also mentioned that there could be some kind of dashboard or collection of tests
… to show more data and indicate the popularity of a binding
… then there was also the point of two seperate entities, consumer and thing
… and show them in the registry table
… does anyone have additional opinions regarding this?
Daniel: Just a very simple comment
… not sure how well we can do this implementation testing
… could have several check boxes, proving implementatiblity
… credibility, showing what has been done, could be a guideline for users
Ege: So similar to what Cris said, do you think there should be a minimum?
Daniel: In the end, we cannot test it reliably, not sure whether we can lift it to the level of proper interoperability testing
Ege: Okay, so you say that we should say something about the extent of the testing, interoperability testing should be required to have a stable binding
… but no one has agued for a test suite, if I see it correctly
Kaz: Probably, at some point we need to think about implementability and interoperability
… but I am not sure whether at this point the testing within the plugfest should be noted in the requirements document
… my point is that the requirements is getting bigger and bigger
… maybe we want to merge the document as is and then continue the discussion regarding testing later
… as we cannot say at this moment that we would like to require that
… the initial draft does not have to be perfect
… the framework is already okay, on the other hand there are a number of open questions still
… so maybe we should mark which parts are stable already and then create separate issues regarding the questions that still need to be resolved
Ege: This corresponds with what Daniel said yesterday
Kaz: I agree with him
Ege: Then I would say, for this one maybe there is something that we can ...
… okay, then I guess we can more or less merge this
… (adds "DRAFT" to the header of the document)
… the question would then be whether we should remove the DISCUSS points or just the comments
… so my proposal would be to keep these items
… and move the comments to the issues so to say
Kaz: If you can do that at once, that is fine
… but for today, maybe we can keep these discussion points and create separate issues
… would be nicer to share the load :)
… my point is that we should not remove these question points but create separate issues later for them
… so I basically agree with you
Ege: Yeah, so we should not delete them before an issue has been created
… after that we can link to the issue from the document
… then I would say, I create these issues
… but it would be nice to have everyone's opinion on it
… then I would use everybody's GitHub tag
Ege: For the other stuff on the agenda, I think we cannot do anything right now
… does anyone have any other issues they want to bring up?
… otherwise there are just some other issues we can work on asynchronously
<kaz> (getting some trouble with the GitHub server and can't continue the discussion now :( )
Kaz: I am okay with closing the call earlier
… also considering that GitHub has some server problems
Ege: Okay, then until next week I will deal with the binding templates and we can have a look at the initial connection again
AOB
None
Ege: Next wednesday is cancelled
[adjourned]