Re: WoT Profiles 2.0 - Strawman Proposal

Hi Ben,

As agreed upon separately, we will talk about your proposals on Wednesday. I have prepared the agenda [1] and I propose to spend at least 30 minutes on this topic.

[1]: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#February_14_and_February_15%2C_2024

Best,
Ege

From: Ben Francis <ben@krellian.com>
Date: Monday, 5. February 2024 at 18:43
To: Korkan, Ege (T CED IIS-DE) <ege.korkan@siemens.com>
Cc: Public Web of Things WG <public-wot-wg@w3.org>
Subject: Re: WoT Profiles 2.0 - Strawman Proposal
On Fri, 2 Feb 2024 at 16:40, Korkan, Ege <ege.korkan@siemens.com<mailto:ege.korkan@siemens.com>> wrote:
Thanks for the strawman proposal. I have some overall comments below but is it possible that you join one of the next TD or Binding calls where you present this?

Yes I can currently be available for either the Wednesday or Thursday call this week, please just let me know when it best fits into the agenda.


My comments:

  *   Since there is no good way to describe meta operations, it is not possible have a default as the non-default is not clear. This is not an issue of your proposal though.

When you say meta operations, do you mean operations like readallproperties, queryallactions and subscribeallevents which are aggregations of multiple interaction affordances? It is possible to describe a custom protocol binding for those types of operations in a Thing Description (e.g. custom HTTP methods and headers), so that part of the defaults can be overridden.

However, the approach to aggregating multiple data schemas is currently prescribed (though not very precisely) in the Thing Description specification, and more precisely prescribed in Profiles. Currently there's no way to override those prescribed defaults, so in that sense it's only possible to have a default.

I agree that's a wider issue if you want to more flexibly describe brownfield implementations of those types of operations.



  *   Invokeaction with ActionStatus object needs definitely more thinking since anything we have in this document should be describable in a TD anyways.
As you know, the protocol bindings prescribed in Profiles are not currently limited to what's possible to describe declaratively in a Thing Description. Action queues are the best known example of where this has proven to be necessary because Thing Descriptions are currently not expressive enough to unambiguously describe dynamic resources. There are other examples, such as the finer details of how events are mapped onto Server-Sent Events or Webhooks.

I agree that ideally every default in a protocol binding should also be describable in a Thing Description in a machine-readable way, so that the default can be overridden. If we agree that as a key principle all defaults in a protocol binding document must also be describable in a Thing Description, then if we are to take this approach to Profiles 2.0 either:

  1.  Profiles must be much more limited in what they can prescribe in WoT 2.0, or:
  2.  Thing Description 2.0 must be much more expressive, and more detailed protocol binding documents will be needed, including for SSE and Webhooks
It may end up being somewhere in the middle.

Ben