Consider whether "$schema" should allow fragments

[handrews]

Splitting this off from #1059 which also discussed "$id" (see PR #1291 for that part), @MikeRalphson raised the use case of a meta-schema included in a schema, but not as an embedded resource:

it seems faintly plausible to me that a metaschema could be identified by $schema using a fragment (my implementation does support metaschemas which are not at the root of their document) - but it's hard to imagine the value of such a thing.

This was exactly the use-case we were discussing over at OAS. We already have a meta-schema for OAS 3.0 (and 1.2 and 2.0) but it contains embedded definitions of the OAS schemaObject (which in these versions is a superset-subset of proper JSON Schema). It would be useful for users who want to continue to use OAS 3.0-compatible schemaObjects to be able to reference the schemaObject definition within the existing metaschema using $schema or our jsonSchemaDialect property, without the oai/TSC having to extract that schemaObject definition to its own resource and maintain it separately.

He also later noted that:

The use of a separate $id might be work for us, though I think some JSON Schema-related tools do still make assumptions that URIs are network-reachable URLs.

which hopefully can be solved by making tooling more aware of URIs not necessarily being URLs (which the spec has said clearly for years, but that's a topic for elsewhere).

I lean towards preferring meta-schemas to be schema resources, as it makes the restriction of $vocabulary to the first dynamic scope (see #1281 for more details) simpler, but @MikeRalphson if you're still strongly in favor of non-schema-resource meta-schemas (or if anyone else wants to argue for them), please discuss that here. I think we should sort this out before the next release as it should be pretty straightforward.

IMHO, OAS 3.1+ tooling should really learn to support $id properly, as it's important if one is re-using schemas among both OAS-aware and OAS-unaware tools. And JSON Schema tooling really needs to handle it correctly.

[gregsdennis]

@MikeRalphson is this still a concern for you now that OAS 3.1 is out (and 4.0 is due soon)?

[gregsdennis]

I'm going to close this as not an issue anymore.