Wot-thing-description: Default value for op in Property Affordance should be linked to read/writeOnly

[egekorkan]

Currently the spec says in https://w3c.github.io/wot-thing-description/#x5-4-default-value-definitions that the op gets the default value of ["readproperty","writeproperty"]. However, this is true only in the case of a readOnly or writeOnly property. Thus, I propose that the text should be changed from:

Array of string with the elements readproperty and writeproperty

to:

Array of string with the elements readproperty and writeproperty when readOnly and writeOnly are set to false OR Array of string with the element readproperty if readOnly is set to true OR Array of string with the element writeproperty if writeOnly is set to true.

This does make it more complicated because it actually is. Once one tries to make a defaults generation algorithm, this becomes important. It would be relevant for scripting as well.

This is coming from this PR in the Playground: https://github.com/thingweb/thingweb-playground/pull/156#issuecomment-727911019

[danielpeintner]

Mhh, not sure if this is necessary. The text reads

the op gets the default value of ["readproperty","writeproperty"]

Doesn't that imply that the value is set ONLY IF op is undefined?

Moreover, readOnly and writeOnly are hints and I am not sure if those values should drive op.

[egekorkan]

Doesn't that imply that the value is set ONLY IF op is undefined?

Yes this is true. It should be set if it is undefined but there is a dependency.

Moreover, readOnly and writeOnly are hints and I am not sure if those values should drive op.

Exactly, that is why if the values of op are generated but are generated wrongly, they would overwrite the meaning conveyed by readOnly and writeOnly. Thus, they should be generated correctly in the first place. The hint statement is valid if there is already an op value.

[sebastiankb]

I'm agree with @egekorkan . Lets assume there is a property with readOnly=true and without writeOnly and op information. Then a TD processor would follow the default table and assumes writeOnly=false and op=["readproperty","writeproperty"]. This leads to a contradiction.

Thus it makes sense, that the op follows the hints writeOnly and readOnly when otherwise no other information are given.

[sebastiankb]

@egekorkan will provide a PR and will check if there some other places in the spec which needs this clearification