-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recommendation for extending enumerations like provider roles #1147
Comments
Hrm, very interesting. Definitely a use case that makes a lot of sense, and one for which we didn't design an explicit extension point. Wish this had come up in one of the release candidates :) We perhaps could have just slid in a custodian value. @m-mohr is our JSON Schema expert - do you know if there's a way to override an enumeration in an extension? I think that would be ideal. If that's not possible in JSON Schema then it probably does need a new field. I do think if it proves to be an extension that gets adoption then it'd be easy to justify including it in core, for a 1.0.1 release (or maybe it needs to be 1.1?). But I don't think we'll do a 1.0.1 any time soon, I imagine we'll build up a number of little small non-breaking changes and then in a year or so bundle them up into one. |
I'm afraid, it's not possible. Once you "extend" the roles in an extension JSON Schema, the stac-spec Item/Collection JSON Schema will fail. The provider roles are (intentionally or unintentionally?) designed in a way that they can't be extended. What's closest to your use case is likely 'host'. I guess your best bet is to add an additional property to the Provider Object that describes the 'host' role better. At the simplest it would be |
Don't think it was intentional :(
So they would do this in an extension? The extension would add an additional property onto the provider object? That would only be valid if it was selected to be 'host'? |
I think it probably was, just because JSON Schema enums can't be extended. If we want to not just provide free-text string fields, we need to use enum. Having just free-text strings makes a spec pretty "weak". So that's why it probably is what we want (indirectly). I mean that is the inheritance thing again: You should not weaken contracts by adding new values, which were said to only return a certain amount of values (Liskov substitution principle).
Yes, that would be an option. |
We can't solve this until STAC 2.0, which is not really on the horizon yet. |
I'm part of a project which will need to add several extensions to STAC. STAC is fairly new at this organisation, and we don't have any JSON Schema experts here. One question which has come up is how to extend the allowed values for a core field, in this case the Provider
roles
. Right now the allowed values are "licensor
,producer
,processor
orhost
", but we would like to also includecustodian
: "The organisation that is responsible for the technical environment around the dataset, setting standards and ensuring safe storage of the dataset."How should I go about implementing this change in an extension? Is it possible to override the
roles
enumeration in such a way that the resulting schema will allow the new value, or should I create a new field just for this value? Or is there some other technique which is recommended here?I had a look through the documentation, but it doesn't seem to cover this part.
The text was updated successfully, but these errors were encountered: