diff --git a/components/StyledMarkdown.tsx b/components/StyledMarkdown.tsx index a56cd48ee..ed34e392c 100644 --- a/components/StyledMarkdown.tsx +++ b/components/StyledMarkdown.tsx @@ -191,6 +191,15 @@ const StyledMarkdownBlock = ({ markdown }: { markdown: string }) => {

), }, + + AdditionalInfoDiv: { + component: ({ children }) => ( +
+ {children} +
+ ), + }, + a: { component: ({ children, href, title, className }) => { if (!href) return children; diff --git a/pages/blog/posts/applicability-json-schema-fundamentals-part-1.md b/pages/blog/posts/applicability-json-schema-fundamentals-part-1.md index 729ac9c2e..f62e9fbb4 100644 --- a/pages/blog/posts/applicability-json-schema-fundamentals-part-1.md +++ b/pages/blog/posts/applicability-json-schema-fundamentals-part-1.md @@ -30,16 +30,16 @@ The validation process for JSON Schema begins with applying the whole JSON Schem 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.) -
+

Vocabulary check

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!

-
+ 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. -
+

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.

-
+ # Subschema application - Validating Objects and Arrays @@ -134,9 +134,9 @@ Luckily, picking this up with our Schema is simple. The `additionalProperties` k 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. -
+

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 learning resources on `additionalProperties`.

-
+ Finally, what if we expect an Object, but are given an Array or another non-object type? @@ -177,9 +177,9 @@ Note, `type` takes an Array of types. It may be that your instance is allowed to ## Validating Arrays -
+

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 learning resources for Array validation.

-
+ 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. @@ -231,9 +231,9 @@ This sounds simple, but let's look at some examples. "allOf": [ true, false, true] } ``` -
+

Remember: A Boolean is a valid schema that always produces the assertion result of its value, regardless of the instance data.

-
+ 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`.