Remove meta-schema tests

[jdesrosiers]

Some tests reference the meta-schema. Arguably we shouldn't do that. These test suites aren't for testing the meta-schema and we've removed such tests in the past. For v1, this pattern is problematic because https://json-schema.org/v1 is just a dialect identifier, not a mea-schema identifier.

This removes meta-schema tests for v1. The reason for removing these tests applies to other dialects as well, but it's only necessary for v1. Should we clean up the other dialect test suites as well?

[gregsdennis]

... https://json-schema.org/v1 is just a dialect identifier, not a mea-schema identifier.

It's both, though. $schema identifies the dialect, and there is a meta-schema with that as the $id. Granted, a dialect doesn't need a meta-schema, but the fact that we have one with the same $id seems relevant.

These tests were originally included as a stop-gap to test invalid schemas. If we remove these, we need a replacement for that function. I don't feel right just removing them.

[jdesrosiers]

It's both, though. $schema identifies the dialect, and there is a meta-schema with that as the $id.

That's not what we decided. Retrieving https://json-schema.org/v1 may result in a meta-schema, but that schema has an exact release $id (https://json-schema.org/v1/2026). It's like an HTTP redirect, the URI resolves, but URI of the resource you got isn't the same as the one you requested. There should never be a meta-schema with "$id": "https://json-schema.com/v1". But, that's not really the point here.

These tests were originally included as a stop-gap to test invalid schemas. If we remove these, we need a replacement for that function. I don't feel right just removing them.

We really wouldn't lose much. There are three tests affected. One is definitions/$defs and that doesn't provide any value. Another isn't actually testing the meta-schema and can be replaced by a normal remote like I did here. So, there's really only one test we'd be losing. It's the one ensuring that $id can't have a fragment. That's an important thing to test, but the test isn't testing the implementation, it's testing the meta-schema.

What if I setup meta-schema testing in the spec repo instead and transfer those two relevant tests over there? Moving it to the spec repo makes more sense than the test suite because that's where we develop the meta-schemas.

[jdesrosiers]

Here's the meta-schema test PR json-schema-org/json-schema-spec#1692