MXF UL Style Guidelines

5.1 Style Guidelines🔗

Universal Labels are used in MXF documents in several contexts. Each of these has particular requirements in terms of layout and presentation of the label. The list below is expanded in the following sections

• Defining individual ULs
• Referring to ULs
• Summarizing ULs in a document

This document recommends UL styles that minimize errors for implementers copying ULs from MXF documents. The trend toward software processes for implementation and validation make this a priority over the original MXF style of using Word tables and long prose.

In the current Engineering Document template (SMPTE AG-27), using HTML reduces the chance of unwanted line breaks without the text being unnecessarily small.

5.2 Defining individual ULs🔗

Table 1 shows an example of the preferred way for defining ULs in MXF documents. It is a modified version of Table 2 in SMPTE ST 2094-2.

Item Name

[optional in MXF documents] value of the <Name> element in the corresponding register for the UL. The case of the characters, whitespace and spellings shall be identical to the register.

Symbol

[required in MXF documents] value of the <Symbol> element in the corresponding register for the UL. The case of the characters and spellings shall be identical to the register.

Kind

value of the <Kind> element in the corresponding register for the UL

Item UL

value of the <UL> element in the corresponding register for the UL using the correct encoding style for the label

Table title

use of the word Label or Element or Type or Group is encouraged to help novice readers locate the register in which the UL can be found

Extra explanatory free-form text outside the summary table is encouraged to clearly define the semantics of the UL.

The following example shows a UL description from SMPTE ST 381-4 (Table 2, Table 3) followed by the preferred alternative representation (Table 4, Table 5). Note that in the preferred representation, the second table is no longer part of the UL description and only serves to provide the common names of the AAC profiles. In most cases a second table is not required.

5.3 Defining groups and sets🔗

There is more information to be conveyed when defining groups and sets. For this reason, a two-table approach is recommended for readability.

The first table shall be identical in style to Table 1. The purpose of this table is to enumerate the full UL for each property in the group.

The second table shall be indexed by the Item Name from the first table (identical in spelling, case and whitespace). The purpose of the second table is to define the syntax and semantics of properties in the group.

Two worked examples are shown in Table 6/Table 7 and Table 8/Table 9. The examples marked ‘preferred’ are preferred since it is facilitating text search and checking:

Symbol

value of the <Symbol> element to be listed in the corresponding register for the UL. The case of the register submission. If the row entry has no Symbol (e.g. Length) then the value in that row should be in italics. Constraints for symbol

Type

value of the <Name> element to be listed in the Types register when the value of the element’s <Type> property is resolved. The case of the characters, whitespace and spellings shall be identical to those in the Types register submission.

Len

[optional] the length in Bytes of the value field of the KLV representation of the element provided as helper information to the reader. If this optional column is present, then the value shall match the value in the register submission for that data type – it is duplicate information in an MXF document. When defining data types, the length of the new data type shall be provided.

Notes

The notes should be numbered and a superscript index should be added to the Item Name column or the Meaning column to indicate which note applies to which element.

Table title

use of the word Label or Element or Type or Group is encouraged to help novice readers locate the register in which the UL can be found

Extra explanatory free-form text outside the summary table is encouraged to clearly

5.4 Referring to ULs🔗

In an MXF document is it often necessary to refer to existing SMPTE ULs. Many legacy documents are inconsistent in the way that this is done. Specifically, some legacy documents have been inconsistent in the case of characters and whitespace making document searches unreliable.

The Symbol of an element has consistent character case, has no whitespace and is not subject to line-break formatting issue. This makes it easy for implementers to search for in document. Document authors should verify that the publication version of documents have not had the character case or whitespace of symbols altered by non-technical editors.

Visually identifying symbols can be made easier for readers by utilizing the code and/or pre elements as needed, as defined by SMPTE AG-27.

MXF document should use the element Symbol in body text to refer to an element. If clarity is required, the following phrasing may be used:

The element with symbol AACSubDescriptor should ...

5.5 Summarizing ULs in a document🔗

It may be helpful to the implementation community to know which ULs are defined in any given document. An optional informative Annex may be provided that includes informative sections for each of the register submissions made in the document. Each section should clearly indicate which register the XML applies to and should contain the mature submission that was entered into the register, as defined in SMPTE AG-18. An example from SMPTE ST 381-4 is given below.

All XML should be presented in a monospaced font and indented with spaces. Color highlighting to assist readability is optional.

Text indicating that in case of conflict with the body text of the main document, then the body text is considered the definitive reference.

<!-- Metadata tags to support XML file editing -->
<!-- -->
<!-- Please fill these in if you edit this XML file -->
<!-- author=Oliver Morgan and Patrick Waddell -->
<!-- edit_date= 20161201-->
<!-- summary_of_edit= add elements for AAC SubDescriptor-->
<!-- author=Patrick Waddell -->
<!-- edit_date= 20170210-->
<!-- summary_of_edit= minor edits for Registrar-->
<!-- -->
<!-- DO NOT EDIT THIS TAG -->
<!-- master_commit_tag=v000000075 -->
<!-- DO NOT EDIT THIS TAG -->

<ElementsRegister xmlns="http://www.smpte-ra.org/schemas/335/2012">
  <Entries>
    <Entry>
      <Register>Elements</Register>
      <NamespaceName>http://www.smpte-ra.org/reg/335/2012</NamespaceName>
      <Symbol>AACChannelConfiguration</Symbol>ss
      <UL>urn:smpte:ul:060e2b34.0101010e.04020403.01030000</UL>
      <Kind>LEAF</Kind>
      <Name>AAC Channel Configuration</Name>
      <Definition>Low order 4 bits of Channel Configuration. Upper 4 bits are zeros</Definition>
      <DefiningDocument>SMPTE ST 381-4</DefiningDocument>
      <IsDeprecated>false</IsDeprecated>
      <ContextScope>DefinedContext</ContextScope>
      <Type>urn:smpte:ul:060e2b34.01040101.01010100.00000000</Type>
    </Entry>
    <Entry>
      <Register>Elements</Register>
      <NamespaceName>http://www.smpte-ra.org/reg/335/2012</NamespaceName>
      <Symbol>AACSamplingFrequency</Symbol>
      <UL>urn:smpte:ul:060e2b34.0101010e.04020403.01040000</UL>
      <Kind>LEAF</Kind>
      <Name>AAC Sampling Frequency</Name>
      <Definition>Low order 4 bits of Sampling Frequency Index. Upper 4 bits are zeros</Definition>
      <DefiningDocument>SMPTE ST 381-4</DefiningDocument>
      <IsDeprecated>false</IsDeprecated>
      <ContextScope>DefinedContext</ContextScope>
      <Type>urn:smpte:ul:060e2b34.01040101.01010100.00000000</Type>
    </Entry>
  </Entries>
</ElementsRegister>