Skip to content

Commit 73bcb7b

Browse files
ritwik-69benjagm
andauthored
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]>
1 parent 179a1d3 commit 73bcb7b

File tree

2 files changed

+46
-32
lines changed

2 files changed

+46
-32
lines changed

components/StyledMarkdown.tsx

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -191,6 +191,16 @@ const StyledMarkdownBlock = ({ markdown }: { markdown: string }) => {
191191
</p>
192192
),
193193
},
194+
specialBox: {
195+
component: ({ children }) => {
196+
return (
197+
<div className='bg-blue-200 border-l-4 border-blue-500 px-4 py-1 relative text-blue-700 dark:bg-blue-900 dark:border-blue-400 dark:text-blue-200'>
198+
{children}
199+
</div>
200+
);
201+
},
202+
},
203+
194204
a: {
195205
component: ({ children, href, title, className }) => {
196206
if (!href) return children;
@@ -665,6 +675,7 @@ export function TableOfContentMarkdown({
665675
'figure',
666676
'Bigquote',
667677
'Regularquote',
678+
'specialBox',
668679
),
669680
},
670681
}}

pages/blog/posts/applicability-json-schema-fundamentals-part-1.md

Lines changed: 35 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
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'
44
tags:
55
- Fundamentals
66
type: Engineering
@@ -10,14 +10,13 @@ authors:
1010
photo: /img/avatars/benhutton.webp
1111
link: https://www.x.com/relequestual
1212
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.'
1414
---
1515

1616
"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).
1717

1818
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.
1919

20-
2120
# Applicator keywords
2221

2322
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
3029

3130
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.)
3231

33-
<div className="bg-blue-200 border-l-4 border-blue-500 px-4 py-1 relative text-blue-700">
32+
<specialBox>
3433
<p className="font-bold"><svg className="w-6 h-6 mr-2 float-left mt-0" xmlns="https://www.w3.org/2000/svg" viewBox="0 0 20 20" fill="currentColor"><path fillRule="evenodd" d="M18 10a8 8 0 11-16 0 8 8 0 0116 0zm-8-3a1 1 0 00-.867.5 1 1 0 11-1.731-1A3 3 0 0113 8a3.001 3.001 0 01-2 2.83V11a1 1 0 11-2 0v-1a1 1 0 011-1 1 1 0 100-2zm0 8a1 1 0 100-2 1 1 0 000 2z" clipRule="evenodd" /></svg>Vocabulary check</p>
3534
<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>
3736

3837
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.
3938

40-
<div className="bg-blue-200 border-l-4 border-blue-500 px-4 py-1 relative text-blue-700">
39+
<specialBox>
4140
<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>
4442

4543
# Subschema application - Validating Objects and Arrays
4644

4745
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.
4846

49-
5047
## Validating Objects
5148

5249
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
8582
"isEmailConfirmed": "true"
8683
}
8784
// isEmailConfirmed should be a Boolean, not a string.
85+
86+
8887
// Will cause validation error.
8988
```
9089

@@ -98,7 +97,7 @@ We need to make sure we define the appropriate constraint if we want any keys to
9897
"email": { "type": "string" },
9998
"isEmailConfirmed": { "type": "boolean" }
10099
},
101-
"required": [ "id", "name", "email" ]
100+
"required": ["id", "name", "email"]
102101
}
103102
```
104103

@@ -112,6 +111,8 @@ We can now be confident that if our required fields are missing, validation will
112111
"isEmaleConfirmed": "true"
113112
}
114113
// Typo for key "isEmaleConfirmed".
114+
115+
115116
// Validates because of applicability.
116117
```
117118

@@ -127,16 +128,16 @@ Luckily, picking this up with our Schema is simple. The `additionalProperties` k
127128
"email": { "type": "string" },
128129
"isEmailConfirmed": { "type": "boolean" }
129130
},
130-
"required": [ "id", "name", "email" ],
131+
"required": ["id", "name", "email"],
131132
"additionalProperties": false
132133
}
133134
```
134135

135136
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.
136137

137-
<div className="bg-blue-200 border-l-4 border-blue-500 px-4 py-1 relative text-blue-700">
138+
<specialBox>
138139
<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 <a href="https://json-schema.org/understanding-json-schema/reference/object.html#additional-properties" target="_blank">learning resources on `additionalProperties`</a>.</p>
139-
</div>
140+
</specialBox>
140141

141142
Finally, what if we expect an Object, but are given an Array or another non-object type?
142143

@@ -149,6 +150,8 @@ Finally, what if we expect an Object, but are given an Array or another non-obje
149150
"isEmaleConfirmed": "true"
150151
}
151152
]
153+
154+
152155
// An array is not an object...
153156
```
154157

@@ -165,7 +168,7 @@ The three keywords we've explored so far, `properties`, `required`, and `additio
165168
"email": { "type": "string" },
166169
"isEmailConfirmed": { "type": "boolean" }
167170
},
168-
"required": [ "id", "name", "email" ],
171+
"required": ["id", "name", "email"],
169172
"additionalProperties": false
170173
}
171174
```
@@ -174,12 +177,11 @@ In summary, for the soundest validation, we must express all the constraints we
174177

175178
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.
176179

177-
178180
## Validating Arrays
179181

180-
<div className="bg-blue-200 border-l-4 border-blue-500 px-4 py-1 relative text-blue-700">
182+
<specialBox>
181183
<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 <a href="https://json-schema.org/understanding-json-schema/reference/array.html" target="_blank">learning resources for Array validation.</a></p>
182-
</div>
184+
</specialBox>
183185

184186
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.
185187

@@ -195,7 +197,7 @@ To validate every item in the array, we need to use the `items` keyword. The `it
195197
"email": { "type": "string" },
196198
"isEmailConfirmed": { "type": "boolean" }
197199
},
198-
"required": [ "id", "name", "email" ],
200+
"required": ["id", "name", "email"],
199201
"additionalProperties": false
200202
}
201203
}
@@ -205,7 +207,6 @@ As with the applicability rules of `properties`, the value Schema of `items` is
205207

206208
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...
207209

208-
209210
# Apply but modify - Boolean logic with subschemas
210211

211212
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.
222223

223224
```json caption="allOf/example1.schema.json"
224225
{
225-
"allOf": [ true, true, true]
226+
"allOf": [true, true, true]
226227
}
227228
```
228229

229230
```json caption="allOf/example2.schema.json"
230231
{
231-
"allOf": [ true, false, true]
232+
"allOf": [true, false, true]
232233
}
233234
```
234-
<div className="bg-blue-200 border-l-4 border-blue-500 px-4 py-1 relative text-blue-700">
235+
236+
<specialBox>
235237
<p><span className="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>
237239

238240
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`.
239241

@@ -243,16 +245,15 @@ The `true` and `false` Boolean Schemas in this example could be any subschemas t
243245

244246
Let's take the two examples again, but use `anyOf` rather than `allOf`.
245247

246-
247248
```json caption="anyOf/example1.schema.json"
248249
{
249-
"anyOf": [ true, true, true]
250+
"anyOf": [true, true, true]
250251
}
251252
```
252253

253254
```json caption="anyOf/example2.schema.json"
254255
{
255-
"anyOf": [ true, false, true]
256+
"anyOf": [true, false, true]
256257
}
257258
```
258259

@@ -329,7 +330,8 @@ Let's go back to our array of people data, modify it, and say it represents an a
329330
"email": "[email protected]",
330331
"isStudent": true,
331332
"year": 1
332-
}, {
333+
},
334+
{
333335
"name": "Alice",
334336
"email": "[email protected]",
335337
"isTeacher": true,
@@ -343,15 +345,16 @@ To start, let's do the same as we did when creating our first schema. Copy the i
343345
```json caption="oneOf/example1.schema.json"
344346
{
345347
"items": {
346-
"oneOf":[
348+
"oneOf": [
347349
{
348350
"properties": {
349351
"name": { "type": "string" },
350352
"email": { "type": "string" },
351353
"isStudent": { "type": "boolean" },
352354
"year": { "type": "number" }
353355
}
354-
}, {
356+
},
357+
{
355358
"properties": {
356359
"name": { "type": "string" },
357360
"email": { "type": "string" },
@@ -376,7 +379,7 @@ Yikes! That's not what we want!
376379

377380
But why isn't it working? Why isn't the instance passing validation?
378381

379-
__What do we know?__
382+
**What do we know?**
380383

381384
The validator is "failing fast". This means it's stopping after the first error.
382385

@@ -430,4 +433,4 @@ All feedback is welcome. If you have questions or comments, you can find me on t
430433
- [JSON Schema live playground (hyperjump validator) for all drafts (from draft-04)](https://json-schema.hyperjump.io)
431434
- [Links to RFC specification documents](/specification)
432435

433-
Photo by Heidi Fin on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
436+
Photo by Heidi Fin on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

0 commit comments

Comments
 (0)