Multiple unnecessary schema redefinition

[fmigneault]

Multiple schemas are redundant under: https://github.com/opengeospatial/ogcapi-processes/tree/master/openapi/schemas

Examples:

• https://github.com/opengeospatial/ogcapi-processes/tree/master/openapi/schemas/geojson
  directly redefines GeoJSON

• Items under

  • https://github.com/opengeospatial/ogcapi-processes/tree/master/openapi/schemas/common-core
  • https://github.com/opengeospatial/ogcapi-processes/tree/master/openapi/schemas/common-geodata

  that redefines items that are (or should be) provided in:

  • https://github.com/opengeospatial/ogcapi-common/tree/master/collections/openapi
  • https://github.com/opengeospatial/ogcapi-common/tree/master/crs/openapi/schemas
  • https://github.com/opengeospatial/ogcapi-common/tree/master/api_modules/collection/schemas
  • https://schemas.opengis.net/ogcapi/common/part1/1.0/openapi/schemas/

• https://github.com/opengeospatial/ogcapi-processes/blob/master/openapi/schemas/processes-core/schema.yaml
  which looks to be a (equivalent/simplified?) JSON-schema specification

• and probably more...

Items that can be reused should do so to avoid diverging definitions and interpretation by developers/users/implementations.

Furthermore, reusing the https://github.com/opengeospatial/ogcapi-common schemas would facilitate interoperability between the various reusable components under the "OGC API - {standard}" umbrella.

[jerstlouis]

@fmigneault

Items that can be reused should do so to avoid diverging definitions and interpretation by developers/users/implementations. Furthermore, reusing the https://github.com/opengeospatial/ogcapi-common schemas would facilitate interoperability between the various reusable components under the "OGC API - {standard}" umbrella.

I fully agree with the goals here.

However, for various reasons such as the ability to include things in metanorma documents, easily produce an API definition with swagger-cli bundle without external dependencies, and having normative schemas at https://schemas.opengis.net/ogcapi/processes/ before OGC API - Common is actually published, the building blocks originating from elsewhere are included here.

The idea to organize the building blocks into /common-* is precisely to try to facilitate synchronizing those builing blocks (e.g., by doing a directory/files comparison only within that sub-directory).

I hope the efforts with the building blocks register and overall efforts to improve semantic support in the standards and the definition server will make this easier and help achieve and maintain consistency.

We adopted the same practice in OGC API - Tiles, DGGS, Coverages, Maps, and those common- blocks should be mostly in sync there. The Common group has not met in a while, but this is related to opengeospatial/ogcapi-common#302.

[fmigneault]

@pvretano
I do not think this blocks the standard definition.
It's something that should be improved over time using the building blocks and the official schema references rather than the local copies to help cross OGC API references to work as intended.
Currently, there are potential discrepancies between published schemas and the local ones.

I will close so that we focus on "more important" issues. We can reopen once building blocks will be better defined.