Definitions and Goals

Definitions (rough)

1. A registry contains essentially independent registered entries ('rows')
2. …has a management policy and process for updates
3. …often provides choices for something (field, attribute) in a specification

Goals

1. Registries should be easy to manage incrementally once set up
2. …and be separated from heavier-weight, slower, processes (like exclusions)

Elements

1. Referencing specification(s)
   • (e.g. the Recommendation that has a field in it)
2. Registry definition and rules
3. Published registry values (the body, contents, table)
   • (something new for W3C to publish)
4. Registry development and tracking

Rules

1. All requirements that affect implementations are in Referencing specification(s)
2. All rules of the registry management are in Registry definition
3. Values only in the Published Registry
4. References to the registry are to its Definition and/or Publication (in /TR)
   • not to where it's developed (e.g. Github, database, wiki)
5. Registry development and tracking must follow practices for any W3C publication

Publication

• Registry definition is approved and published like a Recommendation
• RegistryPublication happens following the rules approved in the Definition

Registry definition

• define the 'columns' and rules for their values
• define how to get a new registered value, application and approval process
• define the update policy: changes, retirements, re-use, etc.

Examples

• W3C Timing Entry Names
• The MP4 Registration Authority
• HTTP Cache Directive

Publishing together

Which elements can be, must be, or must not be, combined in one publication? (debate)

• Registry definitions + Published Registry values
• IETF style: Referencing document + Registry Rules, separate Published Registry (with back-pointer)
• All 3 together (good for simple cases)
• ISO style: publication and management are off the ISO site (bad idea)
• …

We may need a new type of specification (Registry Table, Registry Definitions)

Registry Definitions don't need Exclusion (we think)

Publication development rules (under discussion)

Probably apply to all publications; but Recs and Registries have different practice today

Example development rules for W3C publications (under debate)

• Must keep history
• Must have some request/issue/bug tracking
• Must permit notifications of changes, issues etc.
• Must be backed up by the W3C, should be referencable by a w3.org URL
• Must be accessible, viewable/usable by the W3C community
• …

More information

More extensive discussion and process requirements on a Wiki

Early draft of a process section, assuming one publication model, on Github