Re: What to do with WoT Profiles 1.0

As far as I can tell you're suggesting creating a new sub-protocol just for
asynchronous actions in the HTTP Basic Profile, but using binding templates
to solve ambiguities in the HTTP SSE Profile and HTTP Webhook Profile
(where using the subprotocol member is trickier, since it's already in use).

Note that if you look carefully at the action protocol bindings in the HTTP
Basic Profile, they don't actually rely on using the queryaction and
cancelaction op names in forms. The protocol binding just assumes that if a
Consumer gets an ActionStatus object in response to asynchronous action
invocation, it can then perform queryaction and cancelaction operations on
the dynamic action resources linked in an ActionStatus payload. This was a
deliberate design decision so that the queryaction and cancelaction
operations don't need to be explicitly exposed in Thing Descriptions (see
the example Thing Description https://w3c.github.io/wot-profile/#example-4),
which may confuse generic Consumers (the forms wouldn't make sense anyway,
since the URL endpoints are dynamically generated).

I realise that may not feel very neat, but you may be trying to solve a
problem that doesn't actually exist since there may be no forms to add the
subprotocol to (other than the invokeaction one, but the synchronous member
probably differentiates that sufficiently).

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

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