adjust page indexes; fix section numbers

Author: gregsdennis

.jekyll-metadata

@@ -4,7 +4,7 @@ title: A Vocabulary for Accessing Data Stored in JSON (2023)
 bookmark: data (2023)
 permalink: /schema/vocabs/data-2023/
 icon: fas fa-tag
-order: "1.8.4"
+order: "01.8.2"
 ---
 ## 1. Purpose {#purpose}
 
@@ -29,17 +29,17 @@ The meta-schema which validates keyword usage for this vocabulary can be found a
 
 ## 3. Definitions {#definitions}
 
-### 3.1 Formed Schema {#formed-schema}
+### 3.1. Formed Schema {#formed-schema}
 
 The schema object created as a result of dereferencing all of the values in either the `data` or `optionalData` keywords as described in section 4.1.  That is, each keyword produces an independent formed schema.
 
-### 3.2 Host Schema {#host-schema}
+### 3.2. Host Schema {#host-schema}
 
 The schema object which contains either the `data` or `optionalData` keyword.  The processing rules that govern this schema also govern the formed schema, as specified by section 4.2.
 
 ## 4. The `data` and `optionalData` Keywords {#data-keyword}
 
-### 4.1 Syntax and Semantics {#semantics}
+### 4.1. Syntax and Semantics {#semantics}
 
 The values of `data` and `optionalData` must be objects.  The keys of these objects are interpreted as JSON Schema keywords, and the values MUST be one of
 
@@ -59,7 +59,7 @@ The values of `data` and `optionalData` must be objects.  The keys of these obje
 
 The validation and annotation results of `data` and `optionalData` are those of the formed schemas.  More detail regarding output can be found in section 4.4.
 
-### 4.2 Contextual Behavior {#behavior}
+### 4.2. Contextual Behavior {#behavior}
 
 `data` and `optionalData` MUST be processed contextually in the same manner as the host schema.  Specifically,
 
@@ -71,7 +71,7 @@ Implementations SHOULD validate that the resolved data forms a valid schema agai
 > It is not necessary for an implementation to validate the formed schema using the meta-schema.  Other mechanisms internal to the implementation (such as deserialization) may suffice to perform this task.
 {: .prompt-info }
 
-### 4.3 Resolving data {#resolution}
+### 4.3. Resolving data {#resolution}
 
 The string values within `data` and `optionalData` are dereferenced in different ways depending on the format of the value.
 
@@ -85,29 +85,29 @@ Because JSON Pointers and Relative JSON Pointers are syntactically valid IRIs, t
 
 For each successfully resolved reference, the full value at the specified location MUST be returned.
 
-#### 4.3.1 Reference Resolution Failure {#resolution-failure}
+#### 4.3.1. Reference Resolution Failure {#resolution-failure}
 
 The `data` and `optionalData` keywords differ only in their behavior when resolving a reference fails.
 
 For `data`, if a reference cannot be resolved, or if a resolved value is not valid for the associated keyword, evaluation MUST halt.  Implementations SHOULD use native features of their language to report the failure as appropriate.  Implementations MAY continue to attempt to resolve other references so that multiple resolution failures can be reported together, however further schema evaluation MUST NOT continue.
 
 For `optionalData`, if a reference cannot be resolved, or if a resolved value is not valid for the associated keyword, that keyword MUST be ignored and excluded from the resulting formed schema.  As a consequence, evaluation MUST proceed as if that keyword is absent.
 
-#### 4.3.2 External Data Access {#external}
+#### 4.3.2. External Data Access {#external}
 
 Implementations SHOULD provide a means to pre-load and cache any external references prior to evaluation but MAY be configured to fetch external documents at evaluation time.  Documents fetched from IRIs which contain a JSON Pointer fragment MUST be interpreted using a media type, such as `application/schema-instance+json`, that allows resolution of such fragments.
 
 Users should be aware that fetching data from external locations may carry certain security risks not covered by this document.
 
-### 4.4 Output {#output}
+### 4.4. Output {#output}
 
 The evaluation output of the formed schema is reported into the overall schema output incorporating "data" or "optionalData" into the evaluation path as appropriate and following on with additional pointer segments as navigable within the formed schema.
 
 Annotation results of the formed schema are retained as per the host schema so that they can be processed by other keywords such as `unevaluatedItems` and `unevaluatedProperties`.
 
 ## 5. Examples {#examples}
 
-### 5.1 `data` Example {#data-example}
+### 5.1. `data` Example {#data-example}
 
 The following defines a schema to validate an object instance with a `bar` property that must contain an numeric value less than or equal to the value in the instance's `foo` property.
 
@@ -144,7 +144,7 @@ The following shows how a change in the `foo` property, or its absence, can affe
 { "bar": 20 }
 ```
 
-### 5.2 `optionalData` Example {#optionalData-example}
+### 5.2. `optionalData` Example {#optionalData-example}
 
 In the following schema, `bar` is required to be less than `foo`, however `foo` itself is not required.
 

_docs/schema/vocabs/data-2023.md

@@ -4,7 +4,7 @@ title: A Vocabulary for Identifying Uniqueness of Array Items
 bookmark: uniqueKeys
 permalink: /schema/vocabs/uniquekeys/
 icon: fas fa-tag
-order: "01.8.2"
+order: "01.8.3"
 ---
 
 > This vocabulary will soon be deprecated and replaced by the more general [Array Extensions vocabulary](/schema/vocabs/array-ext).

_docs/schema/vocabs/unique-keys.md

@@ -4,7 +4,7 @@ title: A Vocabulary for Extended Validation of Arrays (WIP)
 bookmark: Array Extensions
 permalink: /schema/vocabs/array-ext/
 icon: fas fa-tag
-order: "01.8.3"
+order: "01.8.4"
 ---
 
 > This vocabulary is a work in progress.  It is intended to deprecate and replace the existing [`uniqueKeys` vocabulary](/schema/vocabs/uniquekeys) by adding some more array-centric functionality.  Comments, questions, and ideas are welcome as issues in the [main `json-everything` repository](https://github.com/gregsdennis/json-everything).