search

w3c / did-extensions

Decentralized Identifier Ecosystem Extensions
https://w3c.github.io/did-extensions/
Other
120 stars 198 forks source link

PROPOSAL: Addressing Old Registration Entries #265

Open OR13 opened 3 years ago

OR13 commented 3 years ago
  1. Create a new list for properly registered methods ( once process for registering methods is resolved )
  2. Move registered methods to the old list (Provisional)
  3. Wait for folks to re-register by conforming to the did method registration process
OR13 commented 3 years ago

Blocked by https://github.com/w3c/did-spec-registries/issues/266

iherman commented 3 years ago

The issue was discussed in a meeting on 2021-08-10

View the transcript #### 6.2. PROPOSAL: Addressing Old Registration Entries (issue did-spec-registries#265) _See github issue [did-spec-registries#265](https://github.com/w3c/did-spec-registries/issues/265)._ **Manu Sporny:** let's pick up 265. This is Orie discussing old registration entries. Orie suggests separate tables, Justin -1 and says use labels. Concrete suggestion: we add labels as a first pass to address issue 265 > *Brent Zundel:* adding labels that say they are wrong in some way but not remove them. **Drummond Reed:** as a first pass indicates that we add labels, then decide later to move them into different tables? **Manu Sporny:** yes **Drummond Reed:** I am in favor of that **Manu Sporny:** any objections? we label everything them decide later if we want to do more? **Daniel Burnett:** sounds like agreement **Manu Sporny:** do we have a volunteer to attempt a first round of labelling? > *Ted Thibodeau Jr.:* +1 label, then decide about segregation (too bad we still have no table sort in respec) **Drummond Reed:** I don't want to be the only volunteer, but I am one volunteer **Manu Sporny:** my expectation is that Joe will be doing a chunk of that work as well for the DID Methods **Joe Andrieu:** okay _See github issue [#-](https://github.com/w3c/did-core/issues/-)._ **Daniel Burnett:** we are at the end of the meeting … any last comments? > *Joe Andrieu:* cheers, folks! **Daniel Burnett:** thank you everyone, thanks to scribes, bye all ---
OR13 commented 3 years ago

Decision in the meeting appears to be label the item as "stale" or "old" or "contentious", action is not clear to me.

OR13 commented 3 years ago

Related https://github.com/w3c/did-spec-registries/pull/329

talltree commented 3 years ago

I want to go on record as re-recommending a variant of original proposal that started this thread:

  • Create a new list for properly registered methods ( once process for registering methods is resolved )
  • Move registered methods to the old list (Provisional)
  • Wait for folks to re-register by conforming to the did method registration process

The proposed variant is:

The list of registered DID methods has grown so large (over a 4 year period) that I strongly suspect this is the only fair way to distinguish those DID methods that are serious enough about usage of their method that they will upgrade their specification to meet the requirements of the DID Core 1.0 spec. IMHO that will do a lot to maintain the overall quality of the DID Spec Registries.

OR13 commented 3 years ago

@talltree would you be willing to make this proposal as a PR against this repo that defines this as the process?

talltree commented 3 years ago

@talltree would you be willing to make this proposal as a PR against this repo that defines this as the process?

@OR13 Yes, but before I do so, I'd like to save all of us work by seeing if we have general agreement on whether we want to keep a single table of all registered DID methods regardless of status, or split it into multiple tables. I see three basic options:

  1. Single table, ordered alphabetically by DID method name, with enumerated Status values. This would be the closest to what we have now. All we need to do is agree on the enumerated values for the Status column and the rules for applying them.
  2. Single table, ordered first by enumerated Status values, then by DID method name. This is the same as the first option, only organizes the table by Status value. It gives slightly more weight to Status values.
  3. Separate tables by Status. With this approach there would be no Status column, but separate tables for all DID methods with the same Status. For example, for 3 Status values:
    1. Table 1: DID Core 1.0 Compliant
    2. Table 2: Provisional
    3. Table 3: Withdrawn

If we can converge on one of these three approaches on the DID WG call tomorrow (Tue Sept 21), I can create a PR based on that.

OR13 commented 3 years ago

I'm in favor of option 1, but also should note that maintain alphabetical order is a thing we have struggled with, it would be nice if the sorting happened automatically, and the table was a csv, similar to this approach here:

https://github.com/multiformats/multicodec/blob/master/table.csv

talltree commented 3 years ago

If we can have a way to sort the table dynamically, i.e., by clicking a column header, then option 1 and option 2 would both be supported. That would tilt me personally to support that direction vs. option 3 (separate tables).

brentzundel commented 3 years ago

speaking as a group member, I prefer a single table. If dynamic sorting can be supported, that would be great. I vaguely recall this coming up in a different context. @TallTed or @jricher does the problem of dynamically sorted tables sound familiar to you?

iherman commented 3 years ago

@TallTed or @jricher does the problem of dynamically sorted tables sound familiar to you?

AFAIK, this is a feature that should be incorporated into respec, eventually. @marcoscaceres, @sidvishnoi, do you have an idea when this would become available?

sidvishnoi commented 3 years ago

Can't give a timeline, but we're tracking it at https://github.com/w3c/respec/issues/3483.

TallTed commented 3 years ago

Yeah, "someday" dynamically sorting (and sizing cursor windows over) large tables will be built into Respec.

Until then, we're stuck with the horror that is a giant static table, because the most commonly used table-handling javascript library fails to integrate for reasons that are beyond my ken.

iherman commented 3 years ago

@sidvishnoi thanks. If it helps you in prioritizing, I have another use case of where such a feature would become really useful (generating reports on epub testing; that will, eventually, involve quite large tables as well...).

@TallTed and the others... I share your opinion on this but, nevertheless, my proposal is to wait for the respec solution. We did try to find/use other tools; I do not remember all the details, but they were all problematic (invalid HTML, necessity to use large external libraries...). The registry will evolve anyway, it is not like we have to have a cast-in-concrete release right now...