Introduction

This section is entirely informative and does not form an integral part of this Administrative Guideline.

This Administrative Guideline covers all classes of Entries defined across all Metadata Register Structure Documents specified by SMPTE, and specifies:

Scope

This Administrative Guideline specifies maintenance and publication processes specific to the SMPTE Metadata Registers.

Definitions

Controlling Organization

Entity responsible for the creation, modification or deletion of an Entry.

Node

Entry that can contain other Entries.

A more detailed definition is provided in each Metadata Register Structure Document.

Entry

Combines one UL and multiple associated properties.

Defining Document

Document referenced in the Defining Document property of an Entry.

A more detailed definition is provided in each Metadata Register Structure Document.

Metadata Register

Collection of Entries defined by a Metadata Register Structure Document.

Metadata Register Structure Document

SMPTE Engineering Document that defines a Metadata Register.

The SMPTE Registration Authority website lists Metadata Register Structure Documents, as provided by Section .

Release

A SMPTE Standard, or a revision or amendment thereof, whose elements consists of one or more Metadata Registers to be published.

UL

SMPTE-administered Universal Label as specified in SMPTE ST 298 and constrained by SMPTE ST 336.

General

Relationship with the Standards Operation Manual

This Administrative Guideline expands on the Standards Operation Manual, Section 5.2.5 as applied to Registers. In case of conflict with the Standards Operation Manual and this document, the former prevails.

Relationship with Metadata Register Structure Document

This Administrative Guideline supersedes all procedural material specified in Metadata Register Structure Documents, in general, and those listed in , in particular.

Superseded Procedures and Criteria.
SMPTE ST 335 Section 5 and Annex B
SMPTE ST 395 Section 5 and Annex B
SMPTE ST 2003 Section 5 and Annex B
SMPTE ST 400 Section 5 and Annex B

Metadata Register Sub Group

The Metadata Register Sub Group is the Sub Group (as defined in the Standards Operations Manual) responsible for developing Releases, as established by TC 30MR.

Metadata Register Structure Documents

The SMPTE Registration Authority website shall include a list of references to all Metadata Register Structure Documents, as determined from time-to-time by TC 30MR.

Current Version Byte

The SMPTE Registration Authority website shall include the current value of the version byte ("Current Version Byte") for each Metadata Register, as determined from time-to-time by TC 30MR.

Entry Management and Publication

Private-Use Entries

A Private-Use Entry is an Entry belonging to a top-level Class 14 Node whose control has been delegated to an entity other than SMPTE according to

The Controlling Organization of a Public-Use Entry can transfer control of the Entry back to SMPTE as specified in . lists Entries that were previously Private-Use Entries, but are currently SMPTE-Controlled Entries.

Private-Use Entries shall not be published by SMPTE. The Controlling Organization of a Private-Use entry is however encouraged to maintain and publish it using a method consistent with those specified herein.

The management and publication of Private-Use Entries is the sole responsibility of the Controlling Organization.

Public-Use Entries

A Public-Use Entry is an Entry belonging to a top-level Class 13 Node whose control has been delegated to an entity other than SMPTE according to .

The Controlling Organization of a Private-Use Entry can transfer control of the Entry back to SMPTE as specified in . 0 lists Entries that were previously Public-Use Entries, but are currently SMPTE-Controlled Entries.

Public-Use Entries shall be published by SMPTE using the Release process specified in Section .

Each Controlling Organization shall submit for publication all Public-Use Entries it defines.

SMPTE-Controlled Entry

A SMPTE-Controlled Entry is an Entry that is neither a Private-Use Entry nor a Public-Use Entry.

SMPTE-Controlled Entries shall be published by SMPTE using the Release process specified in Section .

No SMPTE Engineering Document should be balloted to FCD until all Entries it defines have reached the "mature" state.

No SMPTE RDD should undergo committee ballot until all Entries it defines have reached the "mature" state.

No SMPTE Engineering Document or RDD should be published until all Entries it defines have reached the "accepted" state.

Development and Publication of a Release

General

A Release follows the development process for Engineering Documents, as specified in the Standards Operations Manual.

The document number of the Release is assigned as provided in AG 02.

A Release typically includes Metadata Registers for all Metadata Register Structure Documents.

Initiation

A Release is initiated by creating a Working Draft consisting of all Entries whose Submission is in the "Accepted" state at the time of initiation.

As a result, only Entries that have undergone the Submission process are published.

A Release should be initiated twice every calendar year.

Modification of a Release during Development

No Entry should be added to a Release at or after Committee Draft stage.

Any correction to an Entry included in a Release shall be made through a Submission.

Release Project

There is one Project, as defined in the Standards Operations Manual, for each Release.

The Project shall be assigned to the Metadata Register Sub Group.

To help distinguish between Releases, the Project should be given a distinctive name.

EXAMPLE: Project names of past Releases have included condiment names such as "catsup" and "brown sauce".

Release Numbering

A Release is numbered according to the Document Numbering requirements specified in AG 02.

The Release document number shall include both Year of Issue and Month of Issue, since multiple Releases are planned in a given year.

Publication

Upon publication, a Release shall be made publicly available at the SMPTE Registration Authority website.

Amendment

The amendment of a Release should be reserved for correcting errors before the next Release.

EXAMPLE: Periodic Releases lessens the need for amendments.

Submission Process

General

A Submission is a Request to alter a Metadata Register. It follows the Submission process, which is specified in the following Sections and illustrated in Figure , and is intended to prepare stable Entries for inclusion in a Release.

provides selected examples of the Submission process.

Submission Process (informative).

The Metadata Register Sub Group shall make available to its parent Technology Committee all Submissions not incorporated in a Release. The Standards Vice President may, at his or her discretion, make the latter available publicly.

Initiation

A Submission achieves "initial_draft" state upon submission by a Submitter to the Metadata Register Sub Group.

The Submission shall meet the Acceptance Criteria specified in Section .

Submitters are encouraged to work with the chair of the Metadata Register Sub Group prior to initiating a Submission to ensure that it meets the Acceptance Criteria.

Initial_draft State

Actions

The Submission shall be offered for review to the Metadata Register Sub Group.

The Submitter shall be responsible for addressing any deviation from the Acceptance Criteria noted by the Metadata Register Sub Group, and submitting a revised Submission.

An "initial_draft" Submission is susceptible to significant substantive changes.

Transition to Draft state

The Submission shall transition to the "draft" state if:

  • every UL defined by the Submission has been reserved such that it is not available to any other Submission; and
  • the Metadata Register Sub Group has not determined, by consensus, that the Submission fails to meet the Acceptance Criteria.

Transition to Withdrawn state

The Submission shall transition to "withdrawn" if:

  • requested by the Submitter; or
  • the Submission has been abandoned, as determined by consensus of the Technology Committee of the Metadata Register Sub Group.

Draft State

Actions

The Submission shall be offered to the parent Technology Committee of the Metadata Register Sub Group for review.

A "draft" Submission remains susceptible to modifications following TC review.

The Technology Committee Chair determines the duration of the review, as needed to achieve the transition criteria of Section This duration can be arbitrarily short if, for instance, the Submission was previously reviewed and changes are trivial.

Transition to mature State

The Submission shall transition to the "mature" state unless the parent Technology Committee of the Metadata Register Sub Group has determined, by consensus, that the Submission fails to meet the Acceptance Criteria.

Members that wish to provide comments beyond those related to the Acceptance Criteria are encouraged to join the group responsible for the Submission .

Transition to initial_draft State

The Submission shall transition to "initial_draft" if any substantive modification is made to the Submission.

Transition to Withdrawn State

The Submission shall transition to "withdrawn" if:

  • requested by the Submitter; or
  • the Submission has been abandoned, as determined by consensus of the Technology Committee of the Metadata Register Sub Group.

Mature State

Transition to Accepted State

The Submission shall transition to the "accepted" state once the Defining Document of all Entries whose Defining Document is an Engineering Document or a Registered Disclosure Document, if any, has passed ST Audit and matches the contents of the Entry exactly.

The "mature" state is provided if the Defining Document might undergo further modifications, but requires a stable Submission to proceed.

A "mature" Submission is modified if the Defining Document is modified.

A Submission that does not include Entries from a Defining Document that is an Engineering Document or a Registered Disclosure Document shall transition to the "accepted" state immediately.

Transition to Initial_Draft State

The Submission shall transition to "initial_draft" if any substantive modification is made to the Submission.

Transition to Withdrawn State

The Submission shall transition to "withdrawn" if:

  • requested by the Submitter; or
  • the Submission has been abandoned, as determined by consensus of the parent Technology Committee of the Metadata Register Sub Group.

Accepted State

Modifications shall not be made to the Submission.

Withdrawn State

Actions

All ULs defined by the Submission shall become available to other Submissions.

Transition to Initial_Draft State

The Submission may transition to "initial_draft" if requested by the Submitter.

Acceptance Criteria (normative)

General

Submissions defining Public-Use Entries shall meet the criteria of Sections and .

Submissions defining top-level Class 13 or Class 14 Nodes shall meet the criteria of Sections and .

Submissions defining SMPTE-Controlled Entries other than top-level Class 13 or Class 14 Nodes shall meet the criteria of Sections and .

Common Criteria

Contact Information

The Submission shall include contact information for the Submitter.

Submission File Name

A submission should consist of a single zip file.

The filename of the zip file should conform to the following FILENAME syntax 

FILENAME := TC "-REG-" TYPE "-" DESCRIPTION "-" DATE
TC := 1*(ALPHA / DIGIT)
TYPE := "DD" / "CORR" / "CLASS13" / "CLASS14" / "MISC"
DATE := YYYY "-" MM "-" DD
YYYY := 4DIGIT
MM := 2DIGIT
DD := 2DIGIT

The TC field is the short name of the parent TC of the Metadata Register Sub Group, e.g. 30MR.

The TYPE field shall be selected based on the nature of the submission as specified in

Submission File Name Type Field.
TYPE Type of submission
DD Addition of an Entry
CORR Correction to an existing Entry
CLASS13 Class 13 Node Allocation
CLASS14 Class 14 Node Allocation
MISC Other

The MISC type is intended to be used if no other types fit, e.g. a Submission that both adds and corrects Entries.

The DESCRIPTION field shall be selected based on the value of the TYPE field.

Submission File Name Description Field.
TYPE DESCRIPTION
DD Concise description of item(s) being added (e.g. ST2067-1)
CORR Concise description of item(s) being corrected (e.g. Groups-IsConcrete)
CLASS13 Description of Class13 node owner and purpose of change (e.g. AVID-new-entries)
CLASS14 Description of Class14 node owner and purpose of change (e.g. AVID-new-entries)
MISC Other

The DATE field shall be the date when the Submission was initially submitted.

EXAMPLE 1: 30MR-REG-DD-ST2067-01-2017-12-10.zip

EXAMPLE 2: 30MR-REG-CLASS13-LOC-new-entries-2017-10-10.zip

Contents

A Submission shall consist of one or more documents, each containing Entries that belong to one Metadata Register.

Each XML document shall conform to one of the XML Schema definitions, which shall be determined by TC 30MR from time-to-time and published on the SMPTE Registration Authority website.

The filename of each document should conform to the following DOCNAME syntax: 

DOCNAME := TC "-REG-" TYPE "-" DESCRIPTION "-" REGISTER
REGISTER := "groups" / "elements" / "labels" / "types"

where the TC, TYPE and DESCRIPTION fields shall match that of the Submission file name (Section ).

EXAMPLE: 30MR-REG-DD-ST2067-01-groups.xml, 30MR-REG-CLASS14-XYZCorp-labels.xml

The filename of each document shall remain constant throughout the Submission process.

Unique UL

No UL added by the Submission shall be equal to any published or reserved UL.

This equality shall ignore the value of the Version Byte (Byte 8).

Conformance with the Metadata Register Structure Document

Each Entry defined by the Submission shall conform to the corresponding Metadata Register Structure Document.

Consistency

Each Entry defined by the Submission should be consistent other Entries within the same Node.

Single Controlling Organization

All Entries defined by the Submission shall belong to the same Controlling Organization.

Deletion

A Submission shall not result in an Entry being deleted.

An Entry that is no longer appropriate is deprecated, i.e. its Deprecated field is set to "true".

Top-Level Class 13 or Class 14 Nodes

Submitter

The Submitter shall be the Director of Engineering.

Version Byte

The Version Byte of each new UL shall be Current Version Byte specified in Section .

SMPTE-Controlled Entries

Submitter

The Submitter shall be a member of the Standards Community.

Version Byte

The Version Byte of each new UL shall be Current Version Byte specified in Section .

Defining Document

A Defining Document shall be associated with each Entry.

The Defining Document shall be either:

  • a SMPTE Engineering Document;
  • a specification listed in AG 03; or
  • a SMPTE Registered Disclosure Document (RDD).

The Defining Document shall define the semantics of each Entry.

If the Defining Document is a SMPTE Engineering Document or a SMPTE Registered Disclosure Document, the Defining Document shall in addition define the associated properties of each Entry.

The Submission shall include a copy of the Defining Document, or the portion thereof sufficient to unambiguously define the semantics of the Entry.

Criteria for Public-Use Entries

Submitter

The Submitter shall be the Controlling Organization of the Entries modified by the Submission.

Defining Document

A Defining Document should be associated with each Entry.

Version Byte

The Version Byte of each new UL added by the Submission is at the discretion of the Submitter.

Examples (informative)

SMPTE Engineering Document as Defining Document

illustrates the Release process for an Entry whose Defining Document is a SMPTE Engineering Document.

Sample Timeline: Entry whose Defining Document is a SMPTE Engineering Document.

SMPTE RDD as Defining Document

illustrates the Release process for an Entry whose Defining Document is a SMPTE RDD.

Sample Timeline: Entry whose Defining Document is a SMPTE RDD.

AG 03 Reference as Defining Document or Class 13/14 Top-Level Node Allocation

illustrates the Release process for an Entry whose Defining Document references a normative reference permitted in AG 03, or in the case of a Class 13/14 Top-Level Node Allocation (see ).

Sample Timeline: Entry whose Defining Document is a AG 03 or is a Class 13/14 Top-Level Node.

Allocation and Transfer of Control of Public-Use Entries and Private-Use Entries (normative)

Allocation

Any entity may request a top-level Class 13 or Class 14 Node from the Director of Engineering.

The request shall be in a form determined by the Director of Engineering and published on the SMPTE Registration Authority website, and may require a processing fee. The processing fee shall be determined from time-to-time by the Director of Engineering in consultation with the Standards Vice President and the Financial Vice President.

Upon receipt of the request and processing fee, the Director of Engineering shall initiate a Submission defining the Node being requested.

When the Submission achieves "draft" status, the entity becomes the Controlling Organization of all Entries within the Node, excluding the Node Entry itself, across all Metadata Register Structure Documents.

If the Submission is Withdrawn, the processing fee shall be returned to the requesting party.

Transfer of Control

The Controlling Organization of a Private-Use or a Public-Use Entry may, at its sole discretion, transfer control of the Entry to SMPTE at perpetuity.

The document stipulating the transfer of control shall be in a form determined by the Director of Engineering.

Private-Use Entries under SMPTE Control (normative)

lists Private-Use Entries whose control has been delegated to SMPTE.

Private-Use Entries Controlled by SMPTE.
Node UL Node Name Notes
None

A Private-Use Entry Controlled by SMPTE undergoes the same Submission process as any other SMPTE-Controlled Entry, and cannot be deleted and reused (see Section ).

Public-Use Entries under SMPTE Control (normative)

lists Public-Use Entries whose control has been delegated to SMPTE.

Public-Use Entries Controlled by SMPTE.
Bytes 9..11 Node Name Notes
0D.01.01 Structural Metadata
0D.01.02 Partition Packs | Operational Patterns
0D.01.03 Essence Containers Delegated by AMWA Association.
0D.01.04 Descriptive Metadata Schemes
0D.01.05 Generic Stream Partition
0D.01.06 Application Metadata Plugin