Name the split "dependencies" to "dependent*"

Upon further discussion, the grammatical approach that
is most intuitive was deemed to be that the string array
or schema's usage is dependent upon the presence or
absence of the instance property.

In at least some anecdotal reports, the nature and
direction of the "dependencies" concept proved confusing.
Others found it intuitive.  The revised wording aims
to explicitly tie the dependency direction to the
naming convention.

In addition, while there was some debate over the most
migration-friendly strategy, the decision is to leave
the old form of "dependencies" available as an extension,
and for at least one draft use the meta-schema to avoid
its redefinition.  Therefore both keywords resulting
from the split have been renamed.

"dependentSchemas" was also in the wrong section.  As an
in-place conditional applicator, it belongs with "if", "then",
and "else".  Not with the object child applicators.

Apparently, I had not made the meta-schema changes at all.
The "$comment" follows the precedent established from leaving
"definitions" in the meta-schema after the rename to "$defs".

Author: handrews

hyper-schema.json

@@ -16,7 +16,9 @@
     "properties": {
         "additionalItems": { "$ref": "#" },
         "additionalProperties": { "$ref": "#"},
+        "dependentSchemas": { "$ref": "#" },
         "dependencies": {
+            "$comment": "\"dependencies\" is no longer a keyword, but schema authors should avoid redefining it to facilitate a smooth transition to \"dependentSchemas\" and \"dependentRequired\"",
             "additionalProperties": {
                 "anyOf": [
                     { "$ref": "#" },

jsonschema-core.xml

@@ -1099,18 +1099,18 @@
 
                 <section title="Keywords for Applying Subschemas Conditionally" anchor="conditional">
                     <t>
-                        These keywords work together to implement conditional
-                        application of a subschema based on the outcome of
-                        another subschema.
+                        Three of these keywords work together to implement conditional
+                        application of a subschema based on the outcome of another subschema.
+                        The fourth is a shortcut for a specific conditional case.
                     </t>
                     <t>
-                        These keywords MUST NOT interact with each other across
+                        "if", "then", and "else" MUST NOT interact with each other across
                         subschema boundaries.  In other words, an "if" in one
                         branch of an "allOf" MUST NOT have an impact on a "then"
                         or "else" in another branch.
                     </t>
                     <t>
-                        There is no default behavior for any of these keywords
+                        There is no default behavior for "if", "then", or "else"
                         when they are not present.  In particular, they MUST NOT
                         be treated as if present with an empty schema, and when
                         "if" is not present, both "then" and "else" MUST be
@@ -1181,6 +1181,24 @@
                             or annotation collection purposes, in such cases.
                         </t>
                     </section>
+                    <section title="dependentSchemas">
+                        <t>
+                            This keyword specifies subschemas that are evaluated if the instance
+                            is an object and contains a certain property.
+                        </t>
+                        <t>
+                            This keyword's value MUST be an object.
+                            Each value in the object MUST be a valid JSON Schema.
+                        </t>
+                        <t>
+                            If the object key is a property in the instance, the entire
+                            instance must validate against the susbschema.  Its use is
+                            dependent on the presence of the property.
+                        </t>
+                        <t>
+                            Omitting this keyword has the same behavior as an empty object.
+                        </t>
+                    </section>
                 </section>
             </section>
             <section title="Keywords for Applying Subschemas to Child Instances">
@@ -1327,24 +1345,6 @@
                             Omitting this keyword has the same behavior as an empty schema.
                         </t>
                     </section>
-
-                    <section title="dependencies">
-                        <t>
-                            This keyword specifies subschemas that are evaluated if the instance
-                            is an object and contains a certain property.
-                        </t>
-                        <t>
-                            This keyword's value MUST be an object.
-                            Each value in the object MUST be a valid JSON Schema.
-                        </t>
-                        <t>
-                            If the object key is a property in the instance, the entire
-                            instance must validate against the dependency value.
-                        </t>
-                        <t>
-                            Omitting this keyword has the same behavior as an empty object.
-                        </t>
-                    </section>
                 </section>
             </section>
         </section>
@@ -1685,7 +1685,7 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
                         <list style="symbols">
                             <t>Moved "definitions" from the Validation specification here as "$defs"</t>
                             <t>Moved applicator keywords from the Validation specification as their own vocabulary</t>
-                            <t>Moved "dependencies" from the Validation specification, but only the schema form</t>
+                            <t>Moved the schema form of "dependencies" from the Validation specification as "dependentSchemas"</t>
                         </list>
                     </t>
                     <t hangText="draft-handrews-json-schema-01">

jsonschema-validation.xml

@@ -464,15 +464,16 @@
                     </t>
                 </section>
 
-                <section title="requiredDependencies">
+                <section title="dependentRequired">
                     <t>
                         The value of this keyword MUST be an object.  Properties in
                         this object, if any, MUST be arrays.  Elements in each array,
                         if any, MUST be strings, and MUST be unique.
                     </t>
                     <t>
                         This keyword specifies properties that are required if a specific
-                        other property is present.
+                        other property is present.  Their requirement is dependent on the
+                        presence of the other property.
                     </t>
                     <t>
                         Validation succeeds if, for each name that appears in both
@@ -1065,13 +1066,13 @@
                     <t hangText='"dependencies"'>
                         This keyword had two different modes of behavior, which made it
                         relatively challenging to implement and reason about.
-                        The schema form has been moved to Core under the original
-                        "dependencies" keyword, as part of the applicator vocabulary.
+                        The schema form has been moved to Core and renamed to
+                        "dependentSchemas", as part of the applicator vocabulary.
                         It is analogous to "properties", except that instead of applying
                         its subschema to the property value, it applies it to the object
                         containing the property.
                         The property name array form is retained here and renamed to
-                        "requiredDependencies", as it is an assertion which is a shortcut
+                        "dependentRequired", as it is an assertion which is a shortcut
                         for the conditional use of the "required" assertion keyword.
                     </t>
                 </list>
@@ -1113,7 +1114,7 @@
                         <list style="symbols">
                             <t>Moved "definitions" to the core spec as "$defs"</t>
                             <t>Moved applicator keywords to the core spec</t>
-                            <t>Renamed the array form of "dependencies" to "requiredDependencies", moved the schema form to the core spec</t>
+                            <t>Renamed the array form of "dependencies" to "dependentRequired", moved the schema form to the core spec</t>
                         </list>
                     </t>
                     <t hangText="draft-handrews-json-schema-validation-01">

schema.json

@@ -131,7 +131,20 @@
             "propertyNames": { "format": "regex" },
             "default": {}
         },
+        "dependentSchemas": {
+            "type": "object",
+            "additionalProperties": {
+                "$ref": "#"
+            }
+        },
+        "dependentRequired": {
+            "type": "object",
+            "additionalProperties": {
+                "$ref": "#/$defs/stringArray"
+            }
+        },
         "dependencies": {
+            "$comment": "\"dependencies\" is no longer a keyword, but schema authors should avoid redefining it to facilitate a smooth transition to \"dependentSchemas\" and \"dependentRequired\"",
             "type": "object",
             "additionalProperties": {
                 "anyOf": [