Changes to API-Common Part: 2 Collections (GeoData)

[chris-little]

Do we want or need to change OGC API-EDR Part 1: Core V1.2 to follow the proposed approach to managing the OpenAPI building blocks used in Tiles, Maps, Coverages, DGGS, Processes and now being adopted for Common - Part 2?
See this issue: opengeospatial/ogcapi-common#302 and this presentation to the Architecture DWG in February 2022: [https://portal.ogc.org/files/?artifact_id=100240](https:// portal.ogc.org/files/?artifact_id=100240)
The individual Web API building blocks are organized as sub-directories of an openapi/ directory:
- openapi/schemas/
- openapi/responses/
- openapi/parameters
- openapi/paths/
And within these directories, are organized by OGC API standard parts e.g.,:
-openapi/schemas/common-core/ (for schemas defined by Common - Part 1)
-openapi/schemas/common-geodata/ (for schemas defined by Common - Part 2)
-openapi/schemas/maps-core/ (for schemas defined by Maps - Part 1)
This facilitates synchronizing these building blocks between different standards, especially between Common and the others.
In the openapi/ directory there is an example OpenAPI definition that includes these building blocks, which produces a valid OpenAPI document. That document can be bundled with the swagger-cli tool (see also its GitHub repository)

[chris-little]

@ghobona Changing OGC API-EDR V1.2 to adhere to this suggestion for Common Part 2 is a lot of editorial work. It is good suggestion. What is the current policy or status of this suggestion please, especially re retrofitting? It is mainly editorial, but with costs, no error fixing or extra functionality, but will have benefits for future support.