PROPOSAL: Addressing Old Registration Entries

[OR13]

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]

Blocked by #266

[iherman]

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

• no resolutions were taken

View the transcript

6.2. PROPOSAL: Addressing Old Registration Entries (issue did-spec-registries#265)

See github issue did-spec-registries#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 #-.

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]

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

[OR13]

Related #329

[talltree]

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:

• Leave the table of current DID methods as is.
• Add a new table that is reserved for DID methods whose authors have:
  • Submitted a PR with a link to their revised DID method specification.
  • Self-attested that this revised specification meets the requirements of the DID Core 1.0 spec.
• When a DID methods listed in the original table becomes qualified for inclusion in the new table, change the Status for the listing in the old table to "Upgraded to DID 1.0—See New Table".

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]

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

[talltree]

@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]

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]

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]

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]

@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]

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

[TallTed]

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]

@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...