Re: What to do with WoT Profiles 1.0

On Thu, 25 Apr 2024 at 14:44, Luca Barbato <luca.barbato@luminem.it> wrote:

> The more I'm pondering about it and the more I think we can consider
> Option 1 plus "profiles bring in vocabulary terms so consumers not
> supporting that specific profiles do not have ambiguities since they
> would have to reject the forms as they would for protocols they do not
> support".
>

> Ideally we could get away by being very specific in the terms used for
> subprotocol.
>
> This way TD 1.1 properties can be consumed by any TD 1.1 consumer,
> actions and events that need the knowledge of a profile to be correctly
> consumed would be ignored since they sport a subprotocol term provided
> by the specific profile.
>

Using sub-protocols imported via semantic contexts was actually my initial
proposal for WoT Profiles 2.0, see
https://github.com/w3c/wot-profile/issues/285#issue-1373129843

The downside of that approach is that it results in *less* interoperability
by default, because a non-conformant Consumer has to ignore forms using a
sub-protocol it doesn't support, despite the fact that if it just followed
existing defaults all the basic functionality would work.


> I think
> the consensus so far is that:
> - we want profile 1.0 work to be wrapped up fast to the point it can be
> used no matter how reduced is the set of capabilities as long it is more
> than TD 1.1 alone.
>

I agree in principle, but I would like to see a concrete proposal for what
actually needs removing and what would be left.


> - we cannot release something that would force consumers to reject
> completely a TD if it signals a profile that is not supported.
>

I'm not convinced this is really the case today:

   - Reading and writing properties and invoking actions in the HTTP Basic
   Profile are already consistent with the defaults in the Thing Description
   and Binding Templates specifications, the profile just builds on those
   defaults in a compatible way.
   - Observing properties and subscribing to events using Server-Sent
   Events are also likely to work with a generic Consumer which implements
   SSE, though in the absence of a Server-Sent Events binding template some
   details are ambiguous.
   - Querying and cancelling actions will not work at all without knowledge
   of the profile, but I've not actually seen any examples of this working
   without profiles (certainly not with multiple instances of the same action
   at a time) and there is already ambiguity about how to map data schemas for
   action responses, so I'm not sure much is lost there.
   - Webhooks are unlikely to work without knowledge of the HTTP Webhook
   profile, but again describing Webhooks without a profile requires a lot of
   hacks which are very unlikely to work cross-vendor.

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.

My suspicion is that Consumers which implement profiles only support Things
which implement profiles, and Things which use binding templates (doing
anything non-trivial, outside of the defaults) will only work with
Consumers written by the same vendor which have advance out-of-band
knowledge of the Things they are consuming. I would like to be proven wrong.

Ben