replace keywords with types and relax restrictions on keywords #43
Conversation
node_registry.schema.json
Outdated
| "ogcapi_processes", | ||
| "ogcapi_dggs" |
There was a problem hiding this comment.
Should we be proactive and add the others as well?
(https://ogcapi.ogc.org/#standards)
I think ogcapi_coverages will be the next one on my roadmap.
Wondering also if we should have stac explicitly or catalog is sufficient?
Technically, stac would be a ogcapi_features and ogcapi_records as well.
There was a problem hiding this comment.
Sure why not, I'm happy to add anything here that would let clients meaningfully differentiate between services.
| MIGRATIONS = ( | ||
| convert_keywords_to_types, | ||
| ) |
There was a problem hiding this comment.
Should this migration be within a version mapping?
For example, migrating from 1.2->1.3 makes senses to apply this fix, but it shouldn't be done if 1.3 is already applied. Maybe future migration will require specific version checks as well.
There was a problem hiding this comment.
I was thinking about that but then I decided against it due to the complexity of tracking version differences within the schema.
If you'd prefer that strategy I can make it work but it didn't seem worth it at the time.
There was a problem hiding this comment.
I'm fine with the current approach if it avoids unnecessary complexity/over-engineering since I don't expect the schemas to change too often. If they change drastically, it would probably be a major version anyway, and migration would not be possible if such change was actually needed.
There was a problem hiding this comment.
Should we add the explicit $id as https://raw.githubusercontent.com/DACCS-Climate/Marble-node-registry/refs/tags/1.2.0/node_registry.schema.json (and after bump/tag with 1.3.0)? That would help ensure the reported $schema by the services matches the specific versions that exist.
As discussed in #39 this will replace service "keywords" with "types" and allow keywords to be any string.
This also introduces a mechanism to automatically migrate older versions of the schema to be compatible with the newest version so that we can support nodes that provide older data without needing everyone to update at once.
Resolves #39