We need a process for handling registries, APIs and other 'enumerations'

[dwsinger]

Currently mixed into #79, but the 'Registry' question is much more limited and we should consider attacking it independently.

The AB has a discussion page on Registries at https://www.w3.org/wiki/Registries

[jeffjaffe]

In general there are other items: vocabularies, accessibility mappings that could fit with registries as well.

[dwsinger]

Leaving in the AB hands for now, they can point out what the process consequences are when they work it out.

[dwsinger]

https://www.w3.org/wiki/Registries is a discussion

[dwsinger]

"registries" suggests the rather narrow IANA-like operation, and the requests include API etc.

[dwsinger]

improved discussion at https://www.w3.org/wiki/Repositories

[vfournier17]

Is there a license that applies to the items in the registry?

[dwsinger]

On Mar 19, 2018, at 10:17 , Virginia Fournier ***@***.***> wrote: Which IP rules would apply to the items in the registry?

If you look at the analysis, a lot depends on what the status of the code-points is vis-a-vis obligation to recognize or implement. MP4, for example, merely documents to avoid collision and duplication; so the IPR requirements are those of the referenced spec. (or company). Some IANA code-points are effectively mandatory — so the IPR requirement would need to be W3C or W3C-conformant, i.e. RF. If people think this covers the landscape, we can look into formulating the rules, boilerplate text, and so on.

[chrisn]

An example is the Media Source Extensions Byte Stream Format Registry, which maintains a mapping between MIME-type/subtype pairs and byte stream format specifications for use with MSE.

[lvdbrink]

Another example: the EPSG registry, which is the authoritative source of coordinate reference system definitions. The OGC maintains a shadow copy of this registry.

[kcoyle]

Here's yet another example: the Open Metadata Registry, which has some very well thought-out features for versioning and change control.

• Detail of entry
• History

[dwsinger]

and another

https://www.w3.org/2011/07/regreq.html

[alvestrand]

The stats registry in https://w3.github.io/webrtc-stats/ is one example of a spec that tries to perform the job of a registry. Somewhat doubtful - we still want the stats' behavior documented and published too.

[dwsinger]

Note also

https://www.w3.org/2011/07/regreq.html

TTML uses:

https://www.w3.org/wiki/TTML/RoleRegistry
https://www.w3.org/wiki/TTML/ItemNameRegistry

And perhaps more importantly the media type registry with short form
profile designators for TTML is at:

https://www.w3.org/TR/ttml-profile-registry/

there is an XPointer registry:
https://www.w3.org/2005/04/xpointer-schemes/
It has an ad-hoc script for adding entries:
https://www.w3.org/2005/04/xpointer-schemes/0register
We don't know if that is just supposed to deposit email in someone's mbox
and whether that person knows of their mandate.

[edent]

I'd like to mention the UK Government Registers project - https://www.registers.service.gov.uk/

It provides an authoritative - and non-revocable - list of "things".

See user stories at https://gds.blog.gov.uk/2015/09/01/registers-authoritative-lists-you-can-trust/ and https://gds.blog.gov.uk/2015/10/13/the-characteristics-of-a-register/

[dwsinger]

Looks like webauth has some, see w3c/webauthn#1177

[dret]

in case anybody is interested to read a bit about how registries are usually managed, what is managed, and how to do it, https://tools.ietf.org/html/draft-wilde-registries might be interesting to read. it's expired but still up to date, and if anybody has feedback or input for that document, i would be delighted to hear about that.

[dret]

as a second possibly useful resource, https://github.com/dret/RegMan/blob/master/W3C.md has a list of current W3C specs that ideally should use registries, but use a variety of other ways to do it because W3C doesn't currently support registries.
there are probably more specs where having a registry would have been beneficial, but people did not do it because there currently is no culture or support for doing it at the W3C.

[dret]

i have also posted this over at #79, but this here may be the more specific issue: i just updated the draft of my "the use of registries" document, and i have added a list of w3c specifications that currently are using some shape or form of a "registry", but are doing so in a rather ad-hoc session because there is no process or even guidance (afaict). here is a direct link to the section listing W3C specifications: https://tools.ietf.org/html/draft-wilde-registries-02#appendix-A

[dwsinger]

Initial suggested requirements at https://www.w3.org/wiki/Repositories#Recommendation

[jeffjaffe]

This issue is labeled as "Needs AB Feedback". The AB has discussed it but and there has been progress, but no resolution.

It would be good at this time to invite the Process CG back into the discussion by giving them an update of the AB discussions.

There are two points of view being expressed at the AB. Perhaps @dwsinger @frivoal and @fantasai can provide pointers to either the draft of the process document or pull requests that represent their current views about how to incorporate Registries into Process 2020. With that, members of the Process CG and AB can weigh in on specific text proposals for Process 2020.

[frivoal]

Draft of the @fantasai & @frivoal proposal: https://w3c.github.io/w3process/registries/
Also available as a Diff against the master branch of the process

[edent]

I think that new section is clear and well presented.

[jeffjaffe]

Here seems to be the alternate proposal.

https://www.w3.org/wiki/Registries#Proposed_Process_Text_.E2.80.93_Registries

[frivoal]

@fantasai and I just made a document to summarize the differences between our proposed text and David's.

https://lists.w3.org/Archives/Public/www-archive/2020Jan/att-0007/regdiff.html

While doing this, we made some adjustments to our proposal to reduce gratuitous differences and to take inspiration from David's text in cases where it was more specific or easier to understand.

Other than that, I think the main differences seem to be:

• David's text talks a fair bit about editor's drafts and tooling; this isn't specific to Registries vs other technical reports and is currently out-of-scope for the Process.

• David's text is somewhat ambiguous about whether updating registry values is allowed in registries published as REC-track documents without satisfying the general requirements for substantive changes; our text makes this more explicit by defining them as a new class of changes and explicitly defining that they are allowed.

• Because it uses RECs directly to host the registry rules (and possibly the values), David's text implies that we would have calls for exclusions (and other patent policy mechanics) on registry documents despite the lack of patentable material in that document. Similarly, we'd go through both a CR and PR phase, even though the difference between CR and PR is implementation experience, which is not a relevant concept for registries. Originally, fantasai's porposal did this as well; however because of these issues, the current proposal instead introduces a simplified "Registry Track", similar to the REC track, but with the irrelevant parts removed. This results in more Process document text in our proposal than in David's, but involves less process for Working Groups.

• David's text is not complete: section "Combined Publication" describes an issue and outline possible solutions, but not actual process text. (Ours currently allows two of the three proposed possibilities in David's issue description.)

[frivoal]

As per https://www.w3.org/2020/01/29-w3process-minutes.html and https://www.w3.org/2020/02/12-w3process-minutes.html, this issue is deferred to a subsequent cycle of the Process.

[plehegar]

Sept 16, Registries Presentation at TPAC 2020:, Dec 09, Jan 06, Survey results

[msporny]

Just documenting what the W3C Verifiable Credentials Working Group, the W3C Decentralized Identifiers WG, and W3C Credentials Community Group (and Linked Data Security subgroup) are doing wrt. registries:

1. Both the VCWG and DIDWG spent quite a bit of time working through the details of the process of managing the registry. Each time, even though each group had around 50% overlap wrt. participants, it felt like we were starting the Registries Process discussion from scratch. Discussion spanned six months, and took several hours of WG/Chair/Editor time to sort out the details.
2. Each WG established the registry maintenance process and documented it in each registry. For example, the current process for the DID Specification Registries is here: https://w3c.github.io/did-spec-registries/#the-registration-process
3. At a high level, both groups deferred the day to day operation of the registry to the Credentials Community Group. The CCG has multiple weekly meetings, the Maintenance WGs would meet every quarter or so. That is, the Editors of the registries would operate from within the CCG to ensure the ability to do broad review that pull in the appropriate people but while not going outside of the boundaries of the process established by the WGs.

There have been challenges. For example, the VCWG has been operating in maintenance mode, but not much work has been done on the registries due to questions mostly unrelated to the registries. While the process for the VCWG registries is clear, the Editors coordinating the work between the VCWG and CCG have been hesitant to do work on the registries due to process questions related to the main specification. This isn't a failure of the registries process, per se, just an indication that if there is a question related to WG->CG interaction, people seem to default to not letting anything through until there is clarity on all process issues (because some are concerned that there might be a process issue w/ the registries if there is a process issue with the main specification). Most of the process issues have been around errata, what the definition of "maintenance" means in a maintenance WG, and things related more to "What exactly is a Maintenance WG? What is the definition of "maintain"? Bug fixes are clearly in its purview to fix and publish errata for. Is it allowed to do substantive new feature additions to the main spec to track what's happening in industry? Or must it recharter to do that?" -- and so the Maintenance WG spends its time wrestling those things to the ground and ends up not having enough time to actually discuss how maintenance on the registry is performed... which then backs up on the Editors because they don't want to do things to the registry if it's going to take months to get issues onto the Maintenance WG docket.

All that said, none of this is causing ecosystem-destabilizing issues, but it is limiting the timeliness of the registries. Having some standard W3C Registries Process and W3C Maintenance WG Process, namely, what's in scope and out of scope and best practices wrt how a WG and a CG should work together to maintain a registry might go a long way to prevent the issues that the VCWG and DIDWG have experienced.

[johnfoliot]

This has come up at APA WG, where we note that there is already at least one instance where we really could have used a registry, but instead were obligated to include a collection of taxonomy terms directly into the latest WCAG 2.1 Specification (see Section 7: https://www.w3.org/TR/WCAG21/#input-purposes)

Observers will note that these terms are the same terms as the (current) normative list of attribute values for @autocomplete. However, because the HTML 5 Living Spec is under the control of the WHAT WG there was a concern that a change made there MAY have an impact on the WCAG Specification, which because of legislations around the planet related to "legal conformance" cannot use the Living Specification model. So we currently have duplication of those terms/values (taxonomies) across the two specs.

Finally, the Personalization Task Force is seeking to expand on the use-case that was the driver for SC 1.3.5, by introducing the draft @data-purpose, where once again we seek to re-use the initial taxonomy values. Additionally, the three related modules of that Spec have multiple other taxonomy 'lists' that would be better served as references from a registry rather than 'hard-coded' values in the spec - the 'hard-coded' option potentially being TOO brittle a solution.

So while I cannot and will not speak for the multiple Accessibility groups impacted here (APA WG/Personalization TF & AG WG), as an active participant in all three groups I can state that I believe it is something that the larger W3C/WAI would strongly support.

[frivoal]

The overall pull request for this topic (#335) has finally been accepted and merged (hurray!). Further tweaks and other adjustments can of course be proposed and discussed, but please open individual issues for that.

[gsnedders]

Someone should probably update https://www.w3.org/wiki/Registries now this has been resolved.

[plehegar]

Someone should probably update https://www.w3.org/wiki/Registries now this has been resolved.

I updated the wiki page to indicate that Process 2021 solved the issue. Thanks for the report.