This is a boilerplate Registry Definition as required by [[w3c-process]] for w3c registries.

The intent is that this boilerplate can form the basis of w3c registries for the W3C Timed Text Working Group.

See discussion w3c/ttwg#241 for details of the assumptions made to generate this document.

This document is intended to be the basis of other w3c registries published by TTWG and is not intended to be published as a w3c registry itself. The following SOTD text is auto-generated by the Respec tool to reflect what an actual registry definition document would contain.

Introduction

Replace the text in this section with some informative introductory text about this Registry.

This document is intended to be used as the basis for w3c registries for the W3C TTWG. The [[w3c-process]] sets out requirements for such w3c registries, and defines core concepts like registry definition and registry table.

Registry definitions need to fulfil certain criteria, including specifying custodianship, the change process, and defining the registry table itself.

The text in the section can be used to meet those criteria and allow more rapid creation of registries without having to create new text each time.

This document also includes appendix to facilitate adoption.

Registry Definition

This section specifies the registry definition, consisting of the custodianship, change process and the core requirements of a registry table.

Custodianship

The custodian of this w3c registry is the TTWG. If the TTWG is unable to fulfil the role of custodian, for example if it has been closed, the custodian in lieu is the W3C Team.

Change Process

Requesting a change

Changes to this W3C Registry MUST be requested (the change request) using any one of the following options:

The change request MUST include enough information for the custodian to be able to identify all of:

The proposer of the change MAY open a pull request (or equivalent) on the registry table's version control system, with that pull request containing the proposed changes. If a pull request is opened then a corresponding issue MUST also be opened and the pull request MUST be linked to that issue.

Change request assessment process

The process for assessing a change request depends on the custodian.

Custodian is TTWG

If the custodian is the TTWG:

  • If the change proposer did not open a pull request on the registry table's version control system, then assessment is paused until a TTWG member has opened such a pull request, which MUST represent the requested changes and MUST be linked to a related issue.
  • The TTWG follows its Decision Policy to review the proposal in the pull request.
  • At the end of the Decision Review Period if a TTWG Chair declares that there is consensus to approve, the change request is approved.
  • In the absence of consensus to approve the expectation is that a discussion will happen, to include the change requester. The result of this discussion can be any one of:
    1. the change request is abandoned;
    2. the change request is modified for another review;
    3. if the discussion resolves the objections, and a TTWG Chair declares consensus to approve, the change request can be approved.

An approved change request is enacted by merging its related pull request into the registry table's version control system and publishing the updated version of the registry table.

Custodian is the W3C Team

If the custodian is the W3C Team, the Team MUST seek wide review of the change request and offer a review period of at least 4 weeks, before assessing from the responses received if there is consensus amongst the respondents.

The Team MAY require a pull request on the registry table's version control system to be opened as the basis of the review.

If there is such consensus, the Team MUST make the proposed changes.

Registry Table(s)

This section defines constraints on registry tables. Each registry table consists of a set of registry entries.

The registry table MUST provide a link to the version control system against which any issues and pull requests can be opened.

Registry Entries

Each registry entry has a status, a unique key, and if appropriate, other fields, for example any notes, a description, or a reference to some other defining entity.

The registry table definition MUST define the fields and the key to be used in each registry entry.

Status

The registry entry status field reflects the maturity of that entry. Permitted values are:

            Provisional
            Final
            Deprecated

No other values are permitted.

Provisional

Registry entries with a status of Provisional MAY be changed or deleted. Their status may be changed to Final or Deprecated.

Registry entry keys in Provisional entries that were later deleted MAY be reused.

Newly created registry entries SHOULD have status Provisional.

Final

Registry entries with a status of Final MUST NOT be deleted or changed. Their status MAY be changed to Deprecated.

Registry entry keys in Final entries MUST NOT be reused.

Newly created registry entries MAY have status Final.

Deprecated

Registry entries with a status of Deprecated MUST NOT be deleted or changed. Their status MAY be changed to Final unless that would result in a duplicate key within the set of entries whose status is either Provisional or Final.

Registry entry keys in Deprecated entries that were previously Provisional and never Final MAY be reused.

Registry entry keys in Deprecated entries that were previously Final MUST NOT be reused.

Newly created registry entries MUST NOT have status Deprecated.

Registry Table(s)

This section contains the registry table, i.e. the set of registry entries.

Key Status Other fields Notes
abc1 Provisional This key reuses one that was deprecated without being Final
abc2 Final This entry cannot be changed, but it can be Deprecated.
abc1 Deprecated This was never made Final, and now it cannot be, because its key has been reused.

No conformance requirements are permitted in registry tables. If there are conformance requirements associated with registry entries, then they must be defined in the referencing specification.

Referencing Specifications

Although the formal definition of a Registry includes the referencing specifications, there is no need to list those referencing specifications in the Registry itself; doing so is optional. Listing referencing specifications carries an additional maintenance overhead.

Checklist for applying this boilerplate to a real Registry

When adopting this boilerplate for use in a Registry, the following checklist may be helpful: