Meeting minutes
Agenda Review
Ege: we will start with binding reqs, then refactoring, data mapping
Binding Registry Analysis
<kaz> [DRAFT] Registry Mechanism Analysis
Ege: we have merged the PR which had TODOs
… thus we have two PRs that move things around
wot PR 1199 - Remove requirements
Ege: first removing the draft from the title
Ege: also it removes the requirements part from the document
https://
https://
… I have added the mention that until the html doc is ready and there are no todos, this md can stay
Kaz: thank you. This is good direction
Ege: the process document analysis will come later
Refactoring of Binding Section
PR 2030 - Binding Examples Refactoring
I have addressed https://
<kaz> Preview - A. Example Thing Description Instances with Protocol Bindings
Ege: I have moved the examples in the beginning all to the appendix
… all examples have the same intro part
Design Decisions
Ege: McCool was documenting the requirements of the current discovery document
https://
Ege: we thought that we can tackle this since we have issues about this such as w3c/
<kaz> Issue 1889 - Documenting Design Decisions
<kaz> Issue 1824 - Make more explicit what to expect regarding Forms for the same affordance
Ege: we can have some ui elements that clearly explain why there is a feature and mark it as a requirement
Luca: having multiple per affordance is clear. Multi protocol or multi security for example
… however in the case of jpeg or png, both data would be semantically same but not the same information would be provided
… we need to define what means similar
… HTTP with JSON or CoAP with CBOR, once you deserialize the content, it is exactly the same
… once there are lossy content types, then there will be different information
… we should have a limit on how different information two forms can provide for the same operation
… and same affordance
… do we want to enforce that same operations of an affordance give similar information (to a degree) or say that they have to give the exact same information (thus PNG and JPEG would not be accepted)
Cristiano: this applies to input as well?
Luca: That is different though
… when you are giving input, you know what input you are giving. There is only one. In output, two consumers can get a different output based on the Form
Cristiano: it is possible to provide the wrong header if you choose the wrong form
Luca: if you have multiple input possibilities, you would send the one you want and the Thing should accept it
… if the consumer always get the lossy output, over time, its knowledge can diverge
<cris> node-wot Issue 854 - Handle form content-type client side
Ege: I would like to get a section that explains the reason why we have multiple forms and when you should design a TD with multiple or not
Daniel: we should explain how to create TDs but not put rules on how the TD must be designed
… this will get too complex to specify on our side
… it will depend on the use case
<cris> good point dp
<mjk> profiles can be more restrictive
Daniel: like the discussion on post or put, we let people pick what they want
Kaz: this is good starting point but we need more clarification
… we also need to explain how to specify the consumer's preference on the data it wants to get.
… we should have examples of devices and types of data
CoAP Observe Subprotocol
<kaz> wot-binding-templates Issue 348 - Constraints for the use of cov:observe
Jan: in issue 348, we came to the conclusion that subprotocol for CoAP observe would not be needed
<kaz> wot-binding-templates PR 353 - Replace cov:observe subprotocol
Jan: it can be always assumed since the protocol mechanism works like that
Jan: also we are adding that you should not observe multiple properties at the same time
… also there is a new draft called coap pubsub which can give reason to use subprotocol field
… there is also Series Transfer Pattern (STP) in the works
mk: CoAP pubsub is about setting up a mechanism to do publish and subscribe like in MQTT
… maybe we can just reuse observe mechanism
Ege: should meta operation capability depend on the Thing capability?
Jan: yes I have added this as a recommendation
Ege: so the observe option is always there in the request, the Thing may not have it and respond accordingly?
Jan: yes and the Consumer program would not notice
Ege: Maybe this can be generalized, i.e. if there is only one way to do something, it can be always assumed
Ege: let's wait for Klaus. I will also try to review
<kaz> [adjourned]