Re: What to do with WoT Profiles 1.0

The only example I can find of a response a profile-conformant Thing might
produce which a generic Consumer wouldn't understand (and could reasonably
be expected to understand if it was using a binding template instead), is
if a Consumer of a Thing using the HTTP Basic Profile invokes an action
with a POST request and gets an ActionStatus object (
https://w3c.github.io/wot-profile/#ActionStatus) in the body of the
response instead of an action output. But that can quite easily be fixed by
just setting the synchronous member to false (currently the profile says
that if the synchronous member is undefined it may respond either
synchronously or asynchronously, but maybe that isn't constrained enough).

A top level form with a queryallactions operation is probably not going to
be understood by a generic Consumer, but as far as I can tell the use of
that operation with binding templates is completely unspecified so I can
only assume a generic Consumer would ignore it anyway.

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.

On Thu, 25 Apr 2024 at 15:39, Ben Francis <ben@krellian.com> wrote:

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