-
-
Notifications
You must be signed in to change notification settings - Fork 356
[suggestion] don't link vocabulary URIs; they are not retrievable #874
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
Conversation
What if you are reading on a copied / cached / reformatted version of the spec?
I'm not sure I quite understand the question?
I expect this would go in the next draft of the spec (if agreed upon), since 2019-09 is already released, and not actually have the IDs in this PR - I would have PR'd on a branch for the next draft if I saw one.
@notEthan there's no branch, we do the regular work on master, and branch for things like meta-schema bugfixes. As you noted, there's no way to update a published RFC anyway, so there's no point in a branch on that.
This is a reasonable idea. @philsturgeon @gregsdennis as people working on tools supporting this, what do you think of this one? Also paging @Relequestual on general principle.
Agreed. I'll leave others to comment. This sounds reasonable.
I don't think this change would affect any tools. it should only affect how the spec appears to humans reading it - whether the URI is linked or not.
Note that we do plan to eventually have files here, and could backport them to older drafts, so that is actually a fairly strong reason to leave them as links. You can't go back and change them once published, so a backport would only work if they were published as links.
On the other hand, you could still copy-paste them, I suppose, but it's less obvious.
it doesn't seem to me to make sense that these are links. there is no document to retrieve. if you follow the link, it just links back to the same sections of the spec the link came from.