Re: What to do with WoT Profiles 1.0

On 25/04/24 16:39, Ben Francis wrote:
> On Thu, 25 Apr 2024 at 14:44, Luca Barbato < 
> <>> 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 
> profile/issues/285#issue-1373129843 < 
> 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.

read/write property operations would stay unmarked, we'd have the 
subprotocol marking the async invoke, query and cancel.
Thing-operations would need the subprotocol as well since those also 
might confuse a non-profile consumer.

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

And those would not need a subprotocol as long the actions are synchronous.

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

We need to provide a binding template.

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

I have the same expectation.

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

We'd need a binding template for it as well

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

I guess much depends on what bindings are we referring to, but we are 
returning to the point for which I think we need strong consensus:

- A profile is still using @context to extend the TD (so we have to 
provide an ontology per-profile)

- A profile may define terms within itself and refer to binding templates.

- The consumer may rely on the profile keyword alone to decide how much 
to instantiate beforehand (and reject anything outside the bare-td + 
profiles it supports) (useful for non-ld consumers)

- The consumer not supporting a profile has an easy way to exclude forms 
coming from that profile.


Received on Thursday, 25 April 2024 16:22:41 UTC