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 notifications@github.com 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 https://github.com/w3c/webauthn/pull/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

[dret]

On 2019-05-10 17:15, David Singer wrote:

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

what's the best way to comment/discuss a variety of the documented requirements? i just want to make sure this is done in a way that works best.

https://tools.ietf.org/html/draft-wilde-registries has a bit more elaborate model of registries. it could be one idea to simply use that one, and i'd be more than happy to adjust where it doesn't seem to fit.

[dwsinger]

comments here in the issue are fine

[dret]

• "A registry is a table that documents logically independent 'atoms'; conceptually a table with independent rows" -> it also is a set of rules how to manage that table. often the table also has columns with specific meaning, such as timestamps, author info, or a "deprecated" label.
• "Registries are purely documentational and contain no requirements." -> in most cases they do. most require the meaning of entries to be kept stable over time. most have additional requirements in terms of adding/changing/deprecating/removing entries.
• " hosted in a way that preserves history (e.g. Git, a Wiki)" -> it's rather different to keep an edit history of a web page that represents a registry (such as a wiki), or to keep a history of the actual registry changes. it may make sense to require the latter, so that for example machinery can be built around managing changes. in this day and age, one might even go as far as requiring an API that makes both the content as well as the history machine-readable.
• in the "The registry:" section, maybe add the API, a published/machine-readable history of the registry actions, possibly provide an outline of standard columns (value, description, timestamp, deprecation, reference to definition, ...)
• it might make sense to provide a "menu" of registry policies that w3c groups can choose from, so that they don't have to write their own. they may be allowed to write their own, but in most cases, they's probably happily choose from a small set of standard choices.

[dret]

to be honest, i am a bit confused by the title of this issue: "We need a process for handling registries, APIs and other 'enumerations'" i completely get the need for registries. how do APIs factor into this, and how are they related or something similar to registries?

[dwsinger]

We have a few APIs at the W3C that are 'mapping' APIs, and every time there is a new feature in the spec. they are mapping, a new matching 'API' has to be inserted in the API registry, as I understand. But I'd like someone to confirm (I don't manage such an API myself).

• "A registry is a table that documents logically independent 'atoms'; conceptually a table with independent rows" -> it also is a set of rules how to manage that table. often the table also has columns with specific meaning, such as timestamps, author info, or a "deprecated" label.

Thank you, added "** the rules for values (logically, the column values) in each entry (e.g. uniqueness, matching to a value from some other specification or registry, etc.)"

• "Registries are purely documentational and contain no requirements." -> in most cases they do. most require the meaning of entries to be kept stable over time. most have additional requirements in terms of adding/changing/deprecating/removing entries.

Right, and we're saying that those rules are in the document, not (solely) in the registry, so that the rules get the review to the level required for the referencing document.

• " hosted in a way that preserves history (e.g. Git, a Wiki)" -> it's rather different to keep an edit history of a web page that represents a registry (such as a wiki), or to keep a history of the actual registry changes. it may make sense to require the latter, so that for example machinery can be built around managing changes. in this day and age, one might even go as far as requiring an API that makes both the content as well as the history machine-readable.

Most Wikis I know keep version history, and obviously Git does. Do we need to establish that a record is kept directly of requests, as well?

• in the "The registry:" section, maybe add the API, a published/machine-readable history of the registry actions, possibly provide an outline of standard columns (value, description, timestamp, deprecation, reference to definition, ...)

add what API? added "* managed such that registration history (requests and actions) are archived (e.g. a W3C mailing list archive, pull request history, etc.)"

• it might make sense to provide a "menu" of registry policies that w3c groups can choose from, so that they don't have to write their own. they may be allowed to write their own, but in most cases, they's probably happily choose from a small set of standard choices.

yes, maybe, but at this level I am trying to tease out what the rules and recommendations are.

[dret]

On 2019-05-13 08:57, David Singer wrote:

We have a few APIs at the W3C that are 'mapping' APIs, and every time there is a new feature in the spec. they are mapping, a new matching 'API' has to be inserted in the API registry, as I understand. But I'd like someone to confirm (I don't manage such an API myself).

i am still not quite understanding, but it seems to be sufficiently different from registries to maybe need a different support mechanism?

  * "A registry is a table that documents logically independent
    'atoms'; conceptually a table with independent rows" -> it also
    is a set of rules how to manage that table. often the table also
    has columns with specific meaning, such as timestamps, author
    info, or a "deprecated" label.

Thank you, added "** the rules for values (logically, the column values) in each entry (e.g. uniqueness, matching to a value from some other specification or registry, etc.)"

with rules i was more referring to the way how entries are added, updated, and removed, and how those rules may directly or directly result in populating the table cells.

  * "Registries are purely documentational and contain no
    requirements." -> in most cases they do. most require the
    meaning of entries to be kept stable over time. most have
    additional requirements in terms of
    adding/changing/deprecating/removing entries.

Right, and we're saying that those rules are in the document, not (solely) in the registry, so that the rules get the review to the level required for the referencing document.

true. but the point is: if there is a requirement for some process, you cannot just go ahead and change the document/registry. you have to follow the process, wherever/however that is defined.

  * " hosted in a way that preserves history (e.g. Git, a Wiki)" ->
    it's rather different to keep an edit history of a web page that
    represents a registry (such as a wiki), or to keep a history of
    the actual registry changes. it may make sense to require the
    latter, so that for example machinery can be built around
    managing changes. in this day and age, one might even go as far
    as requiring an API that makes both the content as well as the
    history machine-readable.

Most Wikis I know keep version history, and obviously Git does. Do we need to establish that a record is kept directly of requests, as well?

i think so, personally. i wouldn't be interested in the edit history of the publishing mechanism of the registry. i'd much rather have a clear and well-defined history of the relevant changes to the registry content (as opposed to the registry representation).

  * in the "The registry:" section, maybe add the API, a
    published/machine-readable history of the registry actions,
    possibly provide an outline of standard columns (value,
    description, timestamp, deprecation, reference to definition, ...)

add what API?

the API for a registry. given where we are today, i think it really would make sense to say that at least each registry must be accessible through a well-defined API, and ideally its history should be part of that history as well. i think it would be ok to have that as a read-only API (i.e., no registry updates through the API), but it would be a wasted opportunity to not make newly designed registries machine-readable.

added "* managed such that registration history (requests and actions) are archived (e.g. a W3C mailing list archive, pull request history, etc.)"

good, and potentially/ideally not just in a way that's accessible for humans.

  * it might make sense to provide a "menu" of registry policies
    that w3c groups can choose from, so that they don't have to
    write their own. they may be allowed to write their own, but in
    most cases, they's probably happily choose from a small set of
    standard choices.

yes, maybe, but at this level I am trying to tease out what the rules and recommendations are.

ok. then we can table this until things develop a bit further.

[fantasai]

Straw man proposal:

• Registries are developed through the normal standards track, and are published on /TR just like other technical reports.
• Registries are defined as part of a specification that defines an extensible/updatable table of items. A single REC-track specification can contain have multiple of these (i.e. zero or more).
• The section defining the registry must a) state that it is a Registry per the W3C Process, b) define the fields of its table of items, c) define the method and criteria by which changes are proposed and incorporated.
• Changes to the registry other than adding/removing/updating entries in the registry go through the normal specification change process.
• However, adding/removing/updating entries in the registry can be done through a lightweight process similar to how we handle editorial changes.

[dwsinger]

Hm, I think Elika's suggestions at https://github.com/w3c/w3process/issues/168#issuecomment-494548508 and mine at https://github.com/w3c/w3process/issues/168#issuecomment-491462400 are very similar...

[michaelchampion]

I think this is a good starting point and agree with all but possibly the first point. I wonder about the use case of a CG owning a registry .... Or maybe it’s OK To insist that if a group wants an authoritative registry in /TR, they need to go through at least a streamlined version of Charter to ensure there is consensus to let them.

[fantasai]

@michaelchampion Community Groups can publish Community Group Reports of whatever they want; afaict if they want to make a registry of stuff there's no reason they can't do so right now.

[fantasai]

@dwsinger I think the main difference is that mine just inlines the registry into the /TR publication so that the questions of where and how it's hosted and what archiving and update mechanisms are involved are already solved. ;)

[chaals]

Update mechanics are important, and this is something that is better defined in @dwsinger's proposal although it would probably help to have some concrete working examples.

[dwsinger]

I think the only difference is minor, and we should merge when we resolve this:

• I propose a 'W3C Registries' page which links to all registries managed under the policy, and they in turn link back to their enclosing document (Rec, CG Report, Note, whatever);

• Elika proposes that the Registries be in /TR

[kcoyle]

A working registry that versions updates of each data element in the registry can be seen here. Notice also that each element has a status, such as "added" "published" "deprecated". This registry is already being used for large metadata sets.

I think that the broad definition of registries that seems to be being used here is going to be an impediment to development. Registration of ontologies will have different requirements from registration of datasets and from registration of data elements. I see a mixture of assumptions in the answers and it seems we are not always talking about the same thing. Can we narrow / split our field so that the discussion is more focused?

[nrooney]

I +1'ed to a few of @fantasai's comments which I believe are similar to some of @dwsinger's.

Items going into the registry should have been discussed as part of the document's progression through the Rec Track; so by the time a document is ready to move to the final stages of the Process the adding of items to the registry should have already been discussed. Therefore a lightweight method of adding items to a registry sounds sensible.

[nigelmegitt]

Registries are defined as part of a specification that defines an extensible/updatable table of items.

@fantasai are you suggesting that some subsections of Recs are actually inlined data sourced from other sources which can be updated in-place? So I might look at a spec one day, and see it say some text, and then the next day it shows something different?

Inlining seems both convenient for quick reading and also inconvenient because the updatable content might not be super-obviously subject to change. If someone references a dated version of a spec containing a registry they probably don't expect its contents to change. Requiring that a link is traversed in order to find the "current" version of a registry avoids this.

On balance I'd tend to avoid inlining registry content within Recs for this reason.

Another feature of a registry that would be useful is a change notification service, analogous to (or actually?) an RSS feed for that registry, that can be subscribed to so interested parties can make their own updates, e.g. to implementations, in a timely way.

[TzviyaSiegman]

On balance I'd tend to avoid inlining registry content within Recs for this reason.

I agree with @nigelmegitt that inlining registry content could lead to some difficulties. I think registries need to be easily updatable.

[dret]

On 2019-05-21 22:36, fantasai wrote:

Straw man proposal:

• Registries are developed through the normal standards track, and are published on /TR just like other technical reports.

does that refer to the spec establishing the registry, or the registry itself? IETF has RFC 8126 which defines how to establish registries, and an RFC one will be published in the regular RFC stream. the registry itself though is a different thing and available elsewhere. it seems that this setup makes sense, but i am not sure whether that's what you mean here.

• Registries are defined as part of a specification that defines an extensible/updatable table of items. A single REC-track specification can contain have multiple of these (i.e. zero or more).

that's what RFC 8126 defines in the IETF space. it would probably take an equivalent REC to specify how a REC has to establish a registry.

• The section defining the registry must a) state that it is a Registry per the W3C Process, b) define the fields of its table of items, c) define the method and criteria by which changes are proposed and incorporated.

https://tools.ietf.org/html/draft-wilde-registries-02#section-6 has a few more things that might be worth considering.

• Changes to the registry other than adding/removing/updating entries in the registry go through the normal specification change process.

that's an interesting one. i am not sure IETF even has a process for changing a registry. once it is established, it is supposed to work as specified.

• However, adding/removing/updating entries in the registry can be done through a lightweight process similar to how we handle editorial changes.

it might be good to keep a history of the registry, or even a history of individual entries.

additionally, it might be a good idea to make sure that there is an API for a registry, i.e. that there is a way how to get a machine-readable version of at least the registry contents, and potentially the history as well.

[dret]

On 2019-05-21 23:49, fantasai wrote:

@dwsinger https://github.com/dwsinger I think the main difference is that mine just inlines the registry into the /TR publication so that the questions of where and how it's hosted and what archiving and update mechanisms are involved are already solved. ;)

now i understand: the registry is a TR, not just the document establishing it.

just as food for thought: IETF has 2000+ registries (with of course far more values in them), with quite a number of updates happening. looking at this, maybe treating every update of a registry as something that triggers a published TR update might become relatively noisy.

at a more abstract level, i would argue that specifications and registries are different things, and it makes sense to manage and publish them separately. but that's probably mostly a matter of opinion.

[dret]

On 2019-05-21 23:56, chaals wrote:

Update mechanics are important, and this is something that is better defined in @dwsinger's proposal https://www.w3.org/wiki/Repositories#Recommendation although it would probably help to have some concrete working examples.

for a more extensive list of things to consider, https://tools.ietf.org/html/draft-wilde-registries-02#section-6 has some food for thought.

typically, registries operate in a framework given by general registry mechanics (which are established by a spec defining the registry mechanism). for example, a specific registry can define whether it allows to remove values, or not.

[dret]

On 2019-05-22 13:41, thisNatasha wrote:

Items going into the registry should have been discussed as part of the document's progression through the Rec Track; so by the time a document is ready to move to the final stages of the Process the adding of items to the registry should have already been discussed. Therefore a lightweight method of adding items to a registry sounds sensible.

it's not a given that registries will only allow updates made through the W3C TR process. it probably should be up to the individual registry to define what hoops update requests have to jump through.

[dret]

On 2019-05-22 14:43, Nigel Megitt wrote:

@fantasai https://github.com/fantasai are you suggesting that some subsections of Recs are actually inlined data sourced from other sources which can be updated in-place? So I might look at a spec one day, and see it say some text, and then the next day it shows something different?

i think the suggestion is that the registry itself is a REC that is always republished when it is updated.

Inlining seems both convenient for quick reading and also inconvenient because the updatable content might not be super-obviously subject to change. If someone references a dated version of a spec containing a registry they probably don't expect its contents to change. Requiring that a link is traversed in order to find the "current" version of a registry avoids this.

+1; to me a registry is something different than a spec.

Another feature of a registry that would be useful is a change notification service, analogous to (or actually?) an RSS feed for that registry, that can be subscribed to so interested parties can make their own updates, e.g. to implementations, in a timely way.

+1, that's the idea of an API for registries and their updates, and Atom might be a good choice there.

it might be worthwhile to think about the problem of traffic volume, though. if you end up having implementations that constantly pull the feed, that might create some issues for popular registries.

[dret]

On 2019-05-22 14:47, Tzviya wrote:

I agree with @nigelmegitt https://github.com/nigelmegitt that inlining registry content could lead to some difficulties. I think registries need to be easily updatable.

once again just pointing to IETF here: in their model, the RFC establishing the registry often also specifies the initial contents. the current content then is available in the registry only.

[edent]

You may be interested in the work the UK Government is doing with Registers. https://gov.uk/registers

If I've understood this discussion correctly, this could be a model for registries.

For example, there is a canonical register of every country the UK Government recognises - https://www.registers.service.gov.uk/registers/country - it also includes countries which no longer exist, and metadata about them. Each register is maintained by a named owner, and they commit to regularly updating them. They're also cryptographically signed so that end users can be assured that they have not been compromised.

There's more detail at https://www.registers.service.gov.uk/about/characteristics-of-a-register - and I'm happy to link anyone up to the team which looks after them.

(I'm not the GOVUK rep any more - but still maintain an interest.)

[michaelchampion]

@edent wrote

Each register is maintained by a named owner, and they commit to regularly updating them. They're also cryptographically signed so that end users can be assured that they have not been compromised.

I think that captures the essence of a "registry" -- there is some specific owner, presumably chosen based on qualifications, who is accountable for keep the registry up to date and accurate, and a verification mechanism to ensure that updates are actually made by the owner.

[fantasai]

@fantasai are you suggesting that some subsections of Recs are actually inlined data sourced from other sources which can be updated in-place?

Yes, effectively. Not in-place as in changing a dated publication, but in-place as in the "latest version" of the spec always includes the latest copy of the registry data.

Inlining seems both convenient for quick reading and also inconvenient because the updatable content might not be super-obviously subject to change.

A registry needs to be clearly labelled as such, to opt in that data to the registry-update process. As I said, “The section defining the registry must a) state that it is a Registry per the W3C Process, b) define the fields of its table of items, c) define the method and criteria by which changes are proposed and incorporated.”

If someone references a dated version of a spec containing a registry they probably don't expect its contents to change. Requiring that a link is traversed in order to find the "current" version of a registry avoids this.

The dated version of a spec won't change. Only the undated one. Each change to the registry is an updated publication, just like any editorial change to the spec is an updated publication.

Another feature of a registry that would be useful is a change notification service, analogous to (or actually?) an RSS feed for that registry, that can be subscribed to so interested parties can make their own updates, e.g. to implementations, in a timely way.

I believe there is already an RSS feed for /TR documents. W3C might consider having per-spec RSS feeds as well. If there's a need for some more specialized data service, the WG can provide one however is convenient for the users and maintainers. There are plenty of websites out there serving copies of the ISO language codes and Unicode tables, for example--not every copy has to be served by ISO.

I think registries need to be easily updatable.

The group in charge of maintaining the registry should set up appropriate tooling, e.g. pulling data from a GH-hosted TSV once a day and, if there are changes, building it into a spec, and publishing it with Echidna. Or whatever. The registry can be inlined in the spec as a table, and/or served as a separate TSV, JSON, or other file data in the publication directory, same as other support materials like images and examples and indexes.

it might be worthwhile to think about the problem of traffic volume, though. if you end up having implementations that constantly pull the feed, that might create some issues for popular registries.

Scaling up hosting is an issue no matter what process we decide on, but ultimately we just need to host the official copy. W3C can faciliate serving copies of the data off of someone else's more robust server if needed (using appropriate data formats / APIs) and even offer a w3.org URL for the /TR documents to link to for high-traffic pulls, interesting data queries, and the like.

Hosting directly on /TR quickly and neatly solves the questions of what format, where to host, whether to design and build some new system for serving the data, and how to handle issues like archiving, longevity, branding, reputation, and authority. The issues of convenience and speed can be solved with mirrors.

now i understand: the registry is a TR, not just the document establishing it. just as food for thought: IETF has 2000+ registries (with of course far more values in them), with quite a number of updates happening. looking at this, maybe treating every update of a registry as something that triggers a published TR update might become relatively noisy.

We already have specs which are updated almost daily. This wouldn't be a new problem. And it would not be necessary to announce the registry updates. :) Announcements should be reserved for substantive changes to the framework of the registry, or if the WG particularly wants to announce some set of changes.

Importantly, we are already publishing registries like AAM through the spec publication process. This proposal just streamlines it so that these become practical to maintain.

[frivoal]

I think an other important question is where does stability come from. In the case of specifications, it comes from having multiple implementations that demonstrably match the spec, with the market relying on them so much that changing is generally not practical. Because of that, we don't really need a rule saying that updates to a REC must be compatible with the previous publication of this REC.

For registries there's no such thing. In the general case, there is no expectation that each entry in a registry will necessarily have multiple implementations. There are also different kind of expectations on different registries:

• some can be updated and changed, you just need to not be reckless about it, kind of like specs
• some should be append only
• some should allow appending and deprecating, but never removing or changing
• Flexible initially, then append only (or append / deprecate) after certain maturity criteria have been met

At which level do we want to enforce that:

1. trust the consensus of the WG and its chairs to not do anything silly
2. require each registry to have an "updating policy" section, which has to be followed (publication is denied if it isn't followed, it's valid ground for formal objections, etc)
3. Charters must have an update policy for each registry the WG hosts
4. The Process dictates what can be done

I kind of prefer something along the lines of 2, so that it's enforceable while still letting us account for the diversity of needs for different registries, but that raises the question of what the rules for changing the "updating policy" are. It feels that this is something that should be hard to do, but not necessarily impossible.

[dret]

On 2019-05-23 07:28, Florian Rivoal wrote:

I think an other important question is where does stability come from. In the case of specifications, it comes from having multiple implementations that demonstrably match the spec, with the market relying on them so much that changing is generally not practical. Because of that, we don't really need a rule saying that updates to a REC must be compatible with the previous publication of this REC.

so that's about the REC establishing the registry, right? in the registry model, you don't update the REC. in the REC, you simply refer to the registry and say that whatever value space is managed there is the one that people should look at. the important aspect is that registry entries need to be stable, too (i.e., no updates change change the meaning of existing entries, and mostly just additions anyway).

For registries there's no such thing. In the general case, there is no expectation that each entry in a registry will necessarily have multiple implementations.

i don't quite follow. what's the "implementation of an entry"? let's take a simple example of a language tag registry. the entry "en" may not be recognized/supported by all implementations using languages, but those that do need to be able to depend on the fact that this value will always identify the english language.

There are also different kind of expectations on different registries:

• some can be updated and changed, you just need to not be reckless about it, kind of like specs

in terms of breaking changes? i would disagree.

• some should be append only

yes, that's one policy.

• some should allow appending and deprecating, but never removing or changing

yes, that's another popular policy.

• Flexible initially, then append only (or append / deprecate) after certain maturity criteria have been met

some have "experimental" status for entries, but to me that's a slippery slope because it's hard to say how that should work for implementations.

At which level do we want to enforce that:

1. trust the consensus of the WG and its chairs to not do anything silly

that would be when establishing the registry (and its initial contents)

2. require each registry to have an "updating policy" section, which has to be followed (publication is denied if it isn't followed, it's valid ground for formal objections, etc)

that would be a very good idea.

3. Charters must have an update policy for each registry the WG hosts

i am not quite sure what this means.

4. The Process dictates what can be done

the question is whether defining policies is open, or you define a closed set of policies registries can choose from.

I kind of prefer something along the lines of 2, so that it's enforceable while still letting us account for the diversity of needs for different registries, but that raises the question of what the rules for changing the "updating policy" are. It feels that this is something that should be hard to do, but not necessarily impossible.

i am not sure it would be good to allow updates of the update policy. that would essentially undermine the idea that people can depend on how a registry evolves. they might depend on entry semantics being stable, and then the registry changes its policy that there can be breaking changes to updates. that would break implementations depending on the initially defined policy.

[frivoal]

i don't quite follow. what's the "implementation of an entry"?

That would depend on the type of registry. For some things (a list of languages), speaking of implementation doesn't make sense. For others it might: a list of video codec is a list of things that can be implemented. But there probably wouldn't be an expectation that all UAs implement all video formats. The registry could be used by a capability discovering API, and so it would be expected that many entries would not be implemented by many implementation.

Regardless, the point is, for REC, something qualifies when it has 2 implementations (roughly speaking). For registries, that doesn't work.

some can be updated and changed, you just need to not be reckless about it, kind of like specs in terms of breaking changes? i would disagree.

Again, that would depend on the type of registry. The example given earlier by @edent of the list of countries recognized by the UK government does change and update existing entries, and that's perfectly reasonable for that registry. The same policy would not be reasonable for a list of codecs

3. Charters must have an update policy for each registry the WG hosts i am not quite sure what this means.

It means that if several policies are possible for maintaining a registry, it's not the working group who decides which one they will follow, but the Advisory Committee when they create (or update) the working group.

i am not sure it would be good to allow updates of the update policy.

I am quite sure that it would be bad to allow that to happen lightly. But you can never completely ban it: in the worse case, people can start a completely separate registry with the same information and a different policy. This is a human endavor, and mistakes will be made. So when we realize that we made a mistake in the update policy of a particular registry, it would be good if we had the option to fix it. So I think having some kind of hard-but-possible to change path for updating the update policy would be probably a good thing.

[nigelmegitt]

Not in-place as in changing a dated publication, but in-place as in the "latest version" of the spec always includes the latest copy of the registry data. ... The dated version of a spec won't change. Only the undated one.

@fantasai I'm struggling to understand this: isn't every "latest copy" an alias to a dated version? In your proposal, does an update to a registry automagically generate a new dated version of the Rec that references it, and then update the "latest" link to point to the updated Rec?

W3C might consider having per-spec RSS feeds as well. If there's a need for some more specialized data service, the WG can provide one however is convenient for the users and maintainers.

+1

2. require each registry to have an "updating policy" section, which has to be followed (publication is denied if it isn't followed, it's valid ground for formal objections, etc)

@frivoal : +1 to option 2.

@edent thank you for the links, that's a really useful page. Text from that page:

each register has a named owner called a ‘custodian’.

In the case of W3C I think it would be reasonable to assign custodianship to a group as an alternative to an individual.

[dwsinger]

I have read the comments above and tried my hardest to incorporate them into a revised Wiki text at https://www.w3.org/wiki/Repositories. It would probably help me more if people had more specific edits (or wholesale replacement text)...