Wot-thing-description: Type of `enum`, `const`, and `default`

[JKRhb]

At the moment the type for enum, const, and default is "any type" which makes it possible to define a DataSchema like the following which also passes JSON Schema validation:

{
    "type": "string",
    "const": 5,
    "enum": [2.3, "foo", true, ["hi"]],
    "default": {}
}

While I think that this can be useful when no type is given, I was wondering if there should be a constraint added that binds the type of these tree fields to the type of the DataSchema if one is present.

[egekorkan]

This is actually due to JSON Schema specification. What you have is indeed a valid JSON Schema (it validates on online JSON Schema validators) and there are rules on what precedes what that I couldn't find now. The specification also does not specify something specific.
In TD playground, I do some additional checks and the co-presence of enum and const is one of them. If you validate the TD named enumConstContradiction, it will display a warning.

Edit:
P.S. I am writing on JSON Schema Slack channel to understand what the community thinks

[egekorkan]

So the official answer is more or less what I wrote above. They compared it to an unreachable branch in your code like if(false){something}. Apparently, there is an official linter coming up

[JKRhb]

Thank you for investigating this! :) So I suppose an implementation must support modelling a DataSchema like this although it is discouraged? Or would it be acceptable if this was ruled out?

They compared it to an unreachable branch in your code like if(false){something}. Apparently, there is an official linter coming up

I not entirely convinced by this comparison but the linter is very good news :) (The TD validator is very awesome as well by the way!)

[egekorkan]

My opinion on this would be split on what an implementation is:

• TD Parser: I would say that it should not give an error saying that it is an invalid data schema or TD. Some warnings or recommendations (like a linter) should be possible (and encouraged) though.
• Exposed Thing: If the Thing uses an automatic JSON Schema validation for the inputs it gets, all inputs will fail.
• Consumer1: A UI generation use case: The UI will be based on one of the terms or the behavior will not be defined.
• Consumer2: Payload generation use case: https://json-schema-faker.js.org/ generates the constant value of 5 for the schema above. Another generator can behave differently.

After this, maybe we should have a set of recommendations on how to write better TDs :)

[egekorkan]

To go deeper in the rabbit hole: https://github.com/json-schema-org/json-schema-spec/issues/1079

Pretty good list to be honest :)