Skip to content

Self-host past drafts #54

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 5, 2023
Merged

Self-host past drafts #54

merged 2 commits into from
Sep 5, 2023

Conversation

jdesrosiers
Copy link
Member

Resolves #49

I updated all links to our past drafts to point to a self-hosted version rather than IETF.

For most releases, we already had a copy in the repo, so I just had to change the link.

Missing copies

For the releases I didn't have a copy for, I got one from the IETF site. Unfortunately, they don't have an HTML copy that's self contained, so I chose to use the pdf version instead. However, for a couple of the really old releases, the only thing I could get my hands on was the txt version. It's probably possible to go back in git history to find html versions in the old website for some of the releases I used pdfs for, but I'm not sure that's worth the effort. Here are releases that don't have an html version.

  • draft-zyp-json-schema-00.txt (draft-00)
  • draft-zyp-json-schema-02.txt (draft-02)
  • draft-zyp-json-schema-03.pdf (draft-03)
  • draft-wright-json-schema-00.pdf (draft-05/draft-04)
  • draft-wright-json-schema-validation-00.pdf (draft-05/draft-04)
  • draft-wright-json-schema-hyperschema-00.pdf (draft-05)
  • draft-handrews-json-schema-00.pdf (draft-07 obsolete)
  • draft-handrews-json-schema-validation-00.pdf (draft-07 obsolete)

Relative JSON Pointer

I left Relative JSON Pointer pointing to IETF. I think most of us agree that that spec makes sense to stay on the IETF track.

Symlinks

I did a little reorganization of how we store past drafts. Documents are now named with their IETF identifier and there are symlinks to the latest version using the common names. For example, draft-07 had two releases, draft-handrews-json-schema*-00 and draft-handrews-json-schema*-01. All of those documents are in the /draft07 folder and there are symlinks pointing /draft-07/json-schema-core.html, /draft-07/json-schema-validation.html, and /draft-07/json-schema-hyperschema.html to the *-01 versions.

I didn't to create the symlinks for drafts 00-03 because they're just so old and unused that I didn't think it was necessary. I didn't create symlinks for draft-05 because it's a weird case and I didn't really know what to do with it. Technically, core and validation are just patch updates to draft-04, so draft-04/json-schema*.html should point to the draft-05 documents. But, hyperschema is changed in ways that requires that it be considered it's own version. I decided to just leave draft-05 as a distinct release even though it mostly isn't.

Other cleanup

While looking for IETF links, I came across some IETF copy that doesn't make sense and either removed or updated it. I also noticed we were hosting a pdf for Understanding JSON Schema. That doesn't make sense in the new site, so I removed it.

@jdesrosiers jdesrosiers requested a review from benjagm August 3, 2023 21:20
@benjagm
Copy link
Collaborator

benjagm commented Aug 30, 2023

@jdesrosiers Should we wait to merge this until know the legal implications of moving the spec process away from IETF to OpenJS Foundation?

@jdesrosiers
Copy link
Member Author

I'm not even a little worried that there's a legal issue with us moving away from IETF, but this change isn't related to that choice. It's something we need to do regardless because IETF told us that they don't guarantee that they will host expired drafts forever. Self-hosting is the only choice we have or we could loose those documents.

The only possible legal issue, it's whether or not we can tell people that they can normatively reference our past IETF-published drafts in their spec because we host them and we said it's ok. If it turns out we can't say that, that would be (and currently is) annoying for other specifications, but it wouldn't mean we don't need to, or can't, self-host those documents.

Copy link
Collaborator

@benjagm benjagm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a huge effort you putted on this. Thanks a lot Jason!

Looks good to me.

Copy link
Member

@gregsdennis gregsdennis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some questions. Otherwise, looks great! Thanks.

@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Sep 1, 2023

Deploying with  Cloudflare Pages  Cloudflare Pages

Latest commit: 4266b58
Status: ✅  Deploy successful!
Preview URL: https://917b58d3.website-2v2.pages.dev
Branch Preview URL: https://self-host-drafts.website-2v2.pages.dev

View logs

@jdesrosiers jdesrosiers merged commit 47af649 into main Sep 5, 2023
@jdesrosiers jdesrosiers deleted the self-host-drafts branch September 5, 2023 20:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Link to self hosted drafts, not IETF
3 participants