[consumed-thing] Op values are not filled with defaults in properties

[jak0bw]

When consuming a Thing Description the op values are not properly filled for a property. Example is below.

1. I consume a simplified version of TestThing with only bool property.

{
    "id": "urn:dev:wot:org:w3:testthing:lyon2018",
    "title": "TestThing",
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "@type": "Thing",
    "security": [
        "nosec_sc"
    ],
    "properties": {
        "bool": {
            "title": "true/false",
            "type": "boolean",
            "readOnly": false,
            "writeOnly": false,
            "observable": false,
            "forms": [
                {
                    "href": "http://plugfest.thingweb.io:8083/TestThing/properties/bool",
                    "contentType": "application/json",
                    "op": [
                        "readproperty",
                        "writeproperty"
                    ]
                }
            ]
        }
    },
    "securityDefinitions": {
        "nosec_sc": {
            "scheme": "nosec"
        }
    }
}

When I do writeProperty() everything works as expected.

2. When I remove readOnly, writeOnly, observable, they are inserted by default. When I do writeProperty()everything works as expected.
3. When I remove the whole op array and do writeProperty() everything works as expected. However when I inspect the Thing Description after consumption the op values are not inserted per default.
4. The real problem is the op insertion. If I remove only writeproperty from the op array, writeProperty() fails.
   The Thing Description that fails is the following:

{
    "id": "urn:dev:wot:org:w3:testthing:lyon2018",
    "title": "TestThing",
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "@type": "Thing",
    "security": [
        "nosec_sc"
    ],
    "properties": {
        "bool": {
            "title": "true/false",
            "type": "boolean",
            "readOnly": false,
            "writeOnly": false,
            "observable": false,
            "forms": [
                {
                    "href": "http://plugfest.thingweb.io:8083/TestThing/properties/bool",
                    "contentType": "application/json",
                    "op": [
                        "readproperty"
                    ]
                }
            ]
        }
    },
    "securityDefinitions": {
        "nosec_sc": {
            "scheme": "nosec"
        }
    }
}

The TD Spec here defines default values for op. I think op should always be generated and in case of missing elements should be filled according to the default value definitions.

[danielpeintner]

There might be some inconsistency in when default values are added.... I will try to take a look at it.

Having said that, I don't think a WoT runtime like node-wot is required to add default values in general.
Any opinions @sebastiankb @egekorkan @relu91. Shall we try to add them whenever possible?

[egekorkan]

The TD spec says: "When assignments in a TD are missing, a TD Processor MUST follow the Default Value assignments expressed in the table of § 5.4 Default Value Definitions." So I am guessing that node-wot as a TD Processor MUST add the values.

Related to this, the Scripting API spec says:

To create ConsumedThing with the ThingDescription td, run the following steps:
Run the expand a TD steps on td. If that fails, re-throw the error and abort these steps.
Let thing be a new ConsumedThing object.
Let |td| be an internal slot of thing and let td be its value.
Return thing.

And expanding is defined as:

Note that [WOT-TD] allows using a shortened Thing Description by the means of defaults and requiring clients to expand them with default values specified in [WOT-TD] for the properties that are not explicitly defined in a given TD.

To expand a TD given td, run the following steps:
For each item in the TD default values table from [WOT-TD], if the term is not defined in td, add the term definition with the default value specified in [WOT-TD].

Since the op is there (defined) but its values are incomplete, node-wot could be considered spec compliant when op is already present. However, the op is still not generated when it is not there at all, thus making it not in-line with the spec.

[danielpeintner]

The TD spec says: "When assignments in a TD are missing, a TD Processor MUST follow the Default Value assignments expressed in the table of § 5.4 Default Value Definitions." So I am guessing that node-wot as a TD Processor MUST add the values.

Note: I am not arguing whether it is useful that node-wot should add the defaults. We should do so since we do it for other default values also.

However I don't think that any implementation needs to add these default values. What would be the idea of having them in the first place if they NEED to get added. My take on this is that IF there is no value the default values kicks in for any processing. The reason to NOT HAVE them is manifold:

• reduced data exchange (TD more compact)
• simpler to see non defaults
• avoiding to exchange knowledge that is default anyway

So I am still not sure whether our understanding of the TD spec (or the wording) is misleading. As said, if everyone needs to add it its is useless to have them in the first place..

[danielpeintner]

back to the actual problem...

3\. The real problem is the op insertion. If I remove only `writeproperty `from the op array, `writeProperty()` fails.
    The Thing Description that fails is the following:

Mhh, the reason why writeProperty() fails is that the op array (which is NOT the default op that would be inserted) defines that there is only the op "readproperty".

Our current take is that IF there are op fields they need to be complete.
I see in the TD spec that for PropertyAffordance there needs to be "Array of string with the elements readproperty and writeproperty". According to my understanding the defaults kick in ONLY if there os no op at all? Isn't that the idea?

[egekorkan]

According to my understanding the defaults kick in ONLY if there os no op at all? Isn't that the idea?

I think that this is something that needs to be discussed with the TD task force. @sebastiankb what do you think?

[danielpeintner]

According to my understanding the defaults kick in ONLY if there os no op at all? Isn't that the idea?

I think that this is something that needs to be discussed with the TD task force. @sebastiankb what do you think?

Maybe I am misunderstanding something here but IF you expect runtimes to add "writeproperty" to op arrays that contain only "op": ["readproperty"] I wonder how a user can specify that a property should be read only?

[egekorkan]

After thinking for a while, I think that if op exists it should not be filled. Some examples:

            "forms": [
                {
                    "href": "http://plugfest.thingweb.io:8083/TestThing/properties/bool",
                    "contentType": "application/json",
                    "op": [
                        "readproperty"
                    ]
                },
                {
                    "href": "http://plugfest.thingweb.io:8083/TestThing/properties/bool/observable",
                    "contentType": "application/json",
                    "op": [
                        "observeproperty"
                    ]
                }
            ]

In this case, the second form's op would be filled with readproperty and it would be simply wrong to do that since no handlers exist behind that href. I can think of many other cases as well.

I think what needs to be clarified is what should the scripting runtime do if the interaction has readOnly:true but no op with writeproperty at all. This should at least be an invalid TD from the Scripting API point of view since it would mean that the developer needs to look into the forms to understand that the property is actually not writable.

[danielpeintner]

I think what needs to be clarified is what should the scripting runtime do if the interaction has readOnly:true but no op with writeproperty at all. This should at least be an invalid TD from the Scripting API point of view since it would mean that the developer needs to look into the forms to understand that the property is actually not writable.

Is this a consequence for node-wot, the scripting API or the TD specification?

As mentioned before my opinion is that once op field is set/provided (in one way or the other) in a TD node-wot should not modify it. Having said that, only if no op is available in a TD node-wot should fill in defaults. Flags like readOnly and observable are like hints according to the spec... this seems a bit fuzzy...

[relu91]

As mentioned before my opinion is that once op field is set/provided (in one way or the other) in a TD node-wot should not modify it. Having said that, only if no op is available in a TD node-wot should fill in defaults

+1 I think the default filling mechanism should be as stupid as possible without trying to predict what a developer wants.

[egekorkan]

After thinking for a bit, I think that op value, if it exists should not be changed. The issue can be somewhat closed but I think that the TD is not filled with default values but another assumption mechanism is used to send the requests. Having the actual TD that is used for sending the requests would be also helpful for debugging purposes.

[danielpeintner]

I read the following statement ;-)

The issue can be somewhat closed

Please re-open or comment if we can do anything further..