Re: What to do with WoT Profiles 1.0

On Fri, 26 Apr 2024 at 10:04, Luca Barbato <luca.barbato@luminem.it> wrote:

>
> I think Daniel has a practical case,


I would be very interested to see a test case. Since this currently seems
to be holding up work on profiles, I hope that someone from Siemens will
come forward with a concrete example of what breaks so that we can try to
fix it.


> meanwhile I discussed with
> Cristiano and scripting-api right now does not cover
> response/additionalResponse so a consumer implementing scripting-api
> would have difficulties.
>

I don't think we should be blocking anything on the informative Scripting
API but, until an action queue or dynamic resources are modelled in
JavaScript, such Consumers (i.e. node-wot) should still be able to fall
back to basic functionality ("fire and forget" as you call it below).


> ActionAffordance::output is missing,
> Form::response is missing,
> Form::additionalResponses is missing,
>

They're not missing, they're intentionally omitted. One of the main
benefits of profiles is that these kinds of details do not need to be
described in detail in a Thing Description since they are standardised in a
fixed protocol binding. This example action has no output, but for actions
that do have an output the synchronous member being set to false should be
enough to tell a Consumer not to expect the output in the response to the
invokeaction request. The profile fills in the details of responses for
conformant Consumers, and non-conformant Consumers should be able to fall
back gracefully to basic "fire and forget" functionality.


>
> I consider the lack of DataSchema "anything goes", other consider it
> "expect nothing".
>

> Either way you could present it with a fire-and-forget action.
>
> > Perhaps just making it mandatory to set the synchronous member to false
> > for asynchronous actions would actually solve the problem.
>
> If would make the action excluded by Consumers only considering
> synchronous actions, but consumers mapping asynchronous actions as
> "fire-and-forget" might just happily invoke and then report an error if
> they get a success response with a payload they do not expect.
>

Since there are currently no default responses specified in the HTTP
protocol binding template, I would suggest that a Consumer should not be
generating an error for any HTTP success response. If the synchronous
member of the ActionAffordance is set to false, they also shouldn't be
trying to validate the response against an output data schema.


>
> And we are going back to not having any guidelines in the specs
> regarding degraded consumption...
>

I agree this could be improved.

Ben