Re: What to do with WoT Profiles 1.0

Hi Ben and Luca,

I have tried to catch up but there is simply too much to read through. I am pasting some points raised, along with some other points and answering them below. I think such discussions should be done in a more structured fashion.


  *   In the previous calls, there was preliminary consensus on not using profile as a patch mechanism for mechanisms that we cannot describe now in the TD. Also, along the same lines, no profile should bring implicit mechanisms (sometimes referred to as extending the td spec but I think this is not a correct wording).
  *   Any mention of ambiguity means a lack of expressiveness in the TD spec, thus should be solved there first. The TD TF is aware that there are a lot of things to do and we are working on structuring the work and prioritizing work items.  Metaoperations is a can of worms and we will handle that in this charter. Any suggestions on that would be nice. Along with manageable actions.

Ben wrote
What would be helpful would be some real life testing of generic Consumers (does one actually exist?) against Things which implement profiles, to provide evidence of reduced functionality compared with a Thing using binding templates.

We don’t say a generic consumer but a consumer implemented in a generic way. node-wot and many other implementations are like that. It is just architecturally annoying to implement another stack to handle profiles that add their own stuff. I feel that this point is just never understood by the profile TF or I feel it is kept getting ignored.

Ben wrote
As far as I can tell, the current profiles only add functionality for conformant Consumers, they don't take functionality away for non-conformant Consumers.

We have presented the case against this with node-wot many times.

Ben wrote:
We are at a very late stage in WoT Profiles 1.0 to make such a drastic change to how they work and introduce completely new ontologies, effectively rendering all existing implementations obsolete.

Other than WebThings, which was sort of profile compliant before the profile spec anyways, the example implementation from Oracle and the new one I have heard from Luca, there are no other implementations. WebThings implementations should be describable in TD 2.0 and there should be no need to change it. No implementation should be required to change to fit WoT in general, at least for Things.

Ben and Luca wrote:

Luca: That's the idea. I'm starting from the concern of people having TD
consumers that would get very confused by profiles.

Ben: Is there any evidence this actually happens in practice, or is it just a theoretical concern?

Yes, there has been the case in Siemens with early adopters. I can provide more details in a meeting. Mizushima-san also expressed similar concerns in this week’s call.

There are many open points in WoT and we should work on resolving them. Hope to see you in one of the next WG calls.

Best,
Ege

From: Ben Francis <ben@krellian.com>
Date: Friday, 26. April 2024 at 16:59
To: Luca Barbato <luca.barbato@luminem.it>
Cc: public-wot-wg@w3.org <public-wot-wg@w3.org>
Subject: Re: What to do with WoT Profiles 1.0
On Fri, 26 Apr 2024 at 10:04, Luca Barbato <luca.barbato@luminem.it<mailto: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