JSON Schema: unknown keywords

[m-mohr]

Has the planned change in JSON Schema to disallow unknown keywords any effect on OGC APIs?
https://json-schema.org/blog/posts/the-last-breaking-change

I've seen @jerstlouis recently showing some schemas for Coverages (based on Features - Part 5) for example, which included custom keywords and I think I've also seen this in Processes. (We also use it in openEO.)

This is more an issue to make people aware of a potential breaking change coming in once new JSON Schema versions may get adopted.

[cportele]

Read the section "What is being done to soften the blow?"

Currently we use keywords with a prefix "x-ogc-" for custom keywords, but we monitor the discussion and will change that to whatever mechanism the JSON Schema group will decide.

[m-mohr]

I have read it, but the examples I had seen in presentations didn't had the prefix (yet?).
So with the prefix it sounds good.

[cportele]

All custom keywords had the "x-ogc" prefix from the start, so maybe the examples you have seen are incorrect.

See the discussion, which already has the following:

We could use a new keyword to tag that property as the local identifier of the feature (e.g., x-ogc-role: ID). Note that it is very likely that there will be rules for custom keywords in JSON Schema. That is, the keyword will depend on the result of that discussion.

[jerstlouis]

@m-mohr I guess you were talking about observedProperty, observedPropertyURI, uom and uomURI in https://schemas.opengis.net/ogcapi/tiles/part1/1.0/openapi/schemas/tms/propertiesSchema.yaml?

These should probably be prefixed with x-ogc- (I don't recall to what extent we explicitly call this a JSON schema in 2DTMS / Tiles -- for Coverages at least we will want to add the prefix).
I've identified one other annotation required by Coverages so far that I named x-ogc-field-index (mentioned now in https://github.com/opengeospatial/ogcapi-coverages/blob/2023edits/standard/requirements/requirements_class_fieldselection.adoc), to establish the order of the fields since the property names are otherwise unordered as part of a JSON dictionary/object.

cc @joanma747

[m-mohr]

Yes, indeed!

[joanma747]

While I'm completely in favour of extending JSON schema, one can argue that what you see in https://schemas.opengis.net/ogcapi/tiles/part1/1.0/openapi/schemas/tms/propertiesSchema.yaml is not extending JSON Schema. This is actually a JSON schema that defines an object that has no predefined properties but can have extra properties, and all of them shall be objects with a predefined list of properties. Some of these properties are copied from the JSON Schema and some others are "new" and "invented" by us (actually they are copied from Sensor Things API).

Since this JSON schema define how to define the " Attributes of the features or rangetypes of a coverage", you can argue that this is a metaschema and is extending JSON Schema. This is a matter of opinion. If we agree this is a metaschema, then, we would adopt the extension mechanism (the one that is under discussion now).

I'm experimenting with what is suggested by:
https://stackoverflow.com/questions/64138556/how-do-i-define-my-own-json-schema-keyword-and-vocabulary
https://json-schema.org/draft/2019-09/json-schema-core.html#rfc.appendix.D
that allow(ed) to extend the schema and I found it VERY useful. In my opinion, we should defend the capability to extend JSON schema.