danielpeintner
commented
4 years ago Safety conditions could be TD templates (e.g. expressed as JSON-LD frames), to constrain TDs to be consumed by the script. If consumed TDs do not match the template, an error could be thrown.
@vcharpenay I wonder whether the requirements of a script w.r.t. a given TD (or as you call them safety conditions) are meaningful on the scripting API level only.
I think the same requirements (e.g., having a TD or a thing with the actions turnOn and turnOff) are meaningful for pure binding-protocol solutions also. Even in the case of HTTP (without any scripting in place) it looks necessary to me that a given set of actions is available for the desired solution to work.
Note: I think the issue of finding the right interactions no matter whether an action is called on or turnOn is solved by semantic extensions already. The missing part to me is a simple way to check whether a TD in general fulfills are requirements.
Having said that, it seems we should bring the safety conditions to the TD task force as well. What do you think?
Many WoT scripts on the client side are likely to be reusable across applications, in a similar fashion to Node-RED modules. For instance, control loop between sensors and actuators (temperature sensor vs. thermostat, brightness sensor vs. light switch, flow sensor vs. pump, etc.) could be implemented generically and instantiated for specific Things.
Standardizing a module mechanism for WoT would seem redundant with e.g. ES6 Modules. However, a way to annotate scripts with safety conditions may be an interesting feature. Safety conditions could be TD templates (e.g. expressed as JSON-LD frames), to constrain TDs to be consumed by the script. If consumed TDs do not match the template, an error could be thrown.
See also my position statement at the 2019 WoT workshop.