New JSON Schema Version will ban unknown words

[egekorkan]

After reading https://json-schema.org/blog/posts/stable-json-schema and the linked architectural design record at https://github.com/json-schema-org/json-schema-spec/blob/main/adr/2023-04-sva-prefix.md , we will have to consider using newer JSON Schema versions. Basically, any keyword that is not defined by JSON Schema standard MUST be prefixed with x-. This is a problem in two levels:

1. properties' data schema is mixed with our keywords. So the forms would not be allowed. We can avoid this by putting property data schema into a data keyword
2. All semantic annotations within JSON Schemas will not work... Anything that has @type, prefix:myword or other such terms will not be allowed in JSON Schema libraries. The only way around it is to require a "cleaning" step before the current TD scope is passed to a JSON Schema validator. Maybe there would be some libraries that can help with this but we may need to formally specify this.

[lu-zero]

I'd accept we cannot use jsonschema anymore, we already will have to deal with it not able to describe formats like cbor or msgpack already.

[danielpeintner]

Some thoughts:

• Can we stick with older JSON schema versions (at least for some time)? Time often shows the right way to proceed ;-)
• Does it make sense to get in touch with JSON schema folks to highlight this problem. I am pretty sure we are not the only ones. Maybe JSON schema people could be convinced to add a global flag whether such strong checking can be turned off.
• I wonder what happens to additionalProperties keyword?

[egekorkan]

Can we stick with older JSON schema versions (at least for some time)? Time often shows the right way to proceed ;-)

Definitely :) I do not see a pressure to move to the new ones. Might be something for TD 3.0 even.

Does it make sense to get in touch with JSON schema folks to highlight this problem. I am pretty sure we are not the only ones. Maybe JSON schema people could be convinced to add a global flag whether such strong checking can be turned off.

I am talking with @gregsdennis on JSON Schema Slack.

I wonder what happens to additionalProperties keyword?

That stays but it won't help us exactly. We have issues in the schema definition level and not in the key definitions level. Our forms keyword is like a validation or annotation keyword for JSON Schema that is unknown.

[gregsdennis]

It's important to note (and I didn't in the blog post because it would have been confusing) that implementations can still support custom keywords. You're not limited to just the keywords defined by the spec.

The language in the WIP spec is here.

Basically, the requirement is based on whether the implementation understands the keyword. If not, then the implementation MUST NOT process the schema. So if you can register a custom keyword that does what you want (or nothing), then you're all good. Also, there's nothing stopping an implementation from having a configuration setting that allows unknown keywords; but that MUST NOT be the default behavior.

This means that you'll need to get whatever implementations you use to support what you need.

[benfrancis]

@gregsdennis wrote:

if you can register a custom keyword that does what you want (or nothing), then you're all good.

What does "registering a custom keyword" involve?

Note that x-@type would not be valid JSON-LD. E.g. in Example 47 from the WoT TD 1.1 W3C Recommendation.

Wrapping the JSON Schema of a PropertyAffordance in a data member like EventAffordances have could solve this at the top level, but not at any other level (e.g. sub-properties).

[gregsdennis]

What does "registering a custom keyword" involve?

This will be different per implementation. Here are my docs for JsonSchema.Net: https://docs.json-everything.net/schema/vocabs/#schema-vocabs-custom-keywords