python-jsonschema
diff --git a/‎README.md‎
Lines changed: 29 additions & 18 deletions b/‎README.md‎
Lines changed: 29 additions & 18 deletions
diff --git a/‎annotations/README.md‎
Lines changed: 4 additions & 4 deletions b/‎annotations/README.md‎
Lines changed: 4 additions & 4 deletions
diff --git a/‎annotations/test-case.schema.json‎
Lines changed: 1 addition & 1 deletion b/‎annotations/test-case.schema.json‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎annotations/tests/content.json‎
Lines changed: 0 additions & 2 deletions b/‎annotations/tests/content.json‎
Lines changed: 0 additions & 2 deletions
diff --git a/‎annotations/tests/core.json‎
Lines changed: 103 additions & 1 deletion b/‎annotations/tests/core.json‎
Lines changed: 103 additions & 1 deletion
diff --git a/‎bin/annotate-specification-links‎
Lines changed: 1 addition & 1 deletion b/‎bin/annotate-specification-links‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎bin/jsonschema_suite‎
Lines changed: 0 additions & 2 deletions b/‎bin/jsonschema_suite‎
Lines changed: 0 additions & 2 deletions
diff --git a/‎output-tests/README.md‎
Lines changed: 2 additions & 2 deletions b/‎output-tests/README.md‎
Lines changed: 2 additions & 2 deletions
@@ -8,6 +8,7 @@
 [![Build Status](https://github.com/json-schema-org/JSON-Schema-Test-Suite/workflows/Test%20Suite%20Sanity%20Checking/badge.svg)](https://github.com/json-schema-org/JSON-Schema-Test-Suite/actions?query=workflow%3A%22Test+Suite+Sanity+Checking%22)
 
 This repository contains a set of JSON objects that implementers of JSON Schema validation libraries can use to test their validators.
+The test suite repository exists to verify specified behavior defined by the JSON Schema specification and should not be confused with a style guide. It is not intended to demonstrate how schemas ought to be written. Tests may appear unusual or unintuitive, but they exist solely to exercise behavior prescribed by the specification.
 
 It is meant to be language agnostic and should require only a JSON parser.
 The conversion of the JSON objects into tests within a specific language and test framework of choice is left to be done by the validator implementer.
@@ -16,8 +17,8 @@ The recommended workflow of this test suite is to clone the `main` branch of thi
 
 ## Coverage
 
-All JSON Schema specification releases should be well covered by this suite, including drafts 2020-12, 2019-09, 07, 06, 04 and 03.
-Drafts 04 and 03 are considered "frozen" in that less effort is put in to backport new tests to these versions.
+All JSON Schema specification releases should be well covered by this suite, including versions draft-2020-12, draft-2019-09, draft-07, draft-06, draft-04 and draft-03.
+Versions draft-04 and draft-03 are considered "frozen" in that less effort is put in to backport new tests to these versions.
 
 Additional coverage is always welcome, particularly for bugs encountered in real-world implementations.
 If you see anything missing or incorrect, please feel free to [file an issue](https://github.com/json-schema-org/JSON-Schema-Test-Suite/issues) or [submit a PR](https://github.com/json-schema-org/JSON-Schema-Test-Suite).
@@ -31,14 +32,13 @@ Inside that directory is a subdirectory for each released version of the specifi
 
 The structure and contents of each file in these directories is described below.
 
-In addition to the version-specific subdirectories, two additional directories are present:
+In addition to the version-specific subdirectories, one additional directory is present:
 
-1. `draft-next/`: containing tests for the next version of the specification whilst it is in development
-2. `latest/`: a symbolic link which points to the directory which is the most recent release (which may be useful for implementations providing specific entry points for validating against the latest version of the specification)
+1. `latest/`: a symbolic link which points to the directory which is the most recent release (which may be useful for implementations providing specific entry points for validating against the latest version of the specification)
 
 Inside each version directory there are a number of `.json` files each containing a collection of related tests.
 Often the grouping is by property under test, but not always.
-In addition to the `.json` files, each version directory contains one or more special subdirectories whose purpose is [described below](#subdirectories-within-each-draft), and which contain additional `.json` files.
+In addition to the `.json` files, each version directory contains one or more special subdirectories whose purpose is [described below](#subdirectories-within-each-version-directory), and which contain additional `.json` files.
 
 Each `.json` file consists of a single JSON array of test cases.
 
@@ -78,17 +78,15 @@ Here is a single *test case*, containing one or more tests:
 }
 ```
 
-### Subdirectories Within Each Draft
+### Subdirectories Within Each Version directory
 
-There is currently only one additional subdirectory that may exist within each draft test directory.
+A specification version test directory may contain one or more subdirectories.
 
-This is:
+These are:
 
-1. `optional/`: Contains tests that are considered optional.
+1. `optional/`: Contains tests that are considered optional. Note that this subdirectory currently conflates many reasons why a test may be optional -- it may be because tests within a particular file are indeed not required by the specification but still potentially useful to an implementer, or it may be because tests within it only apply to programming languages with particular functionality (in which case they are not truly optional in such a language). In the future this directory structure will be made richer to reflect these differences more clearly.
 
-Note, the `optional/` subdirectory today conflates many reasons why a test may be optional -- it may be because tests within a particular file are indeed not required by the specification but still potentially useful to an implementer, or it may be because tests within it only apply to programming languages with particular functionality (in
-which case they are not truly optional in such a language).
-In the future this directory structure will be made richer to reflect these differences more clearly.
+2. `proposals/`: Contains a subfolder for each active proposal to the specification. If the proposal is a keyword (generally the case), then the subfolder will bear the name of that keyword. Inside the proposal subfolder is a series of test files that would contain amendments to the required test suite should the proposal be incorporated into the specification. These tests should be considered volatile while the proposal is in development; however, implementations claiming to support the proposal are expected to pass its tests.
 
 ## Using the Suite to Test a Validator Implementation
 
@@ -107,8 +105,8 @@ The precise steps described do not need to be followed exactly, but the results
 
 To test a specific version:
 
-* For 2019-09 and later published drafts, implementations that are able to detect the draft of each schema via `$schema` SHOULD be configured to do so
-* For draft-07 and earlier, draft-next, and implementations unable to detect via `$schema`, implementations MUST be configured to expect the draft matching the test directory name
+* For 2019-09 and later published versions, implementations that are able to detect the version of each schema via `$schema` SHOULD be configured to do so
+* For draft-07 and earlier, v1 (not yet released), and implementations unable to detect via `$schema`, implementations MUST be configured to expect the version matching the test directory name
 * Load any remote references [described below](#additional-assumptions) and configure your implementation to retrieve them via their URIs
 * Walk the filesystem tree for that version's subdirectory and for each `.json` file found:
 
@@ -135,7 +133,7 @@ If your implementation supports multiple versions, run the above procedure for e
 
 ### Additional Assumptions
 
-1. The suite, notably in its `refRemote.json` file in each draft, expects a number of remote references to be configured.
+1. The suite, notably in its `refRemote.json` file in each specification version directory, expects a number of remote references to be configured.
    These are JSON documents, identified by URI, which are used by the suite to test the behavior of the `$ref` keyword (and related keywords).
    Depending on your implementation, you may configure how to "register" these *either*:
 
@@ -158,7 +156,7 @@ If your implementation supports multiple versions, run the above procedure for e
     }
     ```
 
-2. Test cases found within [special subdirectories](#subdirectories-within-each-draft) may require additional configuration to run.
+2. Test cases found within [special subdirectories](#subdirectories-within-each-version-directory) may require additional configuration to run.
    In particular, when running tests within the `optional/format` subdirectory, test runners should configure implementations to enable format validation, where the implementation supports it.
 
 ### Invariants & Guarantees
@@ -216,6 +214,7 @@ This suite is being used by:
 
 * [jinx](https://github.com/juxt/jinx)
 * [json-schema](https://github.com/tatut/json-schema)
+* [M3](https://github.com/JulesGosnell/m3) (all drafts, pure Clojure — also usable from Java, Kotlin, Scala, and JavaScript)
 
 ### Coffeescript
 
@@ -263,6 +262,7 @@ This suite is being used by:
 * [Snow](https://github.com/ssilverman/snowy-json)
 * [jsonschemafriend](https://github.com/jimblackler/jsonschemafriend)
 * [OpenAPI JSON Schema Generator](https://github.com/openapi-json-schema-tools/openapi-json-schema-generator)
+* [M3](https://github.com/JulesGosnell/m3) (all drafts, pure Clojure — also usable from Kotlin, Scala, and JavaScript)
 
 ### JavaScript
 
@@ -281,10 +281,17 @@ This suite is being used by:
 * [jsen](https://github.com/bugventure/jsen)
 * [ajv](https://github.com/epoberezkin/ajv)
 * [djv](https://github.com/korzio/djv)
+* [M3](https://github.com/JulesGosnell/m3) (all drafts, pure Clojure — also usable from Java, Kotlin, and Scala)
 
 ### Kotlin
 
 * [json-schema-validation-comparison](https://www.creekservice.org/json-schema-validation-comparison/functional) (Comparison site for JVM-based validator implementations)
+* [kotlinx-schema](https://github.com/Kotlin/kotlinx-schema)
+* [M3](https://github.com/JulesGosnell/m3) (all drafts, pure Clojure — also usable from Java, Scala, and JavaScript)
+
+### Lua
+
+* [lua-schema](https://framagit.org/fperrad/lua-schema)
 
 ### Node.js
 
@@ -335,13 +342,17 @@ Node-specific support is maintained in a [separate repository](https://github.co
 ### Scala
 
 * [json-schema-validation-comparison](https://www.creekservice.org/json-schema-validation-comparison/functional) (Comparison site for JVM-based validator implementations)
-* [typed-json](https://github.com/frawa/typed-json)
+* [M3](https://github.com/JulesGosnell/m3) (all drafts, pure Clojure — also usable from Java, Kotlin, and JavaScript)
 
 ### Swift
 
 * [JSONSchema](https://github.com/kylef/JSONSchema.swift)
 * [swift-json-schema](https://github.com/ajevans99/swift-json-schema)
 
+### Unison
+
+* [typed-json](https://share.unison-lang.org/@frawa/typed-json)
+
 If you use it as well, please fork and send a pull request adding yourself to
 the list :).
 
 
@@ -5,7 +5,7 @@ on which values of an instance. These tests are agnostic of any output format.
 
 ## Supported Dialects
 
-Although the annotation terminology of didn't appear in the spec until 2019-09,
+Although annotation terminology didn't appear in the spec until 2019-09,
 the concept is compatible with every version of JSON Schema. Test Cases in this
 Test Suite are designed to be compatible with as many releases of JSON Schema as
 possible. They do not include `$schema` or `$id`/`id` keywords so
@@ -25,7 +25,7 @@ A short description of what behavior the Test Case is covering.
 
 The `compatibility` option allows you to set which dialects the Test Case is
 compatible with. Test Runners can use this value to filter out Test Cases that
-don't apply the to dialect currently under test. The terminology for annotations
+don't apply to the dialect currently under test. The terminology for annotations
 didn't appear in the spec until 2019-09, but the concept is compatible with
 older releases as well. When setting `compatibility`, test authors should take
 into account dialects before 2019-09 for implementations that chose to support
@@ -42,7 +42,7 @@ Case is compatible with draft-07 and up.
 **Example**: `"compatibility": "7"`
 
 You can use a `<=` operator to indicate that the Test Case is compatible with
-releases less then or equal to the given release. This example indicates that
+releases less than or equal to the given release. This example indicates that
 the Test Case is compatible with 2019-09 and under.
 
 **Example**: `"compatibility": "<=2019"`
@@ -111,6 +111,6 @@ could contribute annotations for a single keyword.
 An empty object is an assertion that the annotation must not appear at the
 `location` for the `keyword`.
 
-As a convention for this Test Suite, the `expected` array should be sorted such
+As a convention for this Test Suite, the `expected` object should be sorted such
 that the most recently encountered value for an annotation given top-down
 evaluation of the schema comes before previously encountered values.
@@ -13,7 +13,7 @@
       "pattern": "^(<=|=)?([123467]|2019|2020)(,(<=|=)?([123467]|2019|2020))*$"
     },
     "schema": {
-      "markdownDescription": "This schema shouldn't include `$schema` or `id`/`$id` unless necesary for the test because Test Cases should be designed to work with as many releases as possible.",
+      "markdownDescription": "This schema shouldn't include `$schema` or `id`/`$id` unless necessary for the test because Test Cases should be designed to work with as many releases as possible.",
       "type": ["boolean", "object"]
     },
     "externalSchemas": {
 
@@ -68,7 +68,6 @@
       "description": "`contentSchema` is an annotation for string instances",
       "compatibility": "2019",
       "schema": {
-        "$id": "https://annotations.json-schema.org/test/contentSchema-is-an-annotation",
         "contentMediaType": "application/json",
         "contentSchema": { "type": "number" }
       },
@@ -101,7 +100,6 @@
       "description": "`contentSchema` requires `contentMediaType`",
       "compatibility": "2019",
       "schema": {
-        "$id": "https://annotations.json-schema.org/test/contentSchema-is-an-annotation",
         "contentSchema": { "type": "number" }
       },
       "tests": [
 
@@ -25,6 +25,108 @@
           ]
         }
       ]
+    },
+    {
+      "description": "`$dynamicRef` resolves to `$dynamicAnchor`",
+      "compatibility": "2020",
+      "schema": {
+        "$dynamicRef": "#foo",
+        "$defs": {
+          "foo": {
+            "$dynamicAnchor": "foo",
+            "title": "Foo"
+          }
+        }
+      },
+      "tests": [
+        {
+          "instance": "bar",
+          "assertions": [
+            {
+              "location": "",
+              "keyword": "title",
+              "expected": {
+                "#/$defs/foo": "Foo"
+              }
+            }
+          ]
+        }
+      ]
+    },
+    {
+      "description": "`$dynamicRef` resolves to different `$dynamicAnchor`s depending on dynamic path",
+      "compatibility": "2020",
+      "schema": {
+        "$id": "https://test.json-schema.org/dynamic-ref-annotation/main",
+        "if": {
+          "properties": { "kindOfList": { "const": "numbers" } },
+          "required": ["kindOfList"]
+        },
+        "then": { "$ref": "numberList" },
+        "else": { "$ref": "stringList" },
+        "$defs": {
+          "genericList": {
+            "$id": "genericList",
+            "properties": {
+              "list": {
+                "items": { "$dynamicRef": "#itemType" }
+              }
+            },
+            "$defs": {
+              "defaultItemType": {
+                "$dynamicAnchor": "itemType"
+              }
+            }
+          },
+          "numberList": {
+            "$id": "numberList",
+            "$defs": {
+              "itemType": {
+                "$dynamicAnchor": "itemType",
+                "title": "Number Item"
+              }
+            },
+            "$ref": "genericList"
+          },
+          "stringList": {
+            "$id": "stringList",
+            "$defs": {
+              "itemType": {
+                "$dynamicAnchor": "itemType",
+                "title": "String Item"
+              }
+            },
+            "$ref": "genericList"
+          }
+        }
+      },
+      "tests": [
+        {
+          "instance": { "kindOfList": "numbers", "list": [1] },
+          "assertions": [
+            {
+              "location": "/list/0",
+              "keyword": "title",
+              "expected": {
+                "#/$defs/numberList/$defs/itemType": "Number Item"
+              }
+            }
+          ]
+        },
+        {
+          "instance": { "kindOfList": "strings", "list": ["foo"] },
+          "assertions": [
+            {
+              "location": "/list/0",
+              "keyword": "title",
+              "expected": {
+                "#/$defs/stringList/$defs/itemType": "String Item"
+              }
+            }
+          ]
+        }
+      ]
     }
+
   ]
-}
+} 
@@ -79,7 +79,7 @@ def main():
     sys.stdout.write("::remove-matcher owner=me::\n")
 
     for version in TESTS.iterdir():
-        if version.name in {"draft-next", "latest"}:
+        if version.name in {"v1", "latest"}:
             continue
 
         version_urls = urls(version.name)
 
@@ -281,7 +281,6 @@ class SanityTests(unittest.TestCase):
                 "$vocabulary",
                 "additionalProperties",
                 "allOf",
-                "allOf",
                 "anyOf",
                 "const",
                 "contains",
@@ -301,7 +300,6 @@ class SanityTests(unittest.TestCase):
                 "items",
                 "maxContains",
                 "maxItems",
-                "maxItems",
                 "maxLength",
                 "maxProperties",
                 "maximum",
 
@@ -8,7 +8,7 @@ _**NOTE** Although the formats didn't change much between 2019-09 and 2020-12, t
 
 The tests are organized by specification release and then into two categories: content and structure.
 
-Content tests verify that the keywords are producing the correct annotations and/or error messages.  Since there are no requirements on the content of error messages, there's not much that can be verified for them, but it is possible to identify when a error message _could_ be present.  Primarily, these tests need to extensively cover the annotation behaviors of each keyword.  The only output format needed for these tests is `basic` for 2019-09/2020-12 and `list` for later versions.
+Content tests verify that the keywords are producing the correct annotations and/or error messages.  Since there are no requirements on the content of error messages, there's not much that can be verified for them, but it is possible to identify when an error message _could_ be present.  Primarily, these tests need to extensively cover the annotation behaviors of each keyword.  The only output format needed for these tests is `basic` for 2019-09/2020-12 and `list` for later versions.
 
 Structure tests verify that the structures of the various formats (i.e. `flag`, `basic`, `detailed`, `verbose` for 2019-09/2020-12 and `flag`, `list`, `hierarchical` for later versions) are correct.  These tests don't need to cover each keyword; rather they need to sufficiently cover the various aspects of building the output structures by using whatever keywords are necessary to do so.
 
@@ -22,7 +22,7 @@ The `output` property itself has a property for each of the output formats where
 
 ## Other notes
 
-### Ambiguity around 2020-09/2020-12 `basic`
+### Ambiguity around 2019-09/2020-12 `basic`
 
 The 2019-09/2020-12 specs don't define the structure of `basic` very thoroughly.  Specifically there is a nuance where if the list contains a single output node, there are two possible structures, given the text: