fix(InteractionOutput): don't require schema.type in value function

[JKRhb]

At the moment, the value function of the InteractionOutput interface requires the type field of its schema to be set. In a discussion over at https://github.com/eclipse-thingweb/node-wot/issues/1221, we identified this as a problem for several different scenarios, including the exloreDirectory method, as the things property of the Thing Description Directory API specification does not contain a type field itself, as there are two different types that can be obtained from the property (namely, an array or an object of TDs).

Therefore, this PR proposes changing the algorithm to not throw anymore when the field should be null or undefined, making it usable in more scenarios.

---

Preview | Diff

[JKRhb]

Very good points, @relu91, thank you. You are right, this definitely requires more work, especially when it comes to the "check data schema" algorithm. Could we maybe refer to something already defined by JSON Schema here?

[relu91]

Call 05/02:

• @JKRhb relates to the todo item of DataMapping, so that's why it is hard to fix without knowing the result of the discussion
• @danielpeintner we can try a best-effort approach and suggest proper schema validation in an Editor's note
• @relu91 agrees, we can modify the algorithm to support the following keywords that are defined in the TD:
  1. oneOf
  2. const
  3. enum
  4. default ? (related to https://github.com/w3c/wot-scripting-api/issues/537)
• @ashimura It would be important to describe the use cases of each one of these keywords. @relu91 I agree let's open an issue before merging this PR.

[JKRhb]

I've now tried to incorporate oneOf, enum, default, and const into the check data schema algorithm in 0f00764cce6f813ba8c168bab682eef1d6791037. There are at least two aspects of the algorithm that we could discuss in the call later today – I marked these with TODO comments in the HTML document.

[JKRhb]

Edit: This comment has been moved to https://github.com/w3c/wot-scripting-api/issues/546

Regarding the use cases, please find a brief first attempt (that definitely needs more work) for the four terms below:

oneOf

Relevant when a device described by a TD offers two different representations of the same resource (e.g., a property or an action output). A concrete example is the things property in the Thing Description Directory API, where – depending on the URI variable format – the directory can return TDs either as an array or a "collection", i.e. as part of a JSON object.

const

As a developer, I might want to specify that a Thing always returns a certain value when an action is performed. A simple example could be a value like "Success". Combined with oneOf, we could describe that an interaction (in this case an action) always either returns "Success" or "Operation failed" like so:

{
  "actions": {
    "exampleAction": {
      "output": {
        "oneOf": [
          {
            "const": "Success"
          },
          {
            "const": "Operation failed"
          }
        ]
      }
    }
  }
}

default

As a developer, I want to save bandwidth, especially in resource-constrained environments. Therefore, I want to be able to specify a default value that has to be assumed by a TD consumer if the response sent after an operation has been completed does not contain a value.

enum

As a developer, I want to constrain the values that are valid as an interaction output to a set of values. This could be used to describe the allowed states of a smart light ("on" or "off"), for example.

[relu91]

Call 19/02:

• @ashimura we need to gather more implementation feedback because the issue might be related to other problems in different specifications.
• @relu91 I agree but for now I would prefer an iterative approach and fix the issue with what we know ( we can keep https://github.com/w3c/wot-scripting-api/issues/546 to continue the discussion).

[relu91]

From 04/03:

• @relu91 changes look good (+1 for removing default), they might not be perfect but they can refined later
• @danielpeintner approves the changes