Re: What to do with WoT Profiles 1.0

On 25/04/24 19:10, Ben Francis wrote:
> 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).

That's the idea. I'm starting from the concern of people having TD 
consumers that would get very confused by profiles.

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

If that's accepted we have to make it way more evident. Keep in mind 
that dealing with ActionAffordance::output + Form::response + 
Form:additionalResponse is apparently an uncharted territory for enough 

adding a subprotocol to the invoke action form might solve the pressing 
problem since then the consumer would not present the async action.


Received on Thursday, 25 April 2024 17:30:56 UTC