Part 5: OGC API - Common - Part 2 "Schemas" req.class Syncing

[jerstlouis]

As previously discussed in the SWG, here is the feedback from the OGC API - Common - Part: Geospatial Data "Schema" requirement class integration.
Sorry for the late feedback, but I hope this can still be considered as a response to the RFC.

This Pull Request aligns with the initial changes we made for the OGC API - Common - Part 2: Geospatial Data Schemas requirement class:

#953

The two main changes in this PR relate to being able to describe the meaning of enumeration values and nil values.
It also reference QUDT in general instead of units specifically, since QUDT can also be used for x-ogc-definition.
The remaining changes are mostly grammatical / editorial.

This PR only affects the first section 7 - Schemas of Features Part 5.

I've also just integrated the Core Roles, Returnables, Queryables and Sortables in this commit:

opengeospatial/ogcapi-common@11d6bfd

opengeospatial/ogcapi-common@11d6bfd#diff-3e75532a213bcba1f4d083a089ebc2dc5217a3f743e1950b6c4767f14d4195ec

currently organized into:

clause_14_schemas.adoc

and

requirements_class_schemas.adoc

I will likely re-organize the files into individual requirement files to follow how things are organized elsewhere in Common.
The version in this specific commit might be easier to compare with.

The approach I took here was to merge requirements into separate parts of single requirements for brevity, and to merge Schemas, Core Roles, Returnables, Queryables and Sortables into a single "Schemas" requirement class for Common - Part 2.

At least for Common I think this is simpler, and there is not really a need to clients to declare conformance to these things separately. I believe the occurence (or not) of the associated specific properties or link relations really is enough to know that these things are supported by the implementation.

There are no functional changes in this version integrated into Common - Part 2 (other than the different conformance class URIs). I made few changes in these sections, except replacing some mentions of "feature" or "resource" with the broader concept of data. In several OGC APIs, there is not a one-to-one correspondence with what is being filtered and web resources.
For example, the individual cells of a gridded coverage, or data tile, or DGGS zone data, do not correspond to web resources.

I also did minimum rephrasing of the requirements to highlight the fact that an implementation conforming to the Schema requirement class does not necessarily have a Returnables, Queryables and Sortables by putting a condition in front of the associated requirements.

cc. @pvretano @cportele

The latest draft now reflects the updated Schemas requirement classes with everything:

https://docs.ogc.org/DRAFTS/20-024.html#rc-schemas