Move the VC Extension Registry to this Working Group

[decentralgabe]

There is an existing VC Extension Registry in the CCG.

It could be beneficial to move this registry in the VCWG to give it an elevated status, resulting in the registry being an official method of extension for the WG. This does not need eliminate the CCG registry, but could open a path for CCG registered items to 'advance'.

[msporny]

+1 to move the VC Extension Registry to this group. There is no need to have two registries, this group should be managing the registry from now on. /cc CCG Chairs @mprorock @man4prez @kwlinson

[awoie]

+1

[nadalin]

Are you suggesting that this be a note or a specification, was not clear from your suggestion.

[Sakurann]

This does not need eliminate the CCG registry

Could you please elaborate? wouldn't it be confusing to have two registries of the same items? unless note is what you meant per Tony's question.

There is a registry in CCG that is relevant to this WG. We need to clarify the relationship of that registry with this WG. and that should be discussed this is conjunction with issue #909 and a TPAC discussion.

[nadalin]

Also does this mean that the WG would now be the sole process and content owners, full transfer from CCG ? From: Kristina ***@***.***> Sent: Friday, November 11, 2022 2:38 AM To: w3c/vc-data-model ***@***.***> Cc: Anthony Nadalin ***@***.***>; Comment ***@***.***> Subject: Re: [w3c/vc-data-model] Move the VC Extension Registry to this Working Group (Issue #975) This does not need eliminate the CCG registry Could you please elaborate? wouldn't it be confusing to have two registries of the same items? unless note is what you meant per Tony's question. There is a registry in CCG that is relevant to this WG. We need to clarify the relationship of that registry with this WG. and that should be discussed this is conjunction with issue #909 <#909> and a TPAC discussion. — Reply to this email directly, view it on GitHub <#975 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4R4Y3UGALTCPNY5WVOUYDWHYOWVANCNFSM6AAAAAAR32F2ZQ> . You are receiving this because you commented. <https://github.com/notifications/beacon/AB4R4Y5XP6SCB53YFM4WQDLWHYOWVA5CNFSM6AAAAAAR32F2ZSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSOFRFTG.gif> Message ID: ***@***.*** ***@***.***> >

[nadalin]

A very big -1 if the CCG does not want to completely turn over the registry and registry process to the WG as part of the submission.. I’m fine with CG’s incubating things but to continue after submission to a WG I don’t support. From: Kristina ***@***.***> Sent: Friday, November 11, 2022 2:38 AM To: w3c/vc-data-model ***@***.***> Cc: Anthony Nadalin ***@***.***>; Comment ***@***.***> Subject: Re: [w3c/vc-data-model] Move the VC Extension Registry to this Working Group (Issue #975) This does not need eliminate the CCG registry Could you please elaborate? wouldn't it be confusing to have two registries of the same items? unless note is what you meant per Tony's question. There is a registry in CCG that is relevant to this WG. We need to clarify the relationship of that registry with this WG. and that should be discussed this is conjunction with issue #909 <#909> and a TPAC discussion. — Reply to this email directly, view it on GitHub <#975 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4R4Y3UGALTCPNY5WVOUYDWHYOWVANCNFSM6AAAAAAR32F2ZQ> . You are receiving this because you commented. <https://github.com/notifications/beacon/AB4R4Y5XP6SCB53YFM4WQDLWHYOWVA5CNFSM6AAAAAAR32F2ZSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSOFRFTG.gif> Message ID: ***@***.*** ***@***.***> >

[decentralgabe]

@nadalin

Are you suggesting that this be a note or a specification, was not clear from your suggestion.

I'm suggesting a new registry (is that a specification?) hosted and administered by this working group.

@Sakurann

This does not need eliminate the CCG registry

Could you please elaborate? wouldn't it be confusing to have two registries of the same items? unless note is what you meant per Tony's question.

There is a registry in CCG that is relevant to this WG. We need to clarify the relationship of that registry with this WG. and that should be discussed this is conjunction with issue #909 and a TPAC discussion.

As others have mentioned the CCG registry can be useful for incubation and may have less stringent requirements than the VCWG's registry. In this sense, I can see value in each group having their own registry.

I also understand this may be confusing and it could be better to just have a single registry. If we go this route we need to have an answer for "where do I put things that aren't quite ready for the VCWG's registry but I want people to know about them, use them, and help make them better."

[nadalin]

Thanks for the clarification, I’m totally against this this approach with 2 registries and 2 different groups and processes From: Gabe ***@***.***> Sent: Friday, November 11, 2022 9:16 AM To: w3c/vc-data-model ***@***.***> Cc: Anthony Nadalin ***@***.***>; Mention ***@***.***> Subject: Re: [w3c/vc-data-model] Move the VC Extension Registry to this Working Group (Issue #975) @nadalin <https://github.com/nadalin> Are you suggesting that this be a note or a specification, was not clear from your suggestion. I'm suggesting a new registry (is that a specification?) hosted and administered by this working group. @Sakurann <https://github.com/Sakurann> This does not need eliminate the CCG registry Could you please elaborate? wouldn't it be confusing to have two registries of the same items? unless note is what you meant per Tony's question. There is a registry in CCG that is relevant to this WG. We need to clarify the relationship of that registry with this WG. and that should be discussed this is conjunction with issue #909 <#909> and a TPAC discussion. As others have mentioned the CCG registry can be useful for incubation and may have less stringent requirements than the VCWG's registry. In this sense, I can see value in each group having their own registry. I also understand this may be confusing and it could be better to just have a single registry. If we go this route we need to have an answer for "where do I put things that aren't quite ready for the VCWG's registry but I want people to know about them, use them, and help make them better." — Reply to this email directly, view it on GitHub <#975 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4R4Y3M36VNQDOQSMBE4Y3WHZ5NLANCNFSM6AAAAAAR32F2ZQ> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AB4R4Y76BIFL3T64P76IQPTWHZ5NLA5CNFSM6AAAAAAR32F2ZSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSOGL4LO.gif> Message ID: ***@***.*** ***@***.***> >

[decentralgabe]

@nadalin

I said...

I also understand this may be confusing and it could be better to just have a single registry. If we go this route we need to have an answer for "where do I put things that aren't quite ready for the VCWG's registry but I want people to know about them, use them, and help make them better."

Please share your thinking here if we were to go with a single registry.

[TallTed]

@decentralgabe

I also understand this may be confusing and it could be better to just have a single registry. If we go this route we need to have an answer for "where do I put things that aren't quite ready for the VCWG's registry but I want people to know about them, use them, and help make them better."

I would suggest using a "status" or similar attribute, where one value might be "draft" or "feedback sought" or the like. Best practice might be to advise registrants that their "draft" entries would become "withdrawn", "cancelled", or similar, after some period as "draft" — might be 3, 6, 12 months.....

[selfissued]

I support moving the registry to the working group.

I agree that there should only be one group administering the VC registry. Therefore, at the time of the transfer, we should also work with the CCG to cause web references to the CCG registry to redirect to the working group registry. That, or I'm fine with deleting it entirely.

[jandrieu]

I oppose registries as a mechanism for decentralized disambiguation.

We don't technically read a registry and we, the W3C, have a poor track record on doing it well.

[decentralgabe]

decentralization means providing many options. a centralized option does not harm decentralization if it is not the only method of extension. in this sense, I support the registry as an option, even if not the only one.

and past performance is not indicative of future results

[decentralgabe]

I am also open to axing the registry entirely in favor of an IANA registry. I have no preference where it lives. Just think we need another mechanism for extensibility.

[brentzundel]

I believe this issue can be closed now that the group has decided to move forward with the VC Specs Directory.

[brentzundel]

No objections since being marked pending close, closing.