Meeting minutes
<Ege> https://
ege: (explains the W3C patent policy)
<Ege> no
<Ege> Luca is also having issues
/w3c.zoom.us/j/89964604906?pwd=bDlHMWFpeTJZeitXMDZzYkZaMXk2dz09///w3c.zoom.us/j/89964604906?pwd=bDlHMWFpeTJZeitXMDZzYkZaMXk2dz09
<Ege> can you try the zoom app
<Henk> benfrancis, I'm using the browser. Seems to work.,
<Vignesh> I agree to the patent policy
<Ege> https://
<Ege> https://
<Vignesh> Its a 404
ege: topic for today is the "Common Definitions" feature of the Thing Description format
<Ege> https://
Common Definitions feature of TD
ege: (explains user stories for common definitions)
ege: the problem being solved is that in the "form" element of the TD there are repeated verbose statements in each instance of the form
… The "base" element isn't sufficient for all the use cases
<Vignesh> I would say additionalResponses would also fall under same category
ege: and the semantics of interactions are not clear
<Henk> I have run into these problems in hiveot. Especially connection management and duplication of forms.
Vignesh: it would be good for example to describe error response only once
ege: agreed and noted
henk: connection management is a big problem as well as security protocol
… Also a lot of form elements don't add value
… and the problem of multiple bases
vignesh: An improvement would be really helpful for MQTT
ege: for more use cases, we can add to existing issues, cerate new issues, and update the markdown document as needed
… Requirements are to be able to reuse the common definition by linking inside the document
… there needs to be support for a global media type
… multiple base URIs
… initial connection
… also wrapper schemas for messages
dape: preprocessing for the global media type requires expanding the TD
ege: we will specify an algorithm for expansion
… we want to make sure that the simple cases are easy to describe and not burdened by the new mechanism
basic mechanism
henk: how will support for multiple protocols affect the TD?
ege: there is a default protocol
… There are inline fields and thing-wide defaults
… there are thing-wide defaults for security, connections, forms, and schemas
… (explains examples in the tooling folder)
<Henk> Ege Would it be possible to use URI variables in the default form?
<Henk> Example: {"href":"/{operation}/{name}"}
henk: the ability to use variables would eliminate the need to have form definitions
<Vignesh> operation is specified separately in the form usually right?
ege: we would need to do the mapping between the variable values and elements to substitute in the document
dape: we should be careful with this to identify problems/side effects
ege: we should open an issue
vignesh: in the last example, how do you point to 2 different forms?
ege: you can use the form name inside the form
… you can override the default for example
vignesh: OK
ege: (explains some of the recursion needed in the expansion algorithm)
ege: you can use connections inside a form
ege: you can override the security inline (example)
ege: (explains some invalid constructs)
ege: This may be over-engineered
henk: what about authorization and roles for individual affordances?
ege: it's possible today by using multiple security definitions and including them inline in the affordance
henk: it probably doesn't work for connection oriented protocols
ege: we should open an issue on this
… we might need to use a feature of the protocol
… this can be resolved in parallel with the new feature
vignesh: does nosec need to be specified?
ege: yes, the TD is invalid without it
… the security review result was we should not allow nosec as the default
vignesh: what is we have one security scheme but multiple roles?
henk: yes, this is my point too
ege: it's not clear what we need to add, we should describe it in the issue
… We are out of time now and can continue the discussion later
<Vignesh> great! I can have a look once more and get back
ege: Please let us know what additional feedback you have
<Henk> Thank you!
ege: maybe we can reconvene in 2 weeks
AOB
ege: AOB?
… none, adjourned