Re: WoT Profiles 2.0 - Strawman Proposal

On Fri, 2 Feb 2024 at 16:40, Korkan, Ege <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