More

Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>

Author: jviotti

content/2019-09/applicator/additionalProperties.markdown

@@ -43,34 +43,33 @@ related:
 
 The `additionalProperties` keyword restricts object instance properties not
 described by the _sibling_ [`properties`]({{< ref
-"2020-12/applicator/properties"
->}}) and [`patternProperties`]({{< ref "2020-12/applicator/patternproperties"
->}}) keywords (if any), to validate against the given subschema. Information
-about the properties that this keyword was evaluated for is reported using
-annotations.
+"2019-09/applicator/properties" >}}) and [`patternProperties`]({{< ref
+"2019-09/applicator/patternproperties" >}}) keywords (if any), to validate
+against the given subschema. Information about the properties that this keyword
+was evaluated for is reported using annotations.
 
 {{<common-pitfall>}}The use of the [`properties`]({{< ref
-"2020-12/applicator/properties" >}}) keyword **does not prevent the presence of
-other properties** in the object instance and **does not enforce the presence
-of the declared properties**. In other words, additional data that is not
-explicitly prohibited is permitted by default. This is intended behaviour to
-ease schema evolution (open schemas are backwards compatible by default) and to
-enable highly-expressive constraint-driven schemas.
-
-If you want to restrict instances to only contain the properties you declared,
-you must set this keyword to the boolean schema `false`, and if you want to
-enforce the presence of certain properties, you must use the [`required`]({{<
-ref "2020-12/validation/required" >}}) keyword accordingly.
+"2019-09/applicator/properties" >}}) keyword **does not prevent the presence
+of other properties** in the object instance and **does not enforce the
+presence of the declared properties**. In other words, additional data that
+is not explicitly prohibited is permitted by default. This is intended
+behaviour to ease schema evolution (open schemas are backwards compatible by
+default) and to enable highly-expressive constraint-driven schemas.
+
+If you want to restrict instances to only contain the properties you
+declared, you must set this keyword to the boolean schema `false`, and if you
+want to enforce the presence of certain properties, you must use the
+[`required`]({{< ref "2019-09/validation/required" >}}) keyword accordingly.
 {{</common-pitfall>}}
 
 {{<learning-more>}}While the most common use of this keyword is setting it to
-the boolean schema `false` to prevent additional properties, it is possible to
-set it to a satisfiable schema. Doing this, while omitting the
-[`properties`]({{< ref "2020-12/applicator/properties" >}}) and
-[`patternProperties`]({{< ref "2020-12/applicator/patternproperties" >}})
+the boolean schema `false` to prevent additional properties, it is possible
+to set it to a satisfiable schema. Doing this, while omitting the
+[`properties`]({{< ref "2019-09/applicator/properties" >}}) and
+[`patternProperties`]({{< ref "2019-09/applicator/patternproperties" >}})
 keywords, is an elegant way of describing how the value of every property in
-the object instance must look like independently of its
-name.{{</learning-more>}}
+the object instance must look like independently of its name.
+{{</learning-more>}}
 
 {{<constraint-warning `object`>}}
 

content/2019-09/applicator/allOf.markdown

@@ -35,21 +35,22 @@ conjunction](https://en.wikipedia.org/wiki/Logical_conjunction) (AND)
 operation, as instances are valid if they satisfy every constraint of every
 subschema (the intersection of the constraints).
 
-{{<common-pitfall>}} Wrapping a single instance of the [`$ref`](../../core/ref)
-or [`$dynamicRef`](../../core/dynamicref) keyword in an `allOf` operator is an
+{{<common-pitfall>}} Wrapping a single instance of the [`$ref`]({{< ref
+"2019-09/core/ref" >}}) or [`$recursiveRef`]({{< ref
+"2019-09/core/recursiveref" >}}) keyword in an `allOf` operator is an
 anti-pattern.
 
 This practice has historical roots. In JSON Schema [Draft 7](/draft7) and
-earlier versions, any subschema declaring the `$ref` keyword was considered to
-be a _reference object_ and any other sibling keyword was silently ignored. As
-a consequence, subschemas with references that made use of other keywords had
-to artificially wrap the reference into its own subschema.
+earlier versions, any subschema declaring the `$ref` keyword was considered
+to be a _reference object_ and any other sibling keyword was silently ignored.
+As a consequence, subschemas with references that made use of other keywords
+had to artificially wrap the reference into its own subschema.
 {{</common-pitfall>}}
 
 {{<best-practice>}}This keyword typically has a single use case: combining
 _multiple_ schemas through the use of (internal or external) references. If
-this is not the case, prefer elevating the keywords of every subschema to the
-outer schema and avoid using this keyword.  {{</best-practice>}}
+this is not the case, prefer elevating the keywords of every subschema to
+the outer schema and avoid using this keyword.  {{</best-practice>}}
 
 This keyword is equivalent to the `&&` operator found in most programming
 languages. For example:

content/2019-09/applicator/anyOf.markdown

@@ -29,19 +29,19 @@ related:
 The {{<link keyword="anyOf" vocabulary="applicator">}} keyword restricts
 instances to validate against _at least one_ (but potentially multiple) of the
 given subschemas. This keyword represents a [logical
-disjunction](https://en.wikipedia.org/wiki/Logical_disjunction) (OR) operation,
-as instances are valid if they satisfy the constraints of one or more
-subschemas (the union of the constraints).
+disjunction](https://en.wikipedia.org/wiki/Logical_disjunction) (OR)
+operation, as instances are valid if they satisfy the constraints of one or
+more subschemas (the union of the constraints).
 
 {{<learning-more>}}Keep in mind that when collecting annotations, the JSON
 Schema implementation will need to exhaustively evaluate every subschema past
-the first match instead of short-circuiting validation, potentially introducing
-additional computational overhead.
+the first match instead of short-circuiting validation, potentially
+introducing additional computational overhead.
 
 For example, consider 3 subschemas where the instance validates against the
 first. When not collecting annotations, validation will stop after evaluating
-the first subschema. However, when collecting annotations, evaluation will have
-to proceed past the first subschema in case the others emit
+the first subschema. However, when collecting annotations, evaluation will
+have to proceed past the first subschema in case the others emit
 annotations.{{</learning-more>}}
 
 This keyword is equivalent to the `||` operator found in most programming

content/2019-09/applicator/dependentSchemas.markdown

@@ -22,12 +22,12 @@ related:
 
 The `dependentSchemas` keyword restricts object instances to validate against
 one or more of the given subschemas if the corresponding properties are
-defined.  Note that the given subschemas are evaluated against the object that
-defines the property dependency.
+defined.  Note that the given subschemas are evaluated against the object
+that defines the property dependency.
 
 {{<learning-more>}}The [`dependentRequired`]({{< ref
-"2020-12/validation/dependentrequired" >}}) keyword is a specialisation of this
-keyword to describe object dependencies that only consist in property
+"2019-09/validation/dependentrequired" >}}) keyword is a specialisation of
+this keyword to describe object dependencies that only consist in property
 requirement.{{</learning-more>}}
 
 {{<constraint-warning `object`>}}

content/2019-09/applicator/else.markdown

@@ -34,14 +34,16 @@ instances to validate against the given subschema if the {{<link keyword="if"
 vocabulary="applicator">}} sibling keyword failed to validate against the
 instance.
 
-{{<common-pitfall>}} This keyword has no effect if the [`if`]({{< ref "if" >}})
-keyword is not declared within the same subschema.  {{</common-pitfall>}}
+{{<common-pitfall>}} This keyword has no effect if the [`if`]({{< ref
+"2019-09/applicator/if" >}}) keyword is not declared within the same
+subschema. {{</common-pitfall>}}
 
-{{<best-practice>}} The [`if`]({{< ref "if" >}}), [`then`]({{< ref "then" >}}),
-and [`else`]({{< ref "else" >}}) keywords can be thought of as imperative
-variants of the [`anyOf`]({{< ref "anyOf" >}}) keyword, and both approaches are
-equally capable of describing arbitrary conditions. Choose the one that more
-elegantly describes your desired constraints.{{</best-practice>}}
+{{<best-practice>}} The [`if`]({{< ref "2019-09/applicator/if" >}}),
+[`then`]({{< ref "2019-09/applicator/then" >}}), and `else` keywords can be
+thought of as imperative variants of the [`anyOf`]({{< ref
+"2019-09/applicator/anyof" >}}) keyword, and both approaches are equally
+capable of describing arbitrary conditions. Choose the one that more elegantly
+describes your desired constraints.{{</best-practice>}}
 
 ## Examples
 

content/2019-09/applicator/if.markdown

@@ -34,17 +34,19 @@ vocabulary="applicator">}} sibling subschemas (if present). Note that the
 evaluation outcome of this subschema controls which other subschema to apply
 (if any) but has no direct effect on the overall validation result.
 
-{{<best-practice>}} The [`if`]({{< ref "if" >}}), [`then`]({{< ref "then" >}}),
-and [`else`]({{< ref "else" >}}) keywords can be thought of as imperative
-variants of the [`anyOf`]({{< ref "anyOf" >}}) keyword, and both approaches are
-equally capable of describing arbitrary conditions. Choose the one that more
-elegantly describes your desired constraints.{{</best-practice>}}
+{{<best-practice>}} The `if`, [`then`]({{< ref "2019-09/applicator/then"
+>}}), and [`else`]({{< ref "2019-09/applicator/else" >}}) keywords can be
+thought of as imperative variants of the [`anyOf`]({{< ref
+"2019-09/applicator/anyof" >}}) keyword, and both approaches are equally
+capable of describing arbitrary conditions. Choose the one that more elegantly
+describes your desired constraints.{{</best-practice>}}
 
 {{<learning-more>}} This keyword has no effect if neither the [`then`]({{< ref
-"then" >}}) nor [`else`]({{< ref "else" >}}) keywords are declared within the
-same subschema. However, when collecting annotations, the JSON Schema
-implementation will still need to evaluate the [`if`]({{< ref "if" >}}) keyword
-in case its subschema emits annotations.{{</learning-more>}}
+"2019-09/applicator/then" >}}) nor [`else`]({{< ref
+"2019-09/applicator/else" >}}) keywords are declared within the same subschema.
+However, when collecting annotations, the JSON Schema implementation will still
+need to evaluate the `if` keyword in case its subschema emits annotations.
+{{</learning-more>}}
 
 The {{<link keyword="if" vocabulary="applicator">}}, {{<link keyword="then"
 vocabulary="applicator">}}, and {{<link keyword="else"
@@ -59,9 +61,10 @@ JSON Schema is a [constraint-driven
 language](https://modern-json-schema.com/json-schema-is-a-constraint-system).
 Therefore, omitting either the {{<link keyword="then"
 vocabulary="applicator">}} or the {{<link keyword="else"
-vocabulary="applicator">}} keywords is equivalent to setting the corresponding
-part of the ternary conditional operation to the boolean true. In other words,
-undefined consequent or alternative paths lead to success.  For example:
+vocabulary="applicator">}} keywords is equivalent to setting the
+corresponding part of the ternary conditional operation to the boolean true.
+In other words, undefined consequent or alternative paths lead to success.
+For example:
 
 ```c
 // If `then` is missing

content/2019-09/applicator/items.markdown

@@ -45,16 +45,18 @@ related:
 The `items` keyword is used to validate array items and has two different modes
 of operation depending on its value:
 
-**Schema Form**: When set to a schema, `items` validates that all items in the
-array instance validate against the given subschema. Whether this keyword was
-evaluated against any item of the array instance is reported using annotations.
-
-**Array Form**: When set to an array of schemas, `items` validates each item in
-the array instance against the subschema at the corresponding position (tuple
-validation). Items beyond the length of the `items` array can be validated using
-the [`additionalItems`]({{< ref "2019-09/applicator/additionalitems" >}})
-keyword. The annotation reports the largest index to which a subschema was
-applied, or true if it was applied to every item.
+**Schema Form**: When set to a schema, `items` validates that all items in
+the array instance validate against the given subschema. Whether this keyword
+was evaluated against any item of the array instance is reported using
+annotations.
+
+**Array Form**: When set to an array of schemas, `items` validates each item
+in the array instance against the subschema at the corresponding position
+(tuple validation). Items beyond the length of the `items` array can be
+validated using the [`additionalItems`]({{< ref
+"2019-09/applicator/additionalitems" >}}) keyword. The annotation reports the
+largest index to which a subschema was applied, or true if it was applied to
+every item.
 
 {{<common-pitfall>}}This keyword does not prevent an array instance from being
 empty. If needed, use the [`minItems`]({{< ref "2019-09/validation/minitems"

content/2019-09/applicator/not.markdown

@@ -46,7 +46,7 @@ might seem counter-intuitive, consider the following cases:
 {{</learning-more>}}
 
 {{<best-practice>}} Avoid the use of this keyword (usually negating the
-[`required`]({{< ref "/2020-12/validation/required" >}}) keyword) to prohibit
+[`required`]({{< ref "2019-09/validation/required" >}}) keyword) to prohibit
 specific object properties from being defined. Instead, use the
 [`properties`]({{< ref "properties" >}}) keyword and set the disallowed object
 properties to the `false` boolean schema.{{</best-practice>}}

content/2019-09/applicator/oneOf.markdown

@@ -29,24 +29,25 @@ related:
 The {{<link keyword="oneOf" vocabulary="applicator">}} keyword restricts
 instances to validate against _exactly one_ (and only one) of the given
 subschemas and fail on the rest. This keyword represents a [logical exclusive
-disjunction](https://en.wikipedia.org/wiki/Exclusive_or) (XOR) operation. In
-practice, the vast majority of schemas don't require exclusive disjunction
+disjunction](https://en.wikipedia.org/wiki/Exclusive_or) (XOR) operation.
+In practice, the vast majority of schemas don't require exclusive disjunction
 semantics but a simple disjunction. If you are not sure, the {{<link
 keyword="anyOf" vocabulary="applicator">}} keyword is probably a better fit.
 
 {{<common-pitfall>}}
 
 Avoid this keyword unless you absolutely need exclusive disjunction
-semantics, which is rarely the case.
-As its name implies, this keyword enforces the instance to
-be valid against **only one of its subschemas**. Therefore, a JSON Schema
-implementation will exhaustively evaluate every subschema to make sure the rest
-fails, potentially introducing unnecessary computational overhead.
+semantics, which is rarely the case. As its name implies, this keyword
+enforces the instance to be valid against **only one of its subschemas**.
+Therefore, a JSON Schema implementation will exhaustively evaluate every
+subschema to make sure the rest fails, potentially introducing unnecessary
+computational overhead.
 
 {{</common-pitfall>}}
 
 This keyword is equivalent to the following complex boolean construct that
-combines the `||`, `&&`, and `!` operators found in most programming languages:
+combines the `||`, `&&`, and `!` operators found in most programming
+languages:
 
 ```c
 bool valid = (A && !B && !C) || (!A && B && !C) || (!A && !B && C);

content/2019-09/applicator/patternProperties.markdown

@@ -48,7 +48,7 @@ definitions. Information about the properties that this keyword was evaluated
 for is reported using annotations.
 
 {{<common-pitfall>}} This keyword is evaluated independently of the
-[`properties`]({{< ref "2020-12/applicator/properties" >}}) keyword. If an
+[`properties`]({{< ref "2019-09/applicator/properties" >}}) keyword. If an
 object property is described by both keywords, then both subschemas must
 successfully validate against the given property for validation to succeed.
 Furthermore, an instance property may match more than one regular expression