Re: What to do with WoT Profiles 1.0

We are at a very late stage in WoT Profiles 1.0 to make such a drastic
change to how they work and introduce completely new ontologies,
effectively rendering all existing implementations obsolete.

Unless we are intending to use the semantic contexts + subprotocol approach
for Profiles 2.0 (which I thought we had already ruled out, but that's
obviously still up for discussion), I don't think it's worth investing the
effort in making such a big change, only to change direction again for
profiles 2.0.

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

> On 25/04/24 16:39, Ben Francis wrote:
> > On Thu, 25 Apr 2024 at 14:44, Luca Barbato <luca.barbato@luminem.it
> > <mailto: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 <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.
>
> 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.
>
>
> lu
>