SMPTE AG 18
Administrative Guideline
Metadata Registers Procedures
Published - 2023-04-09
SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual.
This Standards Administrative Guideline forms an adjunct to the use and interpretation of the SMPTE Standards Operations Manual. In the event of a conflict, the Operations Manual shall prevail.
Copyright © The Society of Motion Picture and Television Engineers.
This section is entirely informative and does not form an integral part of this Administrative Guideline.
This Administrative Guideline covers all classes of Entry(ies) defined across all Metadata Register Structure Documents specified by SMPTE, and specifies:
This Administrative Guideline specifies maintenance and publication processes specific to the SMPTE Metadata Registers.
Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.
All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as "Informative" or individual paragraphs that start with "Note:"
The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.
The keyword "reserved" indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword "forbidden" indicates "reserved" and in addition indicates that the provision will never be defined in the future.
Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; then formal languages; then figures; and then any other language forms.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
For the purposes of this document, the following terms and definitions apply:
NOTE 1 — A more detailed definition is provided in each Metadata Register Structure Document.
Defining Document property of an Entry.
NOTE 2 — A more detailed definition is provided in each Metadata Register Structure Document.
NOTE 3 — The SMPTE Registration Authority website lists Metadata Register Structure Documents, as provided by 5.4.
This Administrative Guideline expands on the SMPTE Standards Operation Manual, Section 5.2.5 as applied to Registers. In case of conflict with the SMPTE Standards Operation Manual and this document, the former prevails.
This Administrative Guideline supersedes all procedural material specified in Metadata Register Structure Documents, in general, and those listed in Table 1, in particular.
| SMPTE ST 335 and SMPTE ST 335 Am1 | 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 |
The Metadata Register Sub Group is the Sub Group (as defined in the SMPTE Standards Operation Manual) responsible for developing Releases, as established by TC 30MR.
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.
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.
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 Annex C
NOTE — The Controlling Organization of a Public-Use Entry can transfer control of the Entry back to SMPTE as specified in Annex C, Annex D lists Entry(ies) 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.
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 Annex D.
NOTE — The Controlling Organization of a Private-Use Entry can transfer control of the Entry back to SMPTE as specified in Annex D. 0 lists Entry(ies) 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 Clause 7.
Each Controlling Organization shall submit for publication all Public-Use Entries it defines.
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 Clause 7.
No SMPTE Engineering Document should be balloted to FCD until all Entry(ies) it defines have reached the "mature" state.
No SMPTE RDD should undergo committee ballot until all Entry(ies) it defines have reached the "mature" state.
No SMPTE Engineering Document or RDD should be published until all Entry(ies) it defines have reached the "accepted" state.
A Release follows the development process for Engineering Documents, as specified in the SMPTE Standards Operation Manual.
The document number of the Release is assigned as provided in SMPTE AG-02.
NOTE — A Release typically includes Metadata Registers for all Metadata Register Structure Documents.
A Release is initiated by creating a Working Draft consisting of all Entry(ies) whose Submission is in the "Accepted" state at the time of initiation.
NOTE — As a result, only Entry(ies) that have undergone the Submission process are published.
A Release should be initiated twice every calendar year.
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.
There is one Project, as defined in the SMPTE Standards Operation 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".
A Release is numbered according to the Document Numbering requirements specified in SMPTE 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.
Upon publication, a Release shall be made publicly available at the SMPTE Registration Authority website.
The amendment of a Release should be reserved for correcting errors before the next Release.
EXAMPLE: Periodic Releases lessens the need for amendments.
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 1, and is intended to prepare stable Entry(ies) for inclusion in a Release.
Annex C provides selected examples of the Submission process.
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.
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 Annex A.
NOTE — 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.
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.
NOTE — An "initial_draft" Submission is susceptible to significant substantive changes.
The Submission shall transition to the "draft" state if:
The Submission shall transition to "withdrawn" if:
The Submission shall be offered to the parent Technology Committee of the Metadata Register Sub Group for review.
NOTE 1 — A "draft" Submission remains susceptible to modifications following TC review.
NOTE 2 — The Technology Committee Chair determines the duration of the review, as needed to achieve the transition criteria of 8.4.2 This duration can be arbitrarily short if, for instance, the Submission was previously reviewed and changes are trivial.
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.
NOTE — Members that wish to provide comments beyond those related to the Acceptance Criteria are encouraged to join the group responsible for the Submission .
The Submission shall transition to "initial_draft" if any substantive modification is made to the Submission.
The Submission shall transition to "withdrawn" if:
The Submission shall transition to the "accepted" state once the Defining Document of all Entry(ies) 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.
NOTE 1 — The "mature" state is provided if the Defining Document might undergo further modifications, but requires a stable Submission to proceed.
NOTE 2 — A "mature" Submission is modified if the Defining Document is modified.
A Submission that does not include Entry(ies) from a Defining Document that is an Engineering Document or a Registered Disclosure Document shall transition to the "accepted" state immediately.
The Submission shall transition to "initial_draft" if any substantive modification is made to the Submission.
The Submission shall transition to "withdrawn" if:
Modifications shall not be made to the Submission.
All ULs defined by the Submission shall become available to other Submissions.
The Submission may transition to "initial_draft" if requested by the Submitter.
Submissions defining Public-Use Entries shall meet the criteria of Clause A.2 and Clause A.5.
Submissions defining top-level Class 13 or Class 14 Nodes shall meet the criteria of Clause A.2 and Clause A.3.
Submissions defining SMPTE-Controlled Entries other than top-level Class 13 or Class 14 Nodes shall meet the criteria of Clause A.2 and Clause A.4.
The Submission shall include contact information for the Submitter.
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 Table A.1
| 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 |
NOTE —
The MISC type is intended to be used if no other types fit, e.g. a Submission that both adds and corrects Entry(ies).
The DESCRIPTION field shall be selected based on the value of the TYPE 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
A Submission shall consist of one or more documents, each containing Entry(ies) 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 (A.2.2).
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.
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).
Each Entry defined by the Submission shall conform to the corresponding Metadata Register Structure Document.
Each Entry defined by the Submission should be consistent other Entry(ies) within the same Node.
All Entry(ies) defined by the Submission shall belong to the same Controlling Organization.
A Submission shall not result in an Entry being deleted.
NOTE — An Entry that is no longer appropriate is deprecated, i.e. its Deprecated field is set to "true".
The Submitter shall be the Director of Engineering.
The Version Byte of each new UL shall be Current Version Byte specified in 5.5.
The Submitter shall be a member of the Standards Community.
The Version Byte of each new UL shall be Current Version Byte specified in Section 5.5.
A Defining Document shall be associated with each Entry.
The Defining Document shall be either:
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.
The Submitter shall be the Controlling Organization of the Entry(ies) modified by the Submission.
A Defining Document should be associated with each Entry.
The Version Byte of each new UL added by the Submission is at the discretion of the Submitter.
Figure B.1 illustrates the Release process for an Entry whose Defining Document is a SMPTE Engineering Document.
Figure B.2 illustrates the Release process for an Entry whose Defining Document is a SMPTE RDD.
Figure B.3 illustrates the Release process for an Entry whose Defining Document references a normative reference permitted in SMPTE AG-03, or in the case of a Class 13/14 Top-Level Node Allocation (see Annex C).
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 Entry(ies) within the Node, excluding the Node Entry itself, across all Metadata Register Structure Document.
If the Submission is Withdrawn, the processing fee shall be returned to the requesting party.
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.
Table D.1 lists Private-Use Entries whose control has been delegated to SMPTE.
| Node UL | Node Name | Notes |
|---|---|---|
| None | ||
NOTE — 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 A.2.8).
Table E.1 lists Public-Use Entries whose control has been delegated to 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 |