AW: [TF-TD] Meeting minutes + Update TD Tutorial

Hello Kajimoto-san,

> But when I tried to create the map between 3 interaction type to get, put APIs to make
> input document for TF-AP, I faced some difficulties.

> In https://github.com/w3c/wot/blob/master/TF-TD/Tutorial.md, the sample “MyLED”
> is described according to proposed interaction model. 
> This is very helpful to understand the TD and discuss issues.

It was also our impression that it is very valuable to actually model a use-case using the agreed WoT Model.
In the mentioned TD, there are some points that due to the simplicity of the example can be expressed in various ways.

> For example, “ledOnOff” belongs to Property, on the other hand “fadeIn” and “fadeOut”
> belong to Action.
>  “ledOnOff” will cause things=LED turn on or off. So “ledOnOff” can belong to Action
> category too, I think.

That is exactly a point where we discussed also.
Some interactions can be expressed both as action or property, such as the ledOnOff.
Where I see others (e.g. switch off after 5 seconds, dim to 20% over the next minute, increase by 10%) that are only expressable as actions.

We will need some guidelines or rules when to use which pattern (it is the same discussion as in Object-oriented programming).

> And current “fedeIn” is defined that it has no return value, that is, OutputData = void/null.
> It is possible to extend the definition as OutputData = Boolean and it represents the return
> Value of fadeIn action is successful or not.

I found it hard to map the return value of an action to a Resource structure or a RESTful protocol, especially for long-running actions.

For an instantaneous behavior I could get an instant response with the Output as you mentioned.

When I call an action that runs over a longer time, I woukd like to get an immediate feedback if my call was placed (if the action is executed). 
On the other hand, as you mentioned, I would like to be informed when the action is finished and if it was successful.
Maybe I even want to cancel/terminate the execution or alter the parameters.

This is why I proposed to create a new (sub-)resource for the execution of an action once it was called.
There I can subscribe an get notified once it is finished.

To generalize, I would even think it makes sense to not only have a Boolean value, but an enum that tells me about the state.
It can be Idle, or running, finished successfully, aborted by a command or even through an error.
In this resource, we can also store information like with what parameters the action was started and at what time etc.

This also enables us to easily have further extensions in the future, e.g. it is even thinkable for the future to provide a progress indicator there (finished x percent).

> TF-TD and TF-AP members, how do you think to resolve my confusion ?

I would like to address this in today's call and have added an agenda item for it.

With Best Regards,
Johannes

Received on Wednesday, 9 September 2015 10:07:16 UTC