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
Fix: Bad contrast in the blog's dark theme in info boxes (#1143)
* Fix: Bad contrast in the blog's dark theme in info boxes (#1070)
* Fix:Fixed the error where the changes were not
occuring during preview
* Fixed the liniting error
* Fixed the problem of changes not working in
deployement
* Fixed the purging issue
* fixing purging issue
* trying to fix purging issue again
* Trying to fix the issue again
* final fix
* trying to fix purging issue again
* fixing the lint error
* Update applicability-json-schema-fundamentals-part-1.md
---------
Co-authored-by: Benjamin Granados <[email protected]>
Copy file name to clipboardExpand all lines: pages/blog/posts/applicability-json-schema-fundamentals-part-1.md
+35-32Lines changed: 35 additions & 32 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
-
title: "It all starts with applicability - JSON Schema Fundamentals part 1"
3
-
date: "2022-03-21"
2
+
title: 'It all starts with applicability - JSON Schema Fundamentals part 1'
3
+
date: '2022-03-21'
4
4
tags:
5
5
- Fundamentals
6
6
type: Engineering
@@ -10,14 +10,13 @@ authors:
10
10
photo: /img/avatars/benhutton.webp
11
11
link: https://www.x.com/relequestual
12
12
byline: JSON Schema Specification Lead @Postman
13
-
excerpt: "We explore the fundamental JSON Schema concepts: Applicability, Subschemas, and Assertion Boolean Logic - Everyone needs good fundamentals."
13
+
excerpt: 'We explore the fundamental JSON Schema concepts: Applicability, Subschemas, and Assertion Boolean Logic - Everyone needs good fundamentals.'
14
14
---
15
15
16
16
"Validation begins by applying the root Schema to the complete instance document. Applicator keywords apply subschemas to the instance location." - Borrowed from [JSON Schema in 5 minutes](https://json-schema.org/blog/posts/json-schema-in-5-minutes).
17
17
18
18
The primary use case for JSON Schema is validation. Therefore it's imperative to understand precisely how the validation process happens. Let's take a little time to properly grasp the fundamental JSON Schema concept of Applicability.
19
19
20
-
21
20
# Applicator keywords
22
21
23
22
JSON Schema consists of many keywords. These keywords can be broken down into categories, one of which is "applicator". In the physical sense, an "applicator" is a thing you use to introduce one substance to another. For example, a cloth might be used to introduce polish to a nice wooden table. The cloth is the applicator. The polish is applied to the table via the cloth.
@@ -30,23 +29,21 @@ The validation process for JSON Schema begins with applying the whole JSON Schem
30
29
31
30
A JSON Schema may be a Boolean or an Object. In the introductory article mentioned above, we noted how a Boolean Schema of `true` or `false` resulted in the same assertion result (true and false respectivly) regardless of the instance data. We also noted how the equivalent Object Schemas were `{ }` and `{ "not": { } }` respectively. (The `not` keyword inverts the assertion result.)
<p>An "assertion" is a statement of fact. This is used in reference to the result of testing in Computing. The test might be called "X is 1". If the test passes, the assertion is true!</p>
36
-
</div>
35
+
</specialBox>
37
36
38
37
When we talk about the whole Schema in terms of application, we usually refer to it as the "root Schema". This is because the other Schemas which are applied to specific instance locations are different, and we call them "subschemas". Differentiating between the root Schema and subschemas allows us to communicate with clarity which JSON Schema we're talking about, and when to use the Schema as part of the validation process.
<p>The following examples assume to be using JSON Schema 2020-12. Where there are things you should know about previous versions (or drafts) of JSON Schema, it will be highlighted.</p>
42
-
</div>
43
-
41
+
</specialBox>
44
42
45
43
# Subschema application - Validating Objects and Arrays
46
44
47
45
If your JSON instance is an Object or an Array, you'll likely want to validate the values of the Object or the items in the Array. In this introduction, you'll be using the `properties` and `items` keywords, and subschemas.
48
46
49
-
50
47
## Validating Objects
51
48
52
49
Let's jump into an example. Here's our instance data.
@@ -85,6 +82,8 @@ OK, let's check our Schema does all we need it to. What happens when our instanc
85
82
"isEmailConfirmed": "true"
86
83
}
87
84
// isEmailConfirmed should be a Boolean, not a string.
85
+
86
+
88
87
// Will cause validation error.
89
88
```
90
89
@@ -98,7 +97,7 @@ We need to make sure we define the appropriate constraint if we want any keys to
98
97
"email": { "type": "string" },
99
98
"isEmailConfirmed": { "type": "boolean" }
100
99
},
101
-
"required": ["id", "name", "email"]
100
+
"required": ["id", "name", "email"]
102
101
}
103
102
```
104
103
@@ -112,6 +111,8 @@ We can now be confident that if our required fields are missing, validation will
112
111
"isEmaleConfirmed": "true"
113
112
}
114
113
// Typo for key "isEmaleConfirmed".
114
+
115
+
115
116
// Validates because of applicability.
116
117
```
117
118
@@ -127,16 +128,16 @@ Luckily, picking this up with our Schema is simple. The `additionalProperties` k
127
128
"email": { "type": "string" },
128
129
"isEmailConfirmed": { "type": "boolean" }
129
130
},
130
-
"required": ["id", "name", "email"],
131
+
"required": ["id", "name", "email"],
131
132
"additionalProperties": false
132
133
}
133
134
```
134
135
135
136
The value of `additionalProperties` is not just a Boolean, but a Schema. This subschema value is applied to all values of the instance object that are not defined in the `properties` object in our example. You could use `additionalProperties` to allow additional properties, but constrain their values to be a String.
<p>There is a little simplification here to help us understand the concept we're looking to learn. If you want to dig a little deeper, check out our <ahref="https://json-schema.org/understanding-json-schema/reference/object.html#additional-properties"target="_blank">learning resources on `additionalProperties`</a>.</p>
139
-
</div>
140
+
</specialBox>
140
141
141
142
Finally, what if we expect an Object, but are given an Array or another non-object type?
142
143
@@ -149,6 +150,8 @@ Finally, what if we expect an Object, but are given an Array or another non-obje
149
150
"isEmaleConfirmed": "true"
150
151
}
151
152
]
153
+
154
+
152
155
// An array is not an object...
153
156
```
154
157
@@ -165,7 +168,7 @@ The three keywords we've explored so far, `properties`, `required`, and `additio
165
168
"email": { "type": "string" },
166
169
"isEmailConfirmed": { "type": "boolean" }
167
170
},
168
-
"required": ["id", "name", "email"],
171
+
"required": ["id", "name", "email"],
169
172
"additionalProperties": false
170
173
}
171
174
```
@@ -174,12 +177,11 @@ In summary, for the soundest validation, we must express all the constraints we
174
177
175
178
Note, `type` takes an Array of types. It may be that your instance is allowed to be an Object or an Array, and constraints for both can be defined within the same Schema Object.
<p>In this introduction, we're only going to be covering how things work for JSON Schema 2020-12. If you're using a previous version, including "draft-7" or prior, you will likely benefit from digging a little deeper into the <ahref="https://json-schema.org/understanding-json-schema/reference/array.html"target="_blank">learning resources for Array validation.</a></p>
182
-
</div>
184
+
</specialBox>
183
185
184
186
Let's step back to our previous example data, where we were provided with an Array as opposed to an Object. Let's say our data is now only allowed to be an Array.
185
187
@@ -195,7 +197,7 @@ To validate every item in the array, we need to use the `items` keyword. The `it
195
197
"email": { "type": "string" },
196
198
"isEmailConfirmed": { "type": "boolean" }
197
199
},
198
-
"required": ["id", "name", "email"],
200
+
"required": ["id", "name", "email"],
199
201
"additionalProperties": false
200
202
}
201
203
}
@@ -205,7 +207,6 @@ As with the applicability rules of `properties`, the value Schema of `items` is
205
207
206
208
There are other keywords that are applicable to arrays, but If I continue to explain all of them in detail, this article might start to turn into a reference book! Moving on...
207
209
208
-
209
210
# Apply but modify - Boolean logic with subschemas
210
211
211
212
JSON Schema applicator keywords can do more than just apply a subschema and take the resulting Boolean assertion. Applicator keywords can conditionally apply subschemas, and combine or modify any resulting assertions using boolean logic.
@@ -222,18 +223,19 @@ This sounds simple, but let's look at some examples.
<p><spanclassName="font-bold">Remember:</span> A Boolean is a valid schema that always produces the assertion result of its value, regardless of the instance data.</p>
236
-
</div>
238
+
</specialBox>
237
239
238
240
Our first "allOf" example shows the array having three subschemas, which are all `true`. The results are combined using the boolean logic AND operator. The resulting assertion from the `allOf` keyword is `true`.
239
241
@@ -243,16 +245,15 @@ The `true` and `false` Boolean Schemas in this example could be any subschemas t
243
245
244
246
Let's take the two examples again, but use `anyOf` rather than `allOf`.
245
247
246
-
247
248
```json caption="anyOf/example1.schema.json"
248
249
{
249
-
"anyOf": [true, true, true]
250
+
"anyOf": [true, true, true]
250
251
}
251
252
```
252
253
253
254
```json caption="anyOf/example2.schema.json"
254
255
{
255
-
"anyOf": [true, false, true]
256
+
"anyOf": [true, false, true]
256
257
}
257
258
```
258
259
@@ -329,7 +330,8 @@ Let's go back to our array of people data, modify it, and say it represents an a
0 commit comments