Re: WoT Profiles 2.0 - Strawman Proposal

Hi all,

Following on from this discussion I have taken the liberty of making a
start on a Profiles 2.0 Use Cases & Requirements document, with a view to
gathering and agreeing on a set of use cases and requirements up-front
before starting work on the next version of the specification
https://github.com/w3c/wot-profile/pull/417

I welcome your feedback and input.

Kind regards

Ben


On Fri, 9 Feb 2024 at 10:30, Korkan, Ege <ege.korkan@siemens.com> wrote:

> 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> 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
>