Skip to content
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

gis_data_types can be empty #325

Open
1 of 2 tasks
m-mohr opened this issue Jul 20, 2020 · 3 comments
Open
1 of 2 tasks

gis_data_types can be empty #325

m-mohr opened this issue Jul 20, 2020 · 3 comments
Labels
breaking Breaking changes, requires a major-version (2.0.0 for example) bug capabilities
Milestone

Comments

@m-mohr
Copy link
Member

m-mohr commented Jul 20, 2020

Although for each file format in GET /file_formats a gis_data_types array is required, it is not required to have an item. It should have had a minItems: 1 entry, but hasn't. Thus we can't add it any more as it's also not specified in text anywhere that an entry is required, i.e. it's a breaking change.

ToDo:

  • For 1.0.1 we can add a recommendation that at least one item should be given.
  • For 2.0.0 we can add minItems: 1
@m-mohr m-mohr modified the milestones: future, v1.0.1 Jul 20, 2020
@m-mohr m-mohr added bug patch requires a patch-version (x.x.1 for example) breaking Breaking changes, requires a major-version (2.0.0 for example) labels Jul 20, 2020
@soxofaan
Copy link
Member

other possible solution: add "if empty: ["other"] is assumed"?

@m-mohr
Copy link
Member Author

m-mohr commented Jul 22, 2020

@soxofaan That's not really backward compatible, so could only be in 2.0.0. But then we can simply go the clean route that requires a specific item chosen by the back-end.

Nevertheless, I guess implementations will assume that anyway until then.

m-mohr added a commit that referenced this issue Nov 19, 2020
@m-mohr
Copy link
Member Author

m-mohr commented Nov 19, 2020

Added the recommendation for API 1.0.1:

It is RECOMMENDED to specify at least one of the data types, which will likely become a requirement in a future API version.

@m-mohr m-mohr modified the milestones: v1.0.1, future Nov 19, 2020
@m-mohr m-mohr removed the patch requires a patch-version (x.x.1 for example) label Nov 19, 2020
@m-mohr m-mohr modified the milestones: future, 2.0.0 Dec 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Breaking changes, requires a major-version (2.0.0 for example) bug capabilities
Projects
None yet
Development

No branches or pull requests

2 participants