Fix: Interlink terms in UJS with the glossary

pages/understanding-json-schema/_index.md

@@ -8,7 +8,7 @@ Understanding JSON Schema
 
 <img src="understanding/octopus.svg" className="w-1/2 float-right" />
 
-JSON Schema is a powerful tool for validating the structure of JSON
+[JSON](../learn/glossary#json) [Schema](../learn/glossary#schema) is a powerful tool for validating the structure of JSON
 data. However, learning to use it by reading its specification is like
 learning to drive a car by looking at its blueprints. You don\'t need to
 know how an electric motor fits together if all you want to do is pick
@@ -17,7 +17,7 @@ instructor for JSON Schema. It\'s for those that want to write it and
 understand it, but maybe aren\'t interested in building their own
 car—er, writing their own JSON Schema validator — just yet.
 
-> This tutorial describes JSON Schema draft 2020-12. Earlier versions of
+> This tutorial describes JSON Schema [draft](../learn/glossary#draft) 2020-12. Earlier versions of
 JSON Schema are not completely compatible with the format
 described here, but for the most part, those differences are noted
 in the text.

pages/understanding-json-schema/about.md

@@ -6,7 +6,7 @@ section: "docs"
 If you\'ve ever used XML Schema, RelaxNG or ASN.1 you probably already
 know what a schema is and you can happily skip along to the next
 section. If all that sounds like gobbledygook to you, you\'ve come to
-the right place. To define what JSON Schema is, we should probably first
+the right place. To define what [JSON](../learn/glossary#json) [Schema](../learn/glossary#schema) is, we should probably first
 define what JSON is.
 
 JSON stands for \"JavaScript Object Notation\", a simple data

pages/understanding-json-schema/basics.md

@@ -3,9 +3,9 @@ title: The basics
 section: docs
 ---
 
-In [What is a schema?](../understanding-json-schema/about), we described what a schema is,
+In [What is a schema?](../understanding-json-schema/about), we described what a [schema](../learn/glossary#schema) is,
 and hopefully justified the need for schema languages. Here, we proceed
-to write a simple JSON Schema.
+to write a simple [JSON](../learn/glossary#json) Schema.
 
 ## Hello, World!
 
@@ -78,7 +78,7 @@ false
 
 Of course, we wouldn\'t be using JSON Schema if we wanted to just accept
 any JSON document. The most common thing to do in a JSON Schema is to
-restrict to a specific type. The `type` keyword is used for that.
+restrict to a specific type. The `type` [keyword](../learn/glossary#keyword) is used for that.
 
 > When this book refers to JSON Schema "keywords", it means the
 "key" part of the key/value pair in an object.  Most of the work
@@ -105,7 +105,7 @@ The `type` keyword is described in more detail in [here](../understanding-json-s
 
 ## Declaring a JSON Schema
 
-It\'s not always easy to tell which draft a JSON Schema is using. You
+It\'s not always easy to tell which [draft](../learn/glossary#draft) a JSON Schema is using. You
 can use the `$schema` keyword to declare which version of the JSON
 Schema specification the schema is written to. See [$schema](../understanding-json-schema/reference/schema#schema)
 for more information. It\'s generally good practice to include it,

pages/understanding-json-schema/conventions.md

@@ -5,11 +5,11 @@ title: "Conventions used in this documentation"
 
 ## Language-specific notes
 
-The names of the basic types in JavaScript and JSON can be confusing
+The names of the basic types in JavaScript and [JSON](../learn/glossary#json) can be confusing
 when coming from another dynamic language. I\'m a Python programmer by
 day, so I\'ve notated here when the names for things are different from
 what they are in Python, and any other Python-specific advice for using
-JSON and JSON Schema. I\'m by no means trying to create a Python bias to
+JSON and JSON [Schema](../learn/glossary#schema). I\'m by no means trying to create a Python bias to
 this book, but it is what I know, so I\'ve started there. In the long
 run, I hope this book will be useful to programmers of all stripes, so
 if you\'re interested in translating the Python references into Algol-68
@@ -40,7 +40,7 @@ In Swift, JSON can be read using the `JSONDecoder` class.
 ## Draft-specific notes
 
 The JSON Schema standard has been through a number of revisions or
-\"drafts\". The current version is Draft 2020-12, but some older drafts
+[\"drafts\"](../learn/glossary#draft). The current version is Draft 2020-12, but some older drafts
 are still widely used as well.
 
 The text is written to encourage the use of Draft 2020-12 and gives

pages/understanding-json-schema/reference/annotations.md

@@ -3,7 +3,7 @@ title: "Annotations"
 section: docs
 ---
 
-JSON Schema includes a few keywords, that aren\'t strictly used for
+[JSON](../../learn/glossary#json) [Schema](../../learn/glossary#schema) includes a few [keywords](../../learn/glossary#keyword), that aren\'t strictly used for
 validation, but are used to describe parts of a schema. None of these
 \"annotation\" keywords are required, but they are encouraged for good
 practice, and can make your schema \"self-documenting\".
@@ -43,7 +43,7 @@ you can set a value with a `PUT` request, but it would not be included
 when retrieving that record with a `GET` request.
 
 <Star label="New in draft 2019-09" />
-The `deprecated` keyword is a boolean that indicates that the instance
+The `deprecated` keyword is a boolean that indicates that the [instance](../../learn/glossary#instance)
 value the keyword applies to should not be used and may be removed in
 the future.
 

pages/understanding-json-schema/reference/array.md

@@ -5,7 +5,7 @@ section: docs
 
 <Keywords label="single: array" />
 
-Arrays are used for ordered elements. In JSON, each element in an array
+Arrays are used for ordered elements. In [JSON](../../learn/glossary#json), each element in an array
 may be of a different type.
 
 [tabs-start "Language-specific info"]
@@ -49,7 +49,7 @@ In Swift, "array" is analogous to the `Array` type.
 There are two ways in which arrays are generally used in JSON:
 
 - **List validation:** a sequence of arbitrary length where each item
-    matches the same schema.
+    matches the same [schema](../../learn/glossary#schema).
 - **Tuple validation:** a sequence of fixed length where each item may
     have a different schema. In this usage, the index (or location) of
     each item is meaningful as to how the value is interpreted. (This
@@ -59,7 +59,7 @@ There are two ways in which arrays are generally used in JSON:
 ## Items[#items]
 
 List validation is useful for arrays of arbitrary length where each item
-matches the same schema. For this kind of array, set the `items` keyword
+matches the same schema. For this kind of array, set the `items` [keyword](../../learn/glossary#keyword)
 to a single schema that will be used to validate all of the items in the
 array.
 
@@ -125,7 +125,7 @@ the first element of the input array, the second element validates the
 second element of the input array, etc.
 
 <Infobox label="Draft-specific info">
-In Draft 4 - 2019-09, tuple validation was handled by an alternate
+In [Draft](../../learn/glossary#draft) 4 - 2019-09, tuple validation was handled by an alternate
    form of the `items` keyword. When `items` was an array of
    schemas instead of a single schema, it behaved the way
    `prefixItems` behaves.
@@ -306,8 +306,8 @@ specifies that no extra values should exist.
 ["foo", 42, null]
 ```
 
-Note that `items` doesn't "see inside" any instances of `allOf`,
-`anyOf`, or `oneOf` in the same subschema. So in this next example,
+Note that `items` doesn't "see inside" any [instances](../../learn/glossary#instance) of `allOf`,
+`anyOf`, or `oneOf` in the same [subschema](../../learn/glossary#subschema). So in this next example,
 `items` ignores `allOf` and thus fails to validate.
 
 ```json

pages/understanding-json-schema/reference/boolean.md

@@ -7,7 +7,7 @@ section: docs
 
 The boolean type matches only two special values: `true` and `false`.
 Note that values that *evaluate* to `true` or `false`, such as 1 and 0,
-are not accepted by the schema.
+are not accepted by the [schema](../../learn/glossary#schema).
 
 [tabs-start "Language-specific info"]
 

pages/understanding-json-schema/reference/combining.md

@@ -5,7 +5,7 @@ section: docs
 
 <Keywords label="schema composition" />
 
-JSON Schema includes a few keywords for combining schemas together. Note
+[JSON](../../learn/glossary#json) [Schema](../../learn/glossary#schema) includes a few [keywords](../../learn/glossary#keyword) for combining schemas together. Note
 that this doesn\'t necessarily mean combining schemas from multiple
 files or JSON trees, though these facilities help to enable that and are
 described in [Structuring a complex schema](../../understanding-json-schema/structuring). Combining schemas may be as
@@ -19,7 +19,7 @@ JSON Schema keywords.
 
 The keywords used to combine schemas are:
 
-- `allOf`: (AND) Must be valid against *all* of the subschemas
+- `allOf`: (AND) Must be valid against *all* of the [subschemas](../../learn/glossary#subschema)
 - `anyOf`: (OR) Must be valid against *any* of the subschemas
 - `oneOf`: (XOR) Must be valid against *exactly one* of the
     subschemas
@@ -58,7 +58,7 @@ A snippet of the British royal family tree
 ```
 
 > [allOf](#allof) can not be used to \"extend\" a schema to add more
-details to it in the sense of object-oriented inheritance. Instances
+details to it in the sense of object-oriented inheritance. [Instances](../../learn/glossary#instance)
 must independently be valid against \"all of\" the schemas in the
 `allOf`. See the section on [Extending Closed Schemas](../../understanding-json-schema/reference/object#extending) for more
 information.

pages/understanding-json-schema/reference/comments.md

@@ -5,9 +5,9 @@ section: docs
 
 <Star label="New in draft 7" />
 
-The `$comment` keyword is strictly intended for adding comments to a
+The `$comment` [keyword](../../learn/glossary#keyword) is strictly intended for adding comments to a
 schema. Its value must always be a string. Unlike the annotations
-`title`, `description`, and `examples`, JSON schema implementations
+`title`, `description`, and `examples`, [JSON](../../learn/glossary#json) [schema](../../learn/glossary#schema) [implementations](../../learn/glossary#implementation)
 aren\'t allowed to attach any meaning or behavior to it whatsoever, and
 may even strip them at any time. Therefore, they are useful for leaving
 notes to future editors of a JSON schema, but should not be used to

pages/understanding-json-schema/reference/conditionals.md

@@ -7,9 +7,9 @@ section: docs
 
 ## dependentRequired[#dependentRequired]
 
-The `dependentRequired` keyword conditionally requires that certain
+The `dependentRequired` [keyword](../../learn/glossary#keyword) conditionally requires that certain
 properties must be present if a given property is present in an object.
-For example, suppose we have a schema representing a customer. If you
+For example, suppose we have a [schema](../../learn/glossary#schema) representing a customer. If you
 have their credit card number, you also want to ensure you have a
 billing address. If you don\'t have their credit card number, a billing
 address would not be required. We represent this dependency of one
@@ -47,7 +47,7 @@ a `billing_address` property must also be present:
   "billing_address": "555 Debtor's Lane"
 }
 ```
-This instance has a `credit_card`, but it's missing a `billing_address`.
+This [instance](../../learn/glossary#instance) has a `credit_card`, but it's missing a `billing_address`.
 
 ```json
 // props { "indent": true, "valid": false }
@@ -116,7 +116,7 @@ This has a ``billing_address``, but is missing a ``credit_card``.
 ```
 
 <Infobox label="Draft-specific info">
-Previously to Draft 2019-09, ``dependentRequired`` and
+Previously to [Draft](../../learn/glossary#draft) 2019-09, ``dependentRequired`` and
    ``dependentSchemas`` were one keyword called ``dependencies``. If
    the dependency value was an array, it would behave like
    ``dependentRequired`` and if the dependency value was a schema, it
@@ -127,7 +127,7 @@ Previously to Draft 2019-09, ``dependentRequired`` and
 
 ## dependentSchemas [#dependentSchemas]
 
-The `dependentSchemas` keyword conditionally applies a subschema when a
+The `dependentSchemas` keyword conditionally applies a [subschema](../../learn/glossary#subschema) when a
 given property is present. This schema is applied in the same way
 [allOf](../../understanding-json-schema/reference/combining#allof) applies schemas. Nothing is merged or extended. Both
 schemas apply independently.
@@ -431,7 +431,7 @@ Before Draft 7, you can express an \"if-then\" conditional using the
 [Schema composition](../../understanding-json-schema/reference/combining) keywords and a boolean algebra concept called
 \"implication\". `A -> B` (pronounced, A implies B) means that if A is
 true, then B must also be true. It can be expressed as `!A || B` which
-can be expressed as a JSON Schema.
+can be expressed as a [JSON](../../learn/glossary#json) [Schema](../../learn/glossary#schema).
 
 ```json
 // props { "isSchema": true }

pages/understanding-json-schema/reference/const.md

@@ -5,7 +5,7 @@ section: docs
 
 <Star label="New in draft 6" />
 
-The `const` keyword is used to restrict a value to a single value.
+The `const` [keyword](../../learn/glossary#keyword) is used to restrict a value to a single value.
 
 For example, if you only support shipping to the United States for
 export reasons:

pages/understanding-json-schema/reference/enum.md

@@ -3,7 +3,7 @@ title: "Enumerated values"
 section: docs
 ---
 
-The `enum` keyword is used to restrict a value to a fixed set of values.
+The `enum` [keyword](../../learn/glossary#keyword) is used to restrict a value to a fixed set of values.
 It must be an array with at least one element, where each element is
 unique.
 

pages/understanding-json-schema/reference/non_json_data.md

@@ -7,7 +7,7 @@ section: docs
 
 <Star label="New in draft 7" />
 
-JSON schema has a set of keywords to describe and optionally validate
+[JSON](../../learn/glossary#json) [schema](../../learn/glossary#schema) has a set of [keywords](../../learn/glossary#keyword) to describe and optionally validate
 non-JSON data stored inside JSON strings. Since it would be difficult to
 write validators for many media types, JSON schema validators are not
 required to validate the contents of JSON strings based on these

pages/understanding-json-schema/reference/null.md

@@ -3,9 +3,9 @@ title: "null"
 section: docs
 ---
 
-When a schema specifies a `type` of `null`, it has only one acceptable value: `null`.
+When a [schema](../../learn/glossary#schema) specifies a `type` of `null`, it has only one acceptable value: `null`.
 
-> It's important to remember that in JSON, `null` isn't equivalent to something being absent. See [Required Properties](../../understanding-json-schema/reference/object#required) for an example.
+> It's important to remember that in [JSON](../../learn/glossary#json), `null` isn't equivalent to something being absent. See [Required Properties](../../understanding-json-schema/reference/object#required) for an example.
 
 [tabs-start "Language-specific info"]
 

pages/understanding-json-schema/reference/numeric.md

@@ -5,8 +5,8 @@ section: docs
 
 <Keywords label="single: integer single: number single: types; numeric" />
 
-There are two numeric types in JSON Schema: [integer](#integer) and [number](#number).
-They share the same validation keywords.
+There are two numeric types in [JSON](../../learn/glossary#json) [Schema](../../learn/glossary#schema): [integer](#integer) and [number](#number).
+They share the same validation [keywords](../../learn/glossary#keyword).
 
 > JSON has no standard way to represent complex numbers, so there is no
 way to test for them in JSON Schema.

pages/understanding-json-schema/reference/object.md

@@ -5,7 +5,7 @@ section: docs
 
 <Keywords label="single: object" />
 
-Objects are the mapping type in JSON. They map \"keys\" to \"values\".
+Objects are the mapping type in [JSON](../../learn/glossary#json). They map \"keys\" to \"values\".
 In JSON, the \"keys\" must always be strings. Each of these pairs is
 conventionally referred to as a \"property\".
 
@@ -91,8 +91,8 @@ Using non-strings as keys is invalid JSON:
 ## Properties
 
 The properties (key-value pairs) on an object are defined using the
-`properties` keyword. The value of `properties` is an object, where each
-key is the name of a property and each value is a schema used to
+`properties` [keyword](../../learn/glossary#keyword). The value of `properties` is an object, where each
+key is the name of a property and each value is a [schema](../../learn/glossary#schema) used to
 validate that property. Any property that doesn\'t match any of the
 property names in the `properties` keyword is ignored by this keyword.
 
@@ -210,7 +210,7 @@ extra stuff, that is, properties whose names are not listed in the
 allowed.
 
 The value of the `additionalProperties` keyword is a schema that will be
-used to validate any properties in the instance that are not matched by
+used to validate any properties in the [instance](../../learn/glossary#instance) that are not matched by
 `properties` or `patternProperties`. Setting the `additionalProperties`
 schema to `false` means no additional properties will be allowed.
 
@@ -316,7 +316,7 @@ It must be a string:
 ### Extending Closed Schemas[#extending]
 
 It\'s important to note that `additionalProperties` only recognizes
-properties declared in the same subschema as itself. So,
+properties declared in the same [subschema](../../learn/glossary#subschema) as itself. So,
 `additionalProperties` can restrict you from \"extending\" a schema
 using [combining](../../understanding-json-schema/reference/combining) keywords such as [allOf](../../understanding-json-schema/reference/combining#allof). In
 the following example, we can see how the `additionalProperties` can
@@ -548,7 +548,7 @@ The `required` keyword takes an array of zero or more strings. Each of
 these strings must be unique.
 
 <Infobox label="Draft-specific info">
-In Draft 4, `required` must contain at least one string.
+In [Draft](../../learn/glossary#draft) 4, `required` must contain at least one string.
 </Infobox>
 
 In the following example schema defining a user record, we require that

pages/understanding-json-schema/reference/regular_expressions.md

@@ -6,7 +6,7 @@ section: docs
 <Keywords label="regular expressions" />
 
 The [pattern](../../understanding-json-schema/reference/string#regexp) and
-[patternProperties](../../understanding-json-schema/reference/object#regexp) keywords use regular expressions to
+[patternProperties](../../understanding-json-schema/reference/object#regexp) [keywords](../../learn/glossary#keyword) use regular expressions to
 express constraints. The regular expression syntax used is from
 JavaScript ([ECMA 262](https://www.ecma-international.org/publications-and-standards/standards/ecma-262/),
 specifically). However, that complete syntax is not widely supported,
@@ -49,7 +49,7 @@ described below.
     expression.
 -   `{x,y}?`, `{x,}?`: Non-greedy versions of the above expressions.
 -   Use only standard escapes like ``\n``, ``\r``, ``\t`` and keep 
-    in mind that you also need to do JSON escaping.
+    in mind that you also need to do [JSON](../../learn/glossary#json) escaping.
 
 Example
 -------