Ambiguous meaning of queryaction

[egekorkan]

After seeing the discussion at w3c/web-thing-protocol#43 , I have realized that we are not clear about the meaning of queryaction. Is it querying the action affordance's state in the (physical) world or is it querying the invokation request? The first one would be always return the same for all Consumer asking at the same time. The second one means the existence of a queue where each Consumer need to supply an id that they know somehow (possibly through the invokation request).

[benfrancis]

@egekorkan wrote:

I have realized that we are not clear about the meaning of queryaction. Is it querying the action affordance's state in the (physical) world or is it querying the invokation request?

There has always been ambiguity as to whether a queryaction operation queries a single instance of an action or multiple instances of an action. For example, if a Consumer invokes the same action twice in quick succession, which instance does queryaction provide the status for? The first one, the second one, or both? Can a Thing support multiple instances of an action (concurrently or in a queue), or only one instance at a time? This was discussed at length (e.g. in #302 and in particular #1200 where I suggested separate operations were needed for querying a single instance vs. all instances of a single action) but unfortunately those issues were closed without a resolution.

This is also an issue for cancelaction. Does it cancel one instance of an action or all?

I don't think the distinction is necessarily physical state vs. status of a request, because if a Thing can support multiple instances of an action concurrently then they may be the same thing.

From w3c/web-thing-protocol#43:

Currently, in the Thing Description specification:

• There is no way to specify the response payload of a queryaction operation in a TD, or any explanation of what an action "status" might contain
• There is no distinction between an action and an instance of an action, where multiple instances may be requested concurrently or in a queue
• There is no mechanism to identify an individual instance of an action (vs. just an action name) to query or cancel
• There is no mechanism to enumerate multiple concurrent or queued instances of a particular action

@egekorkan wrote:

The first one would be always return the same for all Consumer asking at the same time. The second one means the existence of a queue where each Consumer need to supply an id that they know somehow (possibly through the invokation request).

I think whether a Consumer can query the status of an action invoked by another Consumer using different authentication credentials is another orthogonal question. Even in a single user system there is still the issue of a single instance vs. multiple instances of an action.

See also: #1408, #2068.

Ultimately I think in order to describe physical devices in the real world there is a need to support multiple instances of an action. E.g. sending multiple print jobs to a thermal printer in a queue, invoking a series of movements to be carried out by a robot arm, or printing multiple 3D objects at the same time using an IDEX extruder.

[hspaay]

@egekorkan, this is a great example why if the TD describes a queryaction operation it should also describe the expected input and output of that operation. (this goes for all operations).

Without it:

• the meaning of operations will remain ambiguous
• consumers will not have the same information available depending on the protocol used
• every protocol must reinvent the wheel in defining the relevant payload, eg ActionStatus
• every consumer developer must implement different types for the payload, eg ActionStatus. Note that client most likely has to support multiple protocols in order to talk to different devices

I would love to see this addressed as part of TD-2.0.