Rename VC Specifications Registry to VC Extensions
msporny opened this issue · 13 comments
The DID WG recently resolved to rename the "DID Specifications Registries" to "DID Extensions". This group should consider renaming the "VC Specifications Directory" to "VC Extensions". Doing so avoids the "registry vs. directory" debate and makes it more apparent what the document is about. We would, of course, keep the notion that the list of extension specifiations are not some sort of "official" list but rather, just a collection of extensions that specification authors have decided to include in the list of extensions.
Manu, is this a step toward a later subset of DID Extensions that includes those that are widely implemented (i.e., show serious adoption, or are otherwise demonstrably well tested)?
+1 to VC Extensions
The issue was discussed in a meeting on 2024-08-21
- no resolutions were taken
View the transcript
4.2. Rename VC Specifications Registry to VC Extensions (issue vc-data-model#1551)
See github issue vc-data-model#1551.
Gabe Cohen: We have another new issue, 1551, rename VC Specifications Registry to VC Extensions.
Manu Sporny: In the DID WG, there was a resolution made to split the DID Registry to DID Extensions (unofficial, just a list of things we know about) and DID Methods into its own registry. It's more of a directory than a registry, it's just the ones that we know of.
… Does this group want to do something similar? I think we have consensus about it being not an official list of all available extensions. Proposal is to rename VC Specifications Registry to VC-Extensions.
… Any objections? The only downside here is the pain that Ivan will go through to put redirects in place.
Will Abramson: +1 makes sense to me.
Kevin Dean: +1.
Joe Andrieu: +1.
Ivan Herman: I'm not against it, the only consequence is that many of the papers and even within some diagrams we use the term Verifiable Data Registry or similar term which is a generic term for all kinds of data we store in this ecosystem. We may have to change that as well, which means a lot of small places in our presentations etc. to be updated.
Manu Sporny: That's another good reason to change the name. Verifiable data registries are something different, they can be blockchains, websites, centralized or decentralized, etc., as opposed to a list of specifications.
Dave Longley: +1 to manu, VDR is totally different from VC Specification Registry, so good to make it clearer they are mostly unrelated.
Dave Longley: +1 to VC Extensions.
Manu Sporny: Those should stay the same in the spec. The reason it's an issue in the VCDM is that we talk about them in multiple places in the document in slightly different ways, so renaming to VC-Extensions will remove some of that ambiguity.
Ivan Herman: I am fine with the way that we refer to the verifiable data registry. I don't know if it's tribal knowledge or more formal, but your proposal of changing is very welcome.
Manu Sporny: also, yes, we need to track down where we first defined VDR.
Manu Sporny: yes, +1 to clean up the terminology that we use.
@longpd wrote:
Manu, is this a step toward a later subset of DID Extensions that includes those that are widely implemented (i.e., show serious adoption, or are otherwise demonstrably well tested)?
Hrm, no, I don't think so. DID Extensions and VC Extensions are two different lists of specifications with no expectation of overlap.
Done in 20da204.
I'm going to leave this PR open until the full rename/redirect happens.
@iherman I've also renamed everything I can in https://github.com/w3c/vc-extensions ... please set up the appropriate /TR/ redirects.
+1 to this change
The issue was discussed in a meeting on 2024-08-28
- no resolutions were taken
View the transcript
3.2. Rename VC Specifications Registry to VC Extensions (issue vc-data-model#1551)
See github issue vc-data-model#1551.
Brent Zundel: this is 'rename spec registry to 'VC Extensions''.
… this is in parallel to the DID WG renaming their spec registry to DID Extensions.
… for us, renaming it to VC Extensions avoids the whole 'registry vs directory' issue.
Manu Sporny: we made a WG resolution last time, I've made that change.
… it's at the new URL at github.
… however, I'll keep this issue open until Ivan makes proper redirects on the w3c TR website.
Brent Zundel: would anyone be opposed to making this change?
… sounds like a straightforward move.
Phillip Long: +1 to this change.
Done in 20da204.
I'm going to leave this PR open until the full rename/redirect happens.
@iherman I've also renamed everything I can in https://github.com/w3c/vc-extensions ... please set up the appropriate /TR/ redirects.
I cannot set up such redirections in /TR. I believe what this requires is a new formal publication of the NOTE as if it was a new one, and noting in the republication request that this is, in fact, an old Note renamed. (I suspect there is a need for a formal request because this means a new short name for a TR document.) The Webmaster has the right and the tools to do the redirections at the time of the publication. @deniak, is that correct, or can you simply publish a new version without the formal decision of PlH and Yves involved?
Note, however, that with that change, the reference to the old editor's draft (https://w3c.github.io/vc-specs-dir/) has become a 404; I am not sure whether something can be done about that. We could have chosen to leave the GitHub repository name intact. But I guess that is too late.
I have prepared a publication request admin text in https://github.com/w3c/verifiable-credentials/blob/main/admin/NOTE-vc-extensions-Sep-2024/Approval_request.md; please check it whether it is all right (if it is necessary, that is).
To follow traditions, you should also create and store in the repository the final, static version of the document that I could put to our server. Do not forget to run the document through pubrules' and link checker. Hopefully the date of next Tuesday will work (these formal W3C decisions are usually taken on Fridays).
cc-ing @deniak to see if I miss something.
The issue was discussed in a meeting on 2024-09-11
- no resolutions were taken
View the transcript
3.5. Rename VC Specifications Registry to VC Extensions (issue vc-data-model#1551)
See github issue vc-data-model#1551.
Brent Zundel: next up is 1551, which was a proposal to rename VC specs registry to VC extensions.
… I think this happened, is that right?
Manu Sporny: correct, that happened, waiting for redirects to be set up in TR space, let me know if you are waiting on something.
Ivan Herman: I put a long comment on that more than a week ago, the problem is that it is not that simple, I cannot change the redirect, need to republish the node, making clear that we are changing the name.
… I was not here when it was decided to change the repo/doc.
… I would have said that changing docs short name is not an easy business.
… not a matter of proposal/resolution, there is a proposal I wrote there to change things that I need to submit for administration, you have not commented.
… we are getting into publication moratorium now, all of this is now postponed until next week.
… sorry, but not my decision.
Manu Sporny: I think all of that is fine as long as it happens eventually.
Ivan Herman: 'eventually' is keyword, I will need your input.
@iherman wrote:
I have prepared a publication request admin text in https://github.com/w3c/verifiable-credentials/blob/main/admin/NOTE-vc-extensions-Sep-2024/Approval_request.md; please check it whether it is all right (if it is necessary, that is).
I have reviewed the request, it looks good to me.
To follow traditions, you should also create and store in the repository the final, static version of the document that I could put to our server.
Done:
https://github.com/w3c/vc-extensions/tree/main/NOTE/2024-09-17
Alas! :-(
We have gone through that nightmare before, I just realized, and it is even more complicated than that: w3c/vc-jose-cose#126 (comment). Sorry for missing that:
- I think the following should be used this time: https://respec.org/docs/#previousDiffURI
- echidna should be temporarily suspended before you merge anything because it is using the old version
- when everything is ready, I will have to ask for a TiLT approval for the new short name
All this cannot be done this week. As I told you on the call, this is to be done after TPAC. Also, you should not use directories with exact dates in the repository, those dates almost never go the first round...
P.S. Let us try to avoid such repository/short name changes. It is an admin nightmare!
All is well that ends well:-) The approval for the new short name came quicker than expected, and the publication for the new document has also been speeded up. The only remaining step is to set up echidna for the new repository, see w3c/vc-extensions#40. Once that PR is merged, this issue can be closed.
The PR to update Echidna (w3c/vc-extensions#40) has been merged.
https://www.w3.org/TR/vc-extensions/ is now live and healthy.
Hooray!
Thank you @iherman and @deniak!
Closing as resolved.