Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should schema.type be always defined? #546

Open
relu91 opened this issue Feb 19, 2024 · 0 comments
Open

Should schema.type be always defined? #546

relu91 opened this issue Feb 19, 2024 · 0 comments

Comments

@relu91
Copy link
Member

relu91 commented Feb 19, 2024

TODO: introduce better the problem @JKRhb

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.

Originally posted by @JKRhb in #534 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant