Partial TD validation for input of produce() method

[egekorkan]

Currently, the TD Validation method is used after the expose() method, which makes sense the exposed TD should be a valid TD according to the TD spec. However, the produce() method should specify that there is a certain validation needed for its input. I imagine that this would be a TD template or partial TD but what can be given as input should be specified.

[egekorkan]

Some initial thoughts:

• Not require vocabulary terms that are not required by the TD specification: For example, not requiring description in the root level.
• Not require forms in the root level or interaction level: The forms can be generated by the implementation
• Not require a title: The title can be again generated by the implementation. I think this is not a very important one, but just a thought
• Not require @context: An implementation can insert the default context
• Not require security and securityDefinitions: An implementation can insert default security
• Not specifying other structures for terms defined by the TD specification: For example, forms should be an array, description a string etc. and not another data type.

After this, an empty object becomes a valid input so maybe it should require something. At the same time, it can be thought that an empty object produces a default Thing that can be similar to the Servient Thing of node-wot.

Note: When I say not require, an implementation can still decide to use it.

[zolkis]

Well, the input data for produce() should be a subset of the TD, plus eventually other info that needs standardizing (for instance security initializations etc). However, we will start without the latter.
So we could say it's a non-restricted subset of a TD that however should be valid JSON.

In addition, erroneous input would be just ignored. A script can always check the result by analysing the result of getThingDescription().

[zolkis]

The main point being that it should be different than the "validating a TD" algorithm which is currently used.

[egekorkan]

I think that the word subset might something we don't want to use depending on what it exactly means. I could think of two meanings:

1. A smaller set of defined vocabulary terms and their specified data schema. In this case, we wouldn't specify, for example, how descriptions should look like.
2. Same set of defined vocabulary terms but less restrictive. In this case, we would specify that @context is of a certain type but not required.

I think that the second one is what we want to have. Its validation can be also done easily by simply removing the "required" arrays from the TD JSON Schema. This way, it would be also a rather formal definition and each implementation can force or recommend a superset of this schema-conform TD.

[relu91]

I agree that some kind of validation is possible and I prefer the second point.

After this, an empty object becomes a valid input so maybe it should require something. At the same time, it can be thought that an empty object produces a default Thing that can be similar to the Servient Thing of node-wot.

About this, I think is better not to replicate the same actions and properties of the servient runtime. The default null Thing should just have an id and a name but no action/property/event.

[zolkis]

2. Same set of defined vocabulary terms but less restrictive.

Yes, that is the idea.
Also, note that currently the only way to add interactions to an ExposedThing is via the init dictionary.
We don't have the addProperty, addAction etc methods that take descriptions as arguments, but we construct an object that has the definitions needed to generate all the interactions.

[egekorkan]

The default null Thing should just have an id and a name but no action/property/event.

Just as a note, id term is not mandatory anymore according to the TD spec. However, I think that title term would be a sensible minimum.

[zolkis]

After produce(), things can be in limbo, but after calling expose(), the generated TD must be valid according to the TD spec.

We did standardize that implementations "expand" the init dictionary with terms having a default value in the TD spec (when not specified), and also, all terms that are generated by bindings + local runtime are also expanded. We should indeed enumerate the latter (and provide create algorithms as well). Help is welcome there.

[relu91]

Just as a note, id term is not mandatory anymore according to the TD spec.

Sorry, I miss that.

We did standardize that implementations "expand" the init dictionary with terms having default value in the TD spec (when not specified), and also, all terms that are generated by bindings + local runtime are also expanded. We should indeed enumerate the latter (and provide create algorithms as well).

Maybe a naive solution, but we could use quite the same approach as for the expansion of TD spec. Bindings enumerate the default values (and filling rules if applicable) for their own vocabulary terms, then the implementation of a protocol binding must fill those values. So that we "distribute" the filling process to the specific protocol binding standardization.

[relu91]

I think the situation improved a little bit after #289. However, this issue still contains interesting points:

Just as a note, id term is not mandatory anymore according to the TD spec. However, I think that title term would be a sensible minimum.

The current algorithm does not require a value for title, but it drafts how it could be generated by the runtime. Related issue #300

Just as a note, id term is not mandatory anymore according to the TD spec.

Sorry, I miss that.

We did standardize that implementations "expand" the init dictionary with terms having default value in the TD spec (when not specified), and also, all terms that are generated by bindings + local runtime are also expanded. We should indeed enumerate the latter (and provide create algorithms as well).

Maybe a naive solution, but we could use quite the same approach as for the expansion of TD spec. Bindings enumerate the default values (and filling rules if applicable) for their own vocabulary terms, then the implementation of a protocol binding must fill those values. So that we "distribute" the filling process to the specific protocol binding standardization.

The current spec in 6th step of produce seems to cover the generation of hrefs asking to the runtime possible values. What we are missing is a standard specification in the protocol bindings documents.

[danielpeintner]

Scripting Call 2021-08-02

• @relu91 will take a closer look and open pending issue separately (closing this issue afterwards)

[relu91]

I read through the issue and the spec, I think it is now solved. I opened w3c/wot-binding-templates#121 about how to generate a form given an affordance and a Protocol Template.