Should there be restrictive profiles of CoverageJSON?

[chris-little]

As JSON and CoverageJSON are very flexible, some user communities feel the need to specify restrictive profile(s) of the OGC Community Standard.
I have said specifically 'restrictive'. Profiles that extend the standard should be addressed by future versions of the standard, such as V1.1, V1.2, V2.0 etc.
V1.x versions would be fully backward compatible with the existing V1.0.
V2.0 etc versions would not be backward compatible.
Corrections of errors will be addressed in V1.0.x versions.

[jonblower]

I support the idea to have restrictive profiles, and in fact there is already one example in the spec of a "standalone" profile, which asserts that all information have to be embedded in a single JSON document, not referenced by URLs: https://opengeospatial.github.io/ogcna-auto-review/21-069.html#toc51

Note that the profile can also be included in the media type.

There is also a specified set of common domain types, which are essentially ways of restricting the use of the Domain object.

[chris-little]

Another possible restrictive profile is to only use WGS 84 CRS.

[chris-little]

I do not think that CoverageJSON 1.0 needs any change to support restrictive profiles, but anyone who wished to create one would need to produce restrictive schema fragments.

Is there a need for some kind of support for this?

[jonblower]

I haven't yet seen a use case that can't be handled by the existing mechanisms, but I can't remember if we had something specific in mind when we raised this ticket?