Description
This issue is not intended to make fundamental changes, just address the overly-broad "implementation-defined" behavior by excluding obviously problematic behaviors. Doing this does not preclude further changes to $schema and/or $vocabulary — I'm just filing it to ensure that if we do not otherwise change $schema, it will be more clear in the next release.
My intention was that, in the absence of $schema, or if $schema is not recognized and not available (since we already have clear guidance for how to handle and available $schema with and without a core vocabulary declared), implementations MUST do one of the following:
- Refuse to process the schema, e.g. raise an error rather than returning a pass or fail result
- Assume a specific documented dialect meta-schema URI/IRI, which can be for either a standard or custom meta-schema, but can't just be "the latest" without qualification as that could change
- Document the process by which the implementation determines its behavior, which MUST result in behavior consistent with one of however-many specific dialect meta-schema URIs/IRIs the implementation wants to consider, e.g. "if
$recursive*or the array form ofitemsis present, then the 2019-09 standard default dialect is assumed, otherwise the 2020-12 standard default dialect is assumed."
This would avoid the appearance that an implementation can proceed with completely arbitrary behavior, which was never the intent.
This issue is not intended to address what else we may or may not want $schema to do, which is being discussed in numerous other places. The above set of options is based on a survey of implementations and how they handle such things.