-
Notifications
You must be signed in to change notification settings - Fork 57
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
Improves Covering Schema #208 #209
Merged
Merged
Changes from 2 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
8a48f19
Improves Covering Schema #208
m-mohr f0a4483
Add test
m-mohr 0723ce5
Merge branch 'main' into m-mohr-patch-1
m-mohr f8e6b6b
Merge branch 'main' into m-mohr-patch-1
m-mohr d7b4f56
Merge branch 'main' into m-mohr-patch-1
cholmes e791ee2
Merge branch 'main' into m-mohr-patch-1
cholmes File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to make this required if we want to add other covering types in the future. Or would we remove this
required
when we add the future covering type?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or is there some way to define the specific key names allowed? E.g. that today we only allow the "bbox" key inside
coverings
, but that in the future other keys may be allowed as well?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's the question. I mean right now it's required, isn't it? Otherwise it's empty or someone puts anything else.
In the future the requirement could be relaxed of course, but for 1.1 it doesn't feel very useful to not require it?!
With regards to your second comment, I'm not sure I understand what you are looking for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that your change means that a
bbox
key is now required. Instead, is there some way in JSON schema to allow an enum of values? So we currently define an enum with a single variant but can expand that in the future?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could do something like the following to indicate that you expect more fields in the future where having one of them is required:
It's not really different though, it's just an implicit indication for people reading the schema.
The question really is:
Are
covering: {}
or e.g.covering: { a: "b" }
something that should be allowed in 1.1? Or do we always expect that in 1.1 there is a bbox member in covering? I couldn't really figure out what the intention is...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the expectation is that if the
covering
key exists, then it has abbox
member key.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then the PR is correct. If you want I can update it to the anyOf, I'm pretty neutral on it. What do others think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I think it's fine as-is. Whenever more options are added, the
"required": ["bbox"]
can change to anyOf or oneOf without losing the meaning. And since only the outermost element has additionalProperties set to false, it seems consistent to leave it out here.