[META] Future of Schemata/Compatibility with other ecosystem modules

There was some discussion recently in Drupal Slack over the role/future of Schemata vs. other modules in the same ecosystem. Schemata integrates with various modules either as a dependency or peer: Docson, OpenAPI, OpenAPI JSON:API, etc...

Particularly as regards json:api, there is significant duplicated logic between schemata and jsonapi_schema. These two modules serve different purposes, e.g., you may wish to generate an OpenAPI spec (requires schemata) and also surface json-schema alongside json:api (jsonapi_schema). The latter was forked off with significant Schemata code in it, so bugs that affect one likely affect the other. This particularly pertains to normalizers.

Some key quotes from Slack:

@richgerdes: I wouldn't say that schemata was deprecated, but the jsonapi portion of openapi is definitely not being actively worked on. I also haven't had time to work on the schemata and openapi stuff in general, so its definitely a bit stale.
...
I personally don't think the jsonapi schema system fully replaces the need for openapi, since openapi makes the requests library agnostic, where the jsonapi schema system still requires the client to know that the platform is based on jsonapi and how the various endpoints work.

Rich was generous enough to add me as a maintainer to openapi/openapi_jsonapi and jsonapi_schema, and I've been moving the latter forward in particular.

There is, however, significant spillover from schemata into other modules, like jsonapi_extras. Extras has schemata integration, so customization (e.g., enhancers) made with extras will be reflected in openapi, but not jsonapi_schema, which doesn't depend on schemata.

@richgerdes: I think that the jsonapi_schema stuff should have been built on schemata in the first place, since the schema is all json schema. When Gabe first started on the implementation he didn't want to have extra unnecessary dependencies, and since schemata had support for both rest and jsonapi, it didn't make sense. Ideally, we should probably have created a "jsonschema" module, and made openapi and jsonapi depend on that, or at least moved the platform specific code to separate sub modules? Who knows? Hindsight is always clearer. I think its a little awkward to add the dependency now, but maybe the openapi side of the house could just work off of the jsonapi_schema system instead and schemata can be left for more general entity schema and rest? I don't want to duplicate efforts, but at the same time changing either system my complicate things

@e0ipso: Dropping Schemata was one of the main drivers behind splitting openapi in openapi_jsonapi and openapi_rest. If we restrict ourselves to openapi_jsonapi, I believe Schemata should not be used. Sadly, that is still not the case. But instead of adding more onto Schemata, I would invest that effort into moving away from it.

Honestly, I (@bradjones1) don't really know where this leave us as far as a plan. I wasn't originally involved with the API-first initiative and it seems to be pretty much sunset at this point, but these various parts of the ecosystem are rather intertwined and not actively coordinated. My preference would be to do something along the lines of an audit of the various "schema" modules, their role and responsibilities, and determine what can be agreed upon as common dependencies. For my part, I would prefer a module or library that centralizes the field definition normalization logic and could be shared in all cases where json:api schema is needed. I have #3224754: Make schema normalizer overrides module-agnostic (support jsonapi_schema as well as Schemata/OpenAPI) open against jsonapi_extras which helps to illustrate the problem by way of a concrete example.