remove redundant 'problems' appendix and link to adr; add status section

Author: gregsdennis

proposals/propertyDependencies-adr.md

@@ -7,7 +7,7 @@
 Technical Story:
 
 - Issue discussing feature - https://github.com/json-schema-org/json-schema-spec/issues/1082
-- PR to add to the spec - https://github.com/json-schema-org/json-schema-spec/issues/1082
+- PR to add to the spec - https://github.com/json-schema-org/json-schema-spec/pull/1143
 - ADR to extract from the spec and use feature life cycle - https://github.com/json-schema-org/json-schema-spec/pull/1505
 
 ## Context and Problem Statement

proposals/propertyDependencies.md

@@ -6,6 +6,15 @@ The `propertyDependencies` keyword is a more friendly way to select between two
 or more schemas to validate an instance against than is currently supported by
 JSON Schema.
 
+## Current Status
+
+This proposal is complete and awaiting integration into the specification.
+
+As some additional context, this proposal has been written prior to the stable
+specification's initial release. As such, it will not be integrated until at
+least the spec's second release at the earliest. It is also operating as a
+proving grounds, of sorts, for the SDLC's Feature Life Cycle.
+
 ## Note to Readers
 
 The issues list for this document can be found at
@@ -30,7 +39,7 @@ specification](../jsonschema-core.html) also apply to this document.
 A common need in JSON Schema is to select between one schema or another to
 validate an instance based on the value of some property in the JSON instance.
 There are a several patterns people use to accomplish this, but they all have
-significant [problems](#problems).
+significant [problems](propertyDependencies-adr.md#problems). <!-- Update when moving ADR -->
 
 OpenAPI solves this problem with the `discriminator` keyword. However, their
 approach is more oriented toward code generation concerns, is poorly specified
@@ -113,73 +122,11 @@ subsection of "Keywords for Applying Subschemas Conditionally".
     }
     ```
 
-## [Appendix] Problems With Existing Patterns {#problems}
-
-### `oneOf`/`anyOf`
-
-The pattern of using `oneOf` to describe a choice between two schemas has become
-ubiquitous.
-
-```jsonschema
-{
-  "oneOf": [
-    { "$ref": "#/$defs/aaa" },
-    { "$ref": "#/$defs/bbb" }
-  ]
-}
-```
-
-However, this pattern has several shortcomings. The main problem is that it
-tends to produce confusing error messages. Some implementations employ
-heuristics to guess the user's intent and provide better messaging, but that's
-not wide-spread or consistent behavior, nor is it expected or required from
-implementations.
-
-This pattern is also inefficient. Generally, there is a single value in the
-object that determines which alternative to chose, but the `oneOf` pattern has
-no way to specify what that value is and therefore needs to evaluate the entire
-schema. This is made worse in that every alternative needs to be fully validated
-to ensure that only one of the alternative passes and all the others fail. This
-last problem can be avoided by using `anyOf` instead, but that pattern is much
-less used.
-
-### `if`/`then`
-
-We can describe this kind of constraint more efficiently and with with better
-error messaging by using `if`/`then`. This allows the user to explicitly specify
-the constraint to be used to select which alternative the schema should be used
-to validate the schema. However, this pattern has problems of it's own. It's
-verbose, error prone, and not particularly intuitive, which leads most people to
-avoid it.
-
-```jsonschema
-{
-  "allOf": [
-    {
-      "if": {
-        "properties": {
-          "foo": { "const": "aaa" }
-        },
-        "required": ["foo"]
-      },
-      "then": { "$ref": "#/$defs/foo-aaa" }
-    },
-    {
-      "if": {
-        "properties": {
-          "foo": { "const": "bbb" }
-        },
-        "required": ["foo"]
-      },
-      "then": { "$ref": "#/$defs/foo-bbb" }
-    }
-  ]
-}
-```
-
 ## [Appendix] Change Log
 
-* [October 2023] Created
+* [March 2021] - Initially proposed
+* [October 2021] Added to specification document
+* [May 2024] Extracted from specification document as experimental feature
 
 ## Champions