A non-exhaustive set of possible input documents for registries

[brentzundel]

This PR builds on #98 and #99.

It adds a paragraph for a non-exhaustive list of possible input documents and uses the links that were in the table in #85 to populate the list.

---

Preview | Diff

[iherman]

Please close this PR without merging it, as #98 already does the job well that needs to be done. Saying that creation of registries is in scope is all we need to do in the charter.

We had a long discussion on previous entries where lots of details, references to all kinds of documents, etc, have been listed to avoid unnecessary in-scope/out-of-scope discussions creeping into the WG's work. I think this proposal (which does not contradict the short paragraph proposals in #98 or, rather, #101) just sets the right balance.

[iherman]

The issue was discussed in a meeting on 2022-03-16

• no resolutions were taken

View the transcript

#### 3.2. A non-exhaustive set of possible input documents for registries (pr vc-wg-charter#100) _See github pull request [vc-wg-charter#100](https://github.com/w3c/vc-wg-charter/pull/100)._ **Brent Zundel:** PR 100 adds a possible set of input documents. **Michael Jones:** Having a list of input documents would take away from having a nice clear clause. **Brent Zundel:** I agree, but the same decision would be made here. **Orie Steele:** I just have a question regarding why listing input documents is so contentious. … It seems we can all do registries or not do them. But it does seem like providing links to input documents seems better than not providing those. … Can we have a brief conversation around why we're blocking input documents when we might do something?. **Michael Jones:** It's a fair question. It's my sense, looking at some of the input documents. The registries that are proposed are not structured the way I would structure it. Extensions are overly general. Extensions for VCs -- well there will be a lot of different possible registries. It would be better to have a fresh perspective. As I said in PR 99, we should organically create these. **Markus Sabadello:** I feel like we may or may not want to work on certain things. I don't see any downsides for listing existing documents and it's helpful to point to the existence of those. It doesn't mean that they have to be used, but I agree with Orie that it's better to mention them than to leave them out. **Ted Thibodeau Jr.:** In my world, input documents are things that we've learned from. Either we developed them and they are bad or they are good or whatever. It seems to me it's good to list input documents even if the plan is to make them worthless wrt what we develop. > *Michael Prorock:* +1 Ted. > *Markus Sabadello:* +1 to Ted. **Ted Thibodeau Jr.:** If we can't learn from past experience, what can we learn from?. > *Dave Longley:* +1 to Ted. **Orie Steele:** I think those input documents have evolved organically from those who have implemented version 1. Fully disclosure, I'm an author of a lot of input document / CCG draft things in this space. I can tell you w/ 100% certainty is that I've learned a lot here and many of those shouldn't have happened. … To Ted's point -- acknowledging that we've learned from these things is important. Leaving them out is to bury our heads in the sand. We've learned a lot and a lot has been painful. Sometimes it's good to include an input document and then say that it represents the worst ideas we've had. … We're acknowledging that and we want to move on from it. I also agree with Mike in that we don't want to pour concrete around them. That's going to happen no matter what -- it's easier to talk about things if they are linked. > *Dave Longley:* +1 to Orie. > *Ted Thibodeau Jr.:* I think it's also OK to say "this is an example of something we are adamantly not going to make this time, in xyz ways". > *Michael Prorock:* +1 Orie. **Orie Steele:** I would much rather acknowledge that the documents take us in a way we don't want to go as needed. > *Brent Zundel:* +1 Orie. **Michael Jones:** To Ted's point and Orie's about learning from past work. I support that. I view that as orthogonal to listing them in the charter. There are a number of individuals like Orie, Ted, and Markus and others on this call that are familiar with them. That knowledge will not be lost and brought to the WG. … Either positively or not. I don't think that having a laundry list of possible input documents really moves us forward. Once we have a working group rechartered, I'd be happy to have people submit pointers to that in meeting minutes or notes or drafts. … A charter is a special thing, it does not have to have lists and lists of things. We're already pretty bloated, let's not do that anymore, please. **Brent Zundel:** What if it was a list of links to follow and it wouldn't take up as much space. **Michael Jones:** It's not the formatting that bothers me -- it's the presumption that these are the registries we want to create. … Let the registries evolve organically from the normative work we do together. > *Orie Steele:* the opposite is also true, the presumption that these ARE NOT the registries we want to create. > these registries have ALREADY evolved organically. **Ted Thibodeau Jr.:** The question comes to mind --- who is the charter for? It's for the Advisory Committee. It's not to benefit us to tell us what documents we've already worked on. It's to help other people benefit from work that's already been done. It's for them. > *Orie Steele:* +1 Ted. **Ted Thibodeau Jr.:** It's for people reading the charter to say "I don't know, what's this based on" so they can go look at the input documents. … And know what it's based on. **David Chadwick:** A number of people said this list contains both good and value examples. That means there's a value judgment. Anyone reading the list will not know what's good or bad. If we have the list and we put the value judgments, then people will get bogged down in the mud over those judgments. **Michael Jones:** To the point about the Advisory Committee -- I can't imagine that the current wording that says that registries are in scope would be confusing. … Having recently setup the new W3C registries policy they would be happy to seeing that. Listing things could be breaking into jail, generating questions that otherwise wouldn't occur. > *Orie Steele:* agree regarding the "breaking into jail" bit.

[brentzundel]

The group has failed to come to consensus on this PR, closing