GSD tweaks for 2020 12 patch #1238
Closed
Conversation
This file contains hidden or 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 is covered for the entire spec as section 8.1.3. Note that the validation spec also has this, but only once in that document, so nothing else needs deleting.
Remove repetitiously redundant paragraphs
Vocabulary definitions need not be formal or published depending on usage.
It is related to MIME's Content-Transfer-Encoding, and not HTTP's Content-Encoding.
We also remove the trailing comma. See: #1162 Signed-off-by: Juan Cruz Viotti <[email protected]>
RFC3339 refers to these as "formats". The XML xs:NCName specification refers to it as a "type". We are tying our implementation to the ABNF rules explicitly, so refer to those.
- More cross-references added that note the dependence of these keywords on each other - Confusing paragraph about logical results removed (and it is redundant with other paragraphs)
Co-authored-by: Ben Hutton <[email protected]>
…cal (#1192) * Clarify that plain name fragments are neither canonical or non-canonical Attempt to resolve #937 Add note and cref in appendix A clarifying that we intended to define a URI phrasing which would avoid the requirement to allow for location shadowing in implementations, as this is tricky. Clarifying that plain name fragments should always be supported, and that they only can work in relation to the base URI of the Schema Resource. Otherwise there could be duplicate plain name fragments and addressing wouldn't work.
Fixes issue #937, clarifying a number of other things along the way. While it touches a fair number of lines, I'm fairly sure that it doesn't anything about conformance. After spending more time reading various writings on the concept of the "canonical" URI for a resource, and reviewing our language, I came to the following conclusions: * canonical URIs only make sense at the whole-resource scope * A URI with a fragment is neither canonical nor non-canonical * It makes more sense to talk about fragments w.r.t. canonical URIs * Our language was sufficiently confusing that going this way seems fine. As part of this, I fixed an outright incorrect statement that identifier keywords set canonical URIs. Since there is only one canonical URI and a single schema object could contain three ($id, $anchor, $dynamicAnchor) or more identifier keywords, this statement is clearly a bug. These keywords assign URIs, but only $id assigns a canonical one. I revamped a lot of wording in descriptions and examples to hopefully be more precise. I separated the discussion of the empty fragment in $id from the main paragraph of its functionality, and clarified that this is talking about a media-type-specific semantic equivalence, and is not asserting that RFC 3986 normalization applies to fragments (this has been a point of confusion).
Fixes #1172 Must see new issue relating to the behaviour of annotation collection for resolving in the next draft.
Add first spec related ADR about the handling of additionalProperties ambiguity in 2019-09 and 2020-12 for the patch release by adding a CREF
Specifically draft-bhutton-json-schema-01 and draft-bhutton-json-schema-validation-01
gregsdennis
changed the title
|
ugh... what happened? this was a clean pull of latest! I changed a single line! |
|
oh... it defaulted to draft-next. |
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.
Resolves #1221 remaining issues.