David Singer, Process CG chair

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


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


  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


  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


Registry definition


Publishing together

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

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)

More information

More extensive discussion and process requirements on a Wiki

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

Thank you!