Split Hyper-Schema into its own repo?

[handrews]

JSON Hyper-Schema is very much on its own path separate from JSON Schema Core and Validation. I've been going through the issues, and it's a bit hard to see the size of the Core/Validation work with all of the hypermedia stuff mixed in.

Since it's now possible to move issues from one repo to another, should we move Hyper-Schema over? It would still be published through the web site repo. I think it would be good to make it really clear that it's separate from the "main" specifications, and should really be thought of more as an extension vocabulary that happens to be published by the same group doing Core and Validation.

Right now, there's not much going on with it. I hope to revisit it after OpenAPI 3.1 has been out for a while, as there have been sporadic ideas about mixing OpenAPI's static description approach with Hyper-Schema's runtime hypermedia approach, but really JSON Scheme Core/Validation 2019-09 and OAS 3.1 need to be implemented and worked with for a while before that will make sense.

Core and Validation are closely related, even though using Core without Validation has some use cases. But Hyper-Schema has always been kind of its own thing on top of those.

Thoughts?

[Relequestual]

Yes yes!
Immediate action!

[handrews]

OK, @philsturgeon has taken care of the repo set-up and moving issues over.

I think this is the set of files that would need to move (with git history! there's an easy way to do this I know although I can't remember it offhand):

meta/hyper-schema.json
output/hyper-schema.json
hyper-schema.json
jsonschema-hyperschema.xml
links.json

And these files need changes:

README.md
Makefile

There is a mention of hyper-schema in CONTRIBUTING.md but it's just explaining that validation and hyper-schema have different meta-schemas so that's probably OK? Unsure.

travis.yml, .gitignore, and at least some of the files in the .github directory would need to be copied over, possibly with small tweaks.

Is there anything else that would need to be done to set up the new repo?

DO NOT DO THIS YET 😄

[handrews]

The other thing to consider is how to handle how the web site repo submodules things in. If we pull the history out into the separate repo, that means none of it remains in this repo, right? So we would need to go update all of the submodule entries for all past drafts from draft-04 onward.

Are there any other web site repo concerns?

I don' think there are test suite repo concerns because we never have had a proper test suite for hyper-schema.

[handrews]

@jdesrosiers this is the issue about the hyper-schema split.

• @Relequestual moved things to the archive dir, did some other stuff, and took hyper-schema out of the build in a series of non-PR commits the day of the 2020-12 draft release
• PR importing the history to the new repo: Import hyper-schema spec and meta-schemas from json-schema-spec json-hyperschema-spec#17
• PR deleting the files (but not the history) from this repo: Delete hyper-schema after move to its own repo #1326

Since we're not deleting the history from this repo, the submodule references in the web site repo will continue to work fine. If we want to delete the history we'll have to change that, but I don't see any reason to do so. The past development of Hyper-Schema did occur here and I think it's fine to have that history in both repos: this one for the accurate record of the past, and the new one because you can't "git log" across repos.

[jdesrosiers]

Good enough for me. I just ask that you reference this issue in the PRs, then I'm ready to approve.