Clarify expectations of writing a property

[danielpeintner]

I think the TD spec is currently silent about the expectation of writing properties. Many ideas are floating around

• writing a property returns no value
• writing a property may return a value of type DataSchema
• writing a property may return a value different of type DataSchema (see Philips HUE, currently not describable.)
• ...

see also w3c/wot-scripting-api#193

I think the TD spec ought to be more precise.

[danielpeintner]

Not sure if the discussion in #875 is sufficient. IF so please feel free to close this issue as duplicate of #875.

[relu91]

As I said on call I think this topic should be moved to https://github.com/w3c/wot-architecture where we are defining the WoT Interaction model. For example in this section we are listing and defining the operation types. I would go there and improve the text rather than describe it here.

[benfrancis]

For example in this section we are listing and defining the operation types.

I've been looking for this table! I really think this table should be in the WoT Thing Description specification since it's not just about architecture design, it's defining the semantics of a Thing Description.

[egekorkan]

Ah I was even about to create a PR with that table that is also in the Binding Templates spec :D Thus, +1 to the comment of @benfrancis

[zolkis]

As listed in comment, the TD spec/DataSchema should deal with values precision and eventually step size (it is already dealing with range), for instance this is standard for all CRUDN-capable resources used in OCF.

On a side note, perhaps it would make sense to create TDs for the standard devices listed in the OCF Device Specification, in order to test the TD spec is able to describe those. We should do the same for other protocols as well. Something that could be tested on plugfests.

Then we need use case examples on how actually the return values for writes are used in various IoT protocols. The ones I've seen in OCF:

• just testing equality, which could be encapsulated by implementations
• listing valid options for the interaction, for error resolution - which could be covered by the TD.

I agree the TD spec should clarify the interactions, e.g. if return values are allowed also on writes (arguably should be allowed, since I've seen a lot of swagger files specify return value on "post", all of them also specifying the structure of the return value). So the TD spec should say that a content type and/or DataSchema should be specified if the interaction returns data (it might be already the case, in general terms). But writes should be clarified specifically.

[relu91]

For example in this section we are listing and defining the operation types.

I've been looking for this table! I really think this table should be in the WoT Thing Description specification since it's not just about architecture design, it's defining the semantics of a Thing Description.

Ah I was even about to create a PR with that table that is also in the Binding Templates spec :D Thus, +1 to the comment of @benfrancis

It seems that we had some redundant information in the wrong places 🤣 . Now I am a bit confused, I thought that the Interaction Model is an Architectural concept. Like an interface that is then serialized in a Thing Description.

[egekorkan]

Also see https://w3c.github.io/wot-thing-description/#sec-op-data-schema-mapping. This is still not a full clarification though

[lu-zero]

This covers some aspects that should be part of the whole interaction affordance overhaul.