Meeting minutes
HTTP Binding refactor
Ege: The HTTP Binding historically was part of the main TD spec
Ege: Going with the Registry approach, it is not needed anymore
Ege: This pull request addresses it
<EgeKorka_> wot-binding-template PR 380 - HTTP Binding to TD Alignment
Ege: There are few open questions
[[ TD mentions the default inclusion of the HTTP vocabulary in the TD Context. We need to discuss if we should continue doing this. ]]
[[ TD has an assertion (but not RFC!) saying In the case of a forms entry that has multiple op values the usage of the htv:methodName is not permitted. This should be turned to a real assertion in binding and also should be mentioned in a generic way in the binding registry as it applies to all protocols. This also has a corresponding interactive
example. ]]
<EgeKorka_> WoT Thing Description Eitor's Draft - Example 59
Ege: In the TD we have an example showing how to deal multiple `op`s when methodName has to be specified
Luca: Shall we address this problem now, since it is general and would be good to have a vocabulary term for this on its own since for each protocol we have `method` or equivalent?
Ege: If we have consensus we could agree to add the assertion to the main TD document
Ege: Anybody wants to not make it as a generic assertion?
Luca: I'd go further and surely make a full paragraph to clearly explain the problem and possibly solve the underlying issue regarding multiple ops
Kaz: The PR moves the whole section around "Protocol Binding based on HTTP" from the main TD document?
Ege: Right
… but not as-is
<shows the PR summary>
Ege: Any concerns?
<None>
Ege: I'd leave it open for some more days since it was created 2 days ago
Initial connection
<kaz> TD.Next Usability and Design Work Items
<kaz> wot-thing-description PR 2040 - Initial/Common Connection Container Proposal
<kaz> Rendered version of the proposed updates
Ege: I'd like go further on this
Ege: There are two proposals, mine and Luca's, they are similar
Luca: I tried to make so ideally we could make so the security scheme logic is deduplicated
Luca: I propose to have Forms::base to refer to other forms for Defaults and then Thing::bases acts as container for the default forms, even the default forms can refer to others
Luca: Then I propose to have similar containers for defaults in the Thing for connection setup information (protocol-binding specific) and for protocol setup information if they are different from an actual connection, but probably we can have just one.
Cristiano: With this mechanism, we could call it formDefinitions to match security
Cristiano: With design we are still forced to still to declare a form for the affordance
Luca: Yes since we need at least a different href
Cristiano: Also do we have a way to tell which is the form Default
Luca: We can use the same pattern used with security, so a Thing::base or a Thing::formDefault
Cristiano: Aside decided on the names, we can experiment with it during the plugfest
Cristiano: I prefer consistent naming though
Ege: I'm unsure about the compositionability
Luca: It comes almost for free by defining Forms only once
Cristiano: We could have the problem of circular references so the implementation has to care about this
Ege: We are now at the end of the meeting <Updates the issue with a summary>
<kaz> [adjourned]