You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 2, 2023. It is now read-only.
@@ -31,60 +31,60 @@ The old syntax for these keywords is not an error (and the default meta-schema s
31
31
32
32
### Annotations, Errors, and Outputs
33
33
34
-
[Annotation keywords](WIP-jsonschema-core.html#rfc.section.7.7) such as `title`, `readOnly`, and `default` have always been a part of JSON Schema, but without any guidance on how to make use of them. This draft formalizes how implementations can make annotation information available to applications.
34
+
[Annotation keywords](/work-in-progress/WIP-jsonschema-core.html#rfc.section.7.7) such as `title`, `readOnly`, and `default` have always been a part of JSON Schema, but without any guidance on how to make use of them. This draft formalizes how implementations can make annotation information available to applications.
35
35
36
36
Similarly, there has not previously been guidance on what constitutes useful error reporting when validation fails.
37
37
38
-
To solve both of these problems, we now recommend that implementations support one or more of standardized [output formats](WIP-jsonschema-core.html#rfc.section.10).
38
+
To solve both of these problems, we now recommend that implementations support one or more of standardized [output formats](/work-in-progress/WIP-jsonschema-core.html#rfc.section.10).
39
39
40
40
### Keyword Changes
41
41
42
-
All keywords have now been organized into [vocabularies](WIP-jsonschema-core.html#rfc.section.8.1), with the Core and Validation specifications containing multiple vocabularies. In this process, some keywords have moved from Validation into Core.
42
+
All keywords have now been organized into [vocabularies](/work-in-progress/WIP-jsonschema-core.html#rfc.section.8.1), with the Core and Validation specifications containing multiple vocabularies. In this process, some keywords have moved from Validation into Core.
[`$anchor`](WIP-jsonschema-core.html#rfc.section.8.2.3) | **new** | Replaces the `#plain-name` form of `$id`, with a different syntax and approach
51
-
[`$defs` (renamed from `definitions`)](WIP-jsonschema-core.html#rfc.section.8.2.5) | **renamed** | Note that the standard meta-schema still reserves `definitions` for backwards compatibility
52
-
[`$id`](WIP-jsonschema-core.html#rfc.section.8.2.2) | **changed** | Only URI-references without fragments are allowed; see `$anchor` for a replacement for plain-name fragments; all other fragments in `$id` had undefined behavior previously
53
-
[`$recursiveAnchor` and `$recursiveRef`](WIP-jsonschema-core.html#rfc.section.8.2.4.2) | **new** | Used for extending recursive schemas such as meta-schemas
50
+
[`$anchor`](/work-in-progress/WIP-jsonschema-core.html#rfc.section.8.2.3) | **new** | Replaces the `#plain-name` form of `$id`, with a different syntax and approach
51
+
[`$defs` (renamed from `definitions`)](/work-in-progress/WIP-jsonschema-core.html#rfc.section.8.2.5) | **renamed** | Note that the standard meta-schema still reserves `definitions` for backwards compatibility
52
+
[`$id`](/work-in-progress/WIP-jsonschema-core.html#rfc.section.8.2.2) | **changed** | Only URI-references without fragments are allowed; see `$anchor` for a replacement for plain-name fragments; all other fragments in `$id` had undefined behavior previously
53
+
[`$recursiveAnchor` and `$recursiveRef`](/work-in-progress/WIP-jsonschema-core.html#rfc.section.8.2.4.2) | **new** | Used for extending recursive schemas such as meta-schemas
54
54
[`$ref`] | **changed** | Other keywords are now allowed alongside of it
55
-
[`$vocabulary`](WIP-jsonschema-core.html#rfc.section.8.1) | **new** | Has effects only in meta-schemas, and is used to control what keywords an implementation must or can support in order to process a schema using that meta-schema
55
+
[`$vocabulary`](/work-in-progress/WIP-jsonschema-core.html#rfc.section.8.1) | **new** | Has effects only in meta-schemas, and is used to control what keywords an implementation must or can support in order to process a schema using that meta-schema
These keywords were formerly found in the Validation Specification.
62
62
63
63
keyword | change | notes
64
64
---- | ---- | ----
65
-
[`dependentSchemas` (split from `dependencies`)](WIP-jsonschema-core.html#rfc.section.9.2.2.4) | **split** | This is the schema form of `dependencies`; note that the standard meta-schema still reserves `dependencies` for backwards compatibility
66
-
[`unevaluatedItems`](WIP-jsonschema-core.html#rfc.section.9.3.1.3) | **new** | Similar to `additionalItems`, but can "see" into subschemas and across references
67
-
[`unevaluatedProperties`](WIP-jsonschema-core.html#rfc.section.9.3.2.4) | **new** | Similar to `additionalProperties`, but can "see" into subschemas and across references
65
+
[`dependentSchemas` (split from `dependencies`)](/work-in-progress/WIP-jsonschema-core.html#rfc.section.9.2.2.4) | **split** | This is the schema form of `dependencies`; note that the standard meta-schema still reserves `dependencies` for backwards compatibility
66
+
[`unevaluatedItems`](/work-in-progress/WIP-jsonschema-core.html#rfc.section.9.3.1.3) | **new** | Similar to `additionalItems`, but can "see" into subschemas and across references
67
+
[`unevaluatedProperties`](/work-in-progress/WIP-jsonschema-core.html#rfc.section.9.3.2.4) | **new** | Similar to `additionalProperties`, but can "see" into subschemas and across references
68
68
69
69
The other applicator vocabulary keywords are `items`, `additionalItems`, `properties`, `patternProperties`, `additionalProperties`, `anyOf`, `allOf`, `oneOf`, `not`, `if`, `then`, `else`.
[`dependentRequired` (split from `dependencies`)](WIP-jsonschema-validation.html#rfc.section.6.5.4) | **split** | This is the string array form of `dependencies`; note that the standard meta-schema still reserves `dependencies` for backwards compatibility
78
-
[`maxContains` and `minContains`](WIP-jsonschema-validation.html#rfc.section.6.4.4) | **new** | Assertion for controlling how many times a subschema must be matched within an array
77
+
[`dependentRequired` (split from `dependencies`)](/work-in-progress/WIP-jsonschema-validation.html#rfc.section.6.5.4) | **split** | This is the string array form of `dependencies`; note that the standard meta-schema still reserves `dependencies` for backwards compatibility
78
+
[`maxContains` and `minContains`](/work-in-progress/WIP-jsonschema-validation.html#rfc.section.6.4.4) | **new** | Assertion for controlling how many times a subschema must be matched within an array
The `format` keywords has always been problematic due to its optional nature. There has never been a way to ensure that the implementation processing your schema supports `format` at all, or if it does, to what degree it validates each type of format. In theory, since each format references a standard specification, if a format is supported, it should behave consistently. In practice, this is not the case.
86
86
87
-
There are two ways for an application to validate formats: It can rely on a JSON Schema implementation to validate them (which may or may not have the expected results), or it can note where the `format` keyword has been used and perform its own validation based on that. This second approach is supported by treating `format` as an [annotation keyword](WIP-jsonschema-core.html#rfc.section.7.7) and supporting the [basic, detailed, or verbose output formats](WIP-jsonschema-core.html#rfc.section.10.4.2).
87
+
There are two ways for an application to validate formats: It can rely on a JSON Schema implementation to validate them (which may or may not have the expected results), or it can note where the `format` keyword has been used and perform its own validation based on that. This second approach is supported by treating `format` as an [annotation keyword](/work-in-progress/WIP-jsonschema-core.html#rfc.section.7.7) and supporting the [basic, detailed, or verbose output formats](/work-in-progress/WIP-jsonschema-core.html#rfc.section.10.4.2).
88
88
89
89
To impose some predictability on this system, the behavior has changed in several ways, as illustrated below. The key difference here is that `format` validation is now predictably off by default, but can be configured to be turned on. In draft-07, it was on (but possibly unimplemented) by default and could be configured to be turned off.
90
90
@@ -129,34 +129,34 @@ Additionally, two new formats were added, and a specification reference was upda
129
129
130
130
format | change | notes
131
131
---- | ---- | ----
132
-
[`"duration"`](WIP-jsonschema-validation.html#rfc.section.7.3.1) | **added** | The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339
133
-
[`"hostname"` and `"idn-hostname"`](WIP-jsonschema-validation.html#rfc.section.7.3.3) | **updated** | Use RFC 1123 instead of RFC 1034; this allows for a leading digit
134
-
[`"uuid"`](WIP-jsonschema-validation.html#rfc.section.7.3.5) | **added** | A string instance is valid against this attribute if it is a valid string representation of a UUID, according to RFC4122
132
+
[`"duration"`](/work-in-progress/WIP-jsonschema-validation.html#rfc.section.7.3.1) | **added** | The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339
133
+
[`"hostname"` and `"idn-hostname"`](/work-in-progress/WIP-jsonschema-validation.html#rfc.section.7.3.3) | **updated** | Use RFC 1123 instead of RFC 1034; this allows for a leading digit
134
+
[`"uuid"`](/work-in-progress/WIP-jsonschema-validation.html#rfc.section.7.3.5) | **added** | A string instance is valid against this attribute if it is a valid string representation of a UUID, according to RFC4122
These keywords are now specified purely as annotations, and never assertions. Some guidance is provided around how an implementation can optionally offer further automatic processing of this information outside of the validation process.
142
142
143
143
keyword | change | notes
144
144
---- | ---- | ----
145
-
[`contentEncoding`](WIP-jsonschema-validation.html#rfc.section.8.3) | **updated** | Encodings from RFC 4648 are now allowed, and take precedence over RFC 2045 when there is a difference
146
-
[`contentSchema`](WIP-jsonschema-validation.html#rfc.section.8.5) | **added** | Schema for use with the decoded content string; note that it is _not_ automatically applied as not all content media types can be understood in advance
145
+
[`contentEncoding`](/work-in-progress/WIP-jsonschema-validation.html#rfc.section.8.3) | **updated** | Encodings from RFC 4648 are now allowed, and take precedence over RFC 2045 when there is a difference
146
+
[`contentSchema`](/work-in-progress/WIP-jsonschema-validation.html#rfc.section.8.5) | **added** | Schema for use with the decoded content string; note that it is _not_ automatically applied as not all content media types can be understood in advance
[`deprecated`](WIP-jsonschema-validation.html#rfc.section.9.3) | **added** | Used to indicate that a field is deprecated in some application-specific manner
154
+
[`deprecated`](/work-in-progress/WIP-jsonschema-validation.html#rfc.section.9.3) | **added** | Used to indicate that a field is deprecated in some application-specific manner
155
155
156
156
#### Hyper-Schema Vocabulary
157
157
158
-
[Hyper-Schema Specification, Sections 5 and 6](WIP-jsonschema-hyperschema.html#rfc.section.5)
158
+
[Hyper-Schema Specification, Sections 5 and 6](/work-in-progress/WIP-jsonschema-hyperschema.html#rfc.section.5)
159
159
160
160
keyword | change | notes
161
161
---- | ---- | ----
162
-
[`rel`](WIP-jsonschema-hyperschema.html#rfc.section.6.2.1) | **changed** | Can now be an array of values instead of just a string
162
+
[`rel`](/work-in-progress/WIP-jsonschema-hyperschema.html#rfc.section.6.2.1) | **changed** | Can now be an array of values instead of just a string
0 commit comments