Move core examples/best practices to appendixes #791
Merged
Conversation
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
Relequestual
approved these changes
Sep 2, 2019
|
RFC NNNN - Keyword definitions for normative sections of RFC documents... 😉 |
I feel like I'm missing something or not getting the joke? Am I supposed to do something with this? |
|
The two commits I just added are:
So all of this PR has still been approved, although additional feedback is welcome and it can't be merged until after #780 is merged. |
|
Now also includes the commits from #792, which were approved by @Relequestual and @philsturgeon. I'm just trying to tidy up the stacked PRs while we wait for the final reviews. |
Sorry, just a joke. Should have included emoji =] |
Relequestual
approved these changes
Sep 9, 2019
awwright
approved these changes
Sep 10, 2019
These sections are not normative (RFC 2119 terms will be removed in a subsequent commit), and moving them to an appendix reduces the length of the sizable normative portion of the spec. And also improves flow, I think. The examples within core tend to rely on understanding more of the core keywords than have necessarily been introduced, so they work better after the entire vocabulary has been introduced.
Vocabulary authorship is not part of the JSON Schema specification, so this guidance should not use RFC 2119 terms.
This is going to be a powerful technique for generative use cases, which have been observed either requiring references (as opposed to subschemas) in certain places, or implementing various sorts of inferencing around references on their own or in conjunction with other keywords. For example, one OpenAPI documentation tool assumes that in an "allOf" of several references, the first is a base class of some sort. While this is not correct behavior by either JSON Schema or OpenAPI, it demonstrates a feature built by making implicit assumptions about certain references. This section provides a recommendation for making such behavior explicit, and also guides writers of such tools to the concept of extension vocabularies and annotations.
This should make clear what use cases are considered valid and safe, vs when someone is on their own in terms of figuring that out.
Co-Authored-By: Phil Sturgeon <[email protected]>
handrews
force-pushed
the
examp-best
branch
from
176fdba to
7e982af
Compare
gregsdennis
added
clarification
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
NOTE: The first commit is just a move, the second changes the RFC 2119 terms. They should be examined separately.
These sections are not normative, and moving them to an
appendix reduces the length of the sizable normative
portion of the spec. And also improves flow, I think.
The examples within core tend to rely on understanding more
of the core keywords than have necessarily been introduced,
so they work better after the entire vocabulary has been
introduced.
Vocabulary authorship is not part of the JSON Schema specification,
so this guidance should not use RFC 2119 terms.