Timed Text Markup Language 3 (TTML3)

3.2.1 Generic Processor Conformance

A TTML3 content processor conforms to this specification if the following generic processor criteria are satisfied:

1. The processor provides at least one mechanism for notionally instantiating a reduced xml infoset representation of a conformant document instance.

2. The processor performs profile processing.

   Note:

   The performance of profile processing implies a certain degree of partial validation, short of performing the [validate document] procedure described in the next item below. In particular, the syntactic expression of profile related vocabulary and any essential syntactic or semantic constraint that applies to the usage of this vocabulary are expected to be nominally verified by an implementation prior to making use of this vocabulary. If profile processing is completed without detecting a significant violation of a syntactic or semantic constraint, then more complete validation may be performed by the [validate document] procedure.

3. If a processor is a validating content processor, then it

   1. provides at least one mechanism to implicitly or explicitly associate the reduced xml infoset representation of a candidate document instance with one of the Abstract Document Types defined by 4 Document Types; and

   2. performs the [validate document] procedure.

   Note:

   This specification does not define a strict order between the performance of validation processing and the performance of profile processing described in the previous item above. In particular, these two processing steps may be interleaved (or repeated) such that both are completed prior to performing further (transformation or presentation) processing on a document instance.

   Notwithstanding the above, there is an implied order relationship between validation processing and profile processing; specifically, in order to perform validation processing, it is necessary to resolve the value of the effective validation profile, for which value it is necessary to resolve the value of the effective content profile, or if that value is null, then resolve the value of the effective processor profile, the latter two values of which are obtained during profile processing.

   Note:

   For an example of interleaving validation processing and profile processing, consider the following scenario (in the given order):

   • verify well-formedness of input document source (validation processing);

   • instantiate input document source as potentially valid abstract document instance (general processing);

   • initialize validation state using built-in application semantics (validation processing);

   • initialize profile state using built-in application semantics (profile processing);

   • validate validation related vocabulary (validation processing);

   • update validation state using valid validation related vocabulary (validation processing);

   • validate profile related vocabulary (validation processing);

   • update profile state using valid profile related vocabulary (profile processing);

   • perform abort steps of [abort if unsupported processor profile] procedure (profile processing);

   • validate entire document, re-validating validation and profile vocabulary as required based on new profile state (validation processing);

   • if processing not aborted, continue with transformation or presentation processing (general processing).

4. The processor does not a priori reject or abort the processing of a conformant document instance unless:

   1. the processor does not support some required (mandatory) feature specified or implied by a TTML profile declared to apply to the document instance; or

   2. a validation error occurs when performing the [validate document] procedure.

5. The processor supports all mandatory processing semantics defined by this specification.

   Note:

   The phrase mandatory semantics refers to all explicit use of the conformance key phrases must and must not as well as any declarative statement that can be reasonably inferred from such key phrases.

   Note:

   Support for the mandatory semantics of a feature or extension applies only when the feature or extension is supported by a TTML content processor.

6. If the processor supports some optional processing semantics defined by this specification, then it does so in a manner consistent with the defined semantics.

   Note:

   The phrase optional semantics refers to all explicit use of the conformance key phrases should, should not, may, and may not, as well as any declarative statement that can be reasonably inferred from such key phrases.

3.2.2 Transformation Processor Conformance

A TTML content processor is a conformant TTML3 transformation processor if the following criteria are satisfied:

1. The processor satisfies all requirements specified by 3.2.1 Generic Processor Conformance.

2. The processor supports the TTML3 Transformation profile as specified by G.3 TTML3 Transformation Profile.

3. The processor supports the TTML2 Transformation profile as specified by G.6 TTML2 Transformation Profile.

4. The processor supports the DFXP Transformation profile as specified by G.9 DFXP Transformation Profile.

3.2.3 Presentation Processor Conformance

A TTML content processor is a conformant TTML3 presentation processor if the following criteria are satisfied:

1. The processor satisfies all requirements specified by 3.2.1 Generic Processor Conformance.

2. The processor supports the TTML3 Presentation profile as specified by G.2 TTML3 Presentation Profile.

3. The processor supports the TTML2 Presentation profile as specified by G.5 TTML2 Presentation Profile.

4. The processor supports the DFXP Presentation profile as specified by G.8 DFXP Presentation Profile.

5. The processor performs 11.3.1.3 Intermediate Synchronic Document Construction and 11.3.1.4 Synchronic Flow Processing.

3.4.1 Forward Compatibility

A conforming TTML processor of a prior version of this specification may be able to process a TTML3 content document instance, provided it ignores unknown vocabulary and ignores known vocabulary that appears in a context where it is not permitted in a conforming TTML content document instance; however, such processing may discard or fail to present content, or may present content differently than intended when processed by a conforming TTML3 processor.

3.4.2 Backward Compatibility

TTML3 is designed such that:

• A conforming TTML2 content document instance is a conforming TTML3 content document instance.

• A conforming TTML3 processor processes a conforming TTML2 content document instance such that the output produced by the TTML3 processor is within the variations allowed per TTML2; however, it may emit warnings if it encounters deprecated features.

5.2.1 Introduction

This sub-section is non-normative.

A given profile may be used by a Timed Text Markup Language content author for one of two functions: (1) to declare that a document instance adheres to a collection of constraints on what vocabulary is used and how it is used, or (2) to declare that a processor must satisfy certain conditions on how content is processed. The first of these functions is termed a content profile, while the second is termed a processor profile.

A content profile is used to allow an author to declare, at authoring time, what constraints the author intends to apply to a document instance. Such a declaration permits downstream processors to perform content validation or verification, as well as to guide or limit subsequent transformation or editing of content in order to maintain adherence to an author specified content profile. In addition, a downstream processor may use a content profile declaration to perform an early determination of its ability to process the features implied by the content profile.

Content profiles are declared by using (1) the ttp:contentProfiles attribute on the root tt element, (2) one or more top-level ttp:profile elements of type content, or (3) a combination of these two mechanisms. If not declared, no content profile is implied.

A processor profile is used to allow an author to declare, at authoring time, what processing must be supported when processing a document instance, such that, if a processor is not able to perform the indicated processing, then processing should be aborted. Such a declaration permits downstream processors to avoid processing content that cannot be processed in a manner that meets the requirements of the content author.

Processor profiles are declared by using (1) the ttp:processorProfiles attribute on the root tt element, (2) one or more ttp:profile elements of type processor, or (3) the ttp:profile attribute on the root tt element. If not declared, a processor profile is inferred from a declared content profile or from a default processor profile.

A content author is not limited to using a single profile, but may make reference to multiple profiles of either type, i.e., multiple content profiles and/or multiple processor profiles. When multiple profiles are referenced, their respective specifications are combined to form a single effective content profile that applies to the document and a single effective processor profile that applies to a processor when processing the document. In addition, an author is not limited to making reference to externally defined profiles, but may define one or more profiles inline within a document.

5.2.2 Profile Examples

This sub-section is non-normative.

An example of an author defined additive, derived profile of the TTML Presentation profile is shown below in Example Fragment – TTML Additive Profile.

<tt xml:lang="" xmlns="http://www.w3.org/ns/ttml">
 <head>
   <profile use="ttml3-presentation" xmlns="http://www.w3.org/ns/ttml#parameter">
     <features xml:base="http://www.w3.org/ns/ttml/feature/">
       <feature value="required">#fontStyle-italic</feature>
     </features>
   </profile>
 </head>
 <body/>
</tt>

5.2.3 Profile Designators

A profile is referenced in one of two ways according to whether the profile is defined externally to the referring document or is defined inline within the referring document. When defined externally, a profile is referenced by means of an <absolute-profile-designator> or <relative-profile-designator> expression. When defined internally (inline), a profile is referenced either implicitly or by means of a <fragment-profile-designator> expression.

A profile designator must adhere to the <uri> value syntax. If the profile designator is expressed as a relative URI, then it must be absolutized by using the TT Profile Namespace value as the base URI.

All profile designators which have the TT Profile Namespace as a prefix but are otherwise not listed in Table 5-2 – Profiles are reserved for future standardization, and must not appear in a conformant document instance. Nothwithstanding this constraint, a profile designator is not restricted to the set of designators enumerated in Table 5-2 – Profiles, but may be any URI that feasibly dereferences a TTML profile definition document provided it does not use the TT Profile Namespace as a prefix.

5.2.4 Profile Semantics

5.3.1 Validation Semantics

5.4.1 Core Catalog

The core vocabulary catalog is intended to satisfy the needs of TTML while providing a baseline vocabulary for future profiles. This vocabulary is divided into distinct categories, specified in detail in the following sections:

• 6 Profile

• 7 Parameter

• 8 Content

• 9 Embedded Content

• 10 Styling

• 11 Layout

• 12 Timing

• 13 Animation

• 14 Metadata

The core element vocabulary specified for use with a document instance is enumerated in Table 5-3 – Element Vocabulary.

Element vocabulary groups that are used in defining content models for TTML element types are enumerated in Table 5-4 – Element Vocabulary Groups.

The attribute vocabulary specified for use with the core vocabulary catalog is enumerated in Table 5-5 – Attribute Vocabulary.

5.4.2 Extension Catalog

The extension vocabulary catalog is intended for use by future profiles of TTML, and is not further defined by this version of TTML.

In addition to standardized extension vocabulary, a conforming document instance may contain arbitrary namespace qualified elements that reside in any namespace other than those namespaces defined for use with this specification. Furthermore, a conforming document instance may contain arbitrary namespace qualified attributes on TTML defined vocabulary where such attributes reside in any namespace other than those defined for use with this specification.

6.1.1 ttp:profile

The ttp:profile element is used to specify a content profile or a processor profile. A processor profile specifies a collection of required (mandatory) and optional (voluntary) features and extensions that must or may be supported by a content processor in order to process a document instance that makes (or may make) use of such features and extensions. A content profile specifies a collection of prohibited, required, and optional features and extensions that, respectively, must not, must, and may be present in a document instance that declares its adherence to the profile.

This specification defines two distinct contexts of use for the ttp:profile element:

• as a child of the head element or a ttp:profile element within a TTML document instance;

• as the root element of a TTML profile definition document instance;

When a ttp:profile element appears within a TTML document instance, its purpose is to express authorial intentions about (1) which features and extensions must or may be supported by a recipient content processor in order to process that document or (2) which features and extensions must not, must, or may be included or otherwise used in that document instance.

When a ttp:profile element is used by a TTML profile definition document instance, it serves to publish a machine readable specification of a specific TTML profile that may be referenced by TTML document instances. This specification defines a number of standard Profile Definition Documents in G Standard Profiles.

The ttp:profile element accepts as its children zero or more elements in the Metadata.class element group, followed by either (1) zero or more ttp:features elements followed by zero or more ttp:extensions elements or (2) zero or more ttp:profile elements. When a ttp:profile element contains a child ttp:profile element, then the child is referred to as a nested profile and the parent is referred to as a nesting profile; otherwise it is referred to as a non-nesting profile.

<ttp:profile
  combine = ("leastRestrictive" | "mostRestrictive" | "replace") : replace
  designator = xsd:string
  type = ("processor" | "content") : processor
  use = xsd:string
  xml:base = <uri>
  xml:id = ID
  Content: Metadata.class*, ((ttp:features*, ttp:extensions*)|ttp:profile*)
</ttp:profile>

The type attribute is used to determine whether a profile is a content profile or a processor profile. If not specified, the profile is considered to be a processor profile. If a ttp:profile element references a baseline profile or a nested profile, then the type of the referenced profile must be the same as the type of the referencing profile. For example, a ttp:profile element that defines a processor profile may only make reference to other processor profiles, and may not reference a content profile.

The combine attribute is used to specify how feature or extension specifications are combined in the case that multiple specifications apply to the same feature or extension, respectively.

If the value of the combine attribute is replace, then a lexically subsequent feature or extension specification replaces a lexically prior specification, where specification elements are ordered as follows:

1. specifications defined by a baseline profile referenced by a use attribute;

2. specifications defined by descendant ttp:profile elements in post-order traversal order;

3. specifications defined as descendant ttp:feature or ttp:extension elements in post-order traversal order.

If the value is leastRestrictive, then the least restrictive specification value applies; if the value is mostRestrictive, then the most restrictive specification value applies. The order of restrictiveness is as follows (from least to most): optional, required, prohibited.

If the combine attribute is not specified, then replacement semantics apply.

If specified, the designator attribute must adhere to the <absolute-profile-designator> value syntax. A designator attribute may be specified on a ttp:profile element that appears in a TTML document instance, and, if not specified, the defined profile is considered to be an undesignated profile. A designator attribute should be specified on a ttp:profile element that appears in a TTML profile definition document instance, and, if not specified, the defining context (e.g., an external specification) must specify a designator in its accompanying definition text.

If specified, the use attribute must adhere to the <uri> value syntax, and, furthermore, must denote a profile designator in accordance with 5.2 Profiling. In this case, the profile designator must refer to (1) a standard, predefined profile definition document as defined by 6 Profile, or (2) a feasibly dereferenceable resource representing a valid Profile Definition Document instance. In either case, the referenced profile serves as the baseline profile of the specifying ttp:profile element.

If the use attribute is not specified, then the baseline profile of the ttp:profile element must be considered to be the empty (null) profile, i.e., an undesignated profile definition containing no feature or extension specifications.

The combined profile specification set CPSS of features and extensions of a profile P is determined according to the following ordered rules, where merging a specification S into CPSS entails applying a combination method in accordance with the specified (or default) value of the combine attribute, and where merging a combined specification set CPSS'  into CPSS entails merging each ordered specification of CPSS'  into CPSS:

1. initialize CPSS to the empty set;

2. if a use attribute is present, then merge the combined specification set of the referenced baseline profile into CPSS;

3. for each ttp:profile child of the P, using a post-order traversal, merge the combined specification set of the child profile into CPSS;

4. for each ttp:feature and ttp:extension child of the ttp:profile element, using a post-order traversal, merge the feature or extension specification into CPSS.

A conformant TTML processor is not required to be able to dereference a profile definition document that is not one of the standard, predefined profiles defined by G Standard Profiles. Furthermore, a conformant TTML processor may make use of a built-in, static form of each standard, predefined profile so as not to require dereferencing a network resource.

If a TTML processor is unable to dereference a non-standard profile definition document, then it must not further process the document without the presence of an explicit override from an end-user or some implementation specific parameter traceable to an end-user or to a user or system configuration setting. If a TTML processor aborts processing of a document instance due to the inability to reference a non-standard profile definition document, then some end-user notification should be given unless the end-user or system has disabled such a notification, or if the processor does not permit or entail the intervention of an end-user.

A conformant TTML processor is not required to be able to support a combined profile or a nesting profile. If (1) combined profiles are not supported and the processing of a profile would cause it to be considered a combined profile, or (2) nesting profiles are not supported and the processing of a profile would cause it to be considered a nesting profile, then further processing of the profile must not occur without the presence of an explicit override from an end-user or some implementation specific parameter traceable to an end-user or to a user or system configuration setting. If a TTML processor aborts processing of a document instance due to lack of support for combined profiles or nesting profiles, then some end-user notification should be given unless the end-user or system has disabled such a notification, or if the processor does not permit or entail the intervention of an end-user.

The ttp:profile element is illustrated by the following example.

<ttp:profile use="ttml3-presentation">
  <ttp:features xml:base="http://www.w3.org/ns/ttml/feature/">
    <ttp:feature>#text-outline</ttp:feature>
  </ttp:features>
</ttp:profile>

6.1.2 ttp:features

The ttp:features element is a container element used to group information about feature support and usage requirements.

The ttp:features element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more ttp:feature elements.

<ttp:features
  xml:base = <uri> : TT Feature Namespace
  xml:id = ID
  Content: Metadata.class*, ttp:feature*
</ttp:features>

If specified, the xml:base attribute must (1) adhere to the <uri> value syntax, (2) express an absolute URI that adheres to [XML Base] and, (3) express a feature namespace as defined by E.1 Feature Designations. If not specified, the xml:base attribute's default value applies, which is the TT Feature Namespace.

The xml:base attribute is used to permit the abbreviation of feature designation URIs expressed by child ttp:feature elements.

6.1.3 ttp:feature

The ttp:feature element is used to specify information about support and usage requirements for a particular feature.

<ttp:feature
  extends = xsd:string
  restricts = xsd:string
  value = ("optional" | "required" | "use" | "prohibited") : see prose below
  xml:id = ID
  Content: #PCDATA
</ttp:feature>

The children of the ttp:feature element must express a non-empty sequence of character information items the concatenation of which adheres to the <uri> value syntax.

If specified, the extends attribute and/or the restricts attribute must (1) adhere to the <uri> value syntax, and (2) express a feature designation as defined by E.1 Feature Designations.

The extends attribute may be used to indicate that the feature being defined is, from either (or both) a syntactic or (and) semantic perspective, a proper superset of the feature referenced by the extends attribute. The restricts attribute may be used to indicate that the feature being defined is, from either (or both) a syntactic or (and) semantic perspective, a proper subset of the feature referenced by the restricts attribute. If an extends attribute is specified, then a restricts attribute must not be specified on a ttp:feature element; likewise, if a restricts attribute is specified, then an extends attribute must not be specified.

If the URI expressed by (1) the content of the ttp:feature element, (2) the extends attribute, or (3) the restricts attribute is a relative URI, then, when combined with the feature namespace value expressed by the xml:base attribute of the nearest ancestor ttp:features element, it must express an absolute URI. In either case (original absolute URI or resulting absolutized URI), the URI expressed by the ttp:feature element must further adhere to the syntax of a feature designation as defined by E.1 Feature Designations, and, furthermore, the specific designation that appears in this URI, i.e., the portion of the feature designation that starts with the fragment identifier separator '#', must be defined by this specification or some published version thereof (that has achieved REC status).

If the URI expressed by the content of the ttp:feature element, by the extends attribute, or by the restricts attribute is a relative URI, then an xml:base attribute should be specified on the nearest ancestor ttp:features element.

The value attribute specifies constraints on support for or use of the designated feature according to the profile type.

If the profile is a processor profile then the following semantics apply:

• if the value of the value attribute is optional, then a processor may but need not implement or otherwise support the feature in order to process the document;

• if the value is required, then perform the following steps:

  1. if the feature is implemented or otherwise supported by a processor, then continue processing the document;

  2. otherwise, if (1) the extends attribute is specified on this ttp:feature element, (2) the value of the extends attribute designates a feature that is implemented or otherwise supported by a processor, and (3) the computed value of the ttp:permitFeatureNarrowing property of the root tt element is not false, then continue processing the document;

  3. otherwise, if (1) the restricts attribute is specified on this ttp:feature element, (2) the value of the restricts attribute designates a feature that is implemented or otherwise supported by a processor, and (3) the computed value of the ttp:permitFeatureWidening property of the root tt element is not false, then continue processing the document;

  4. otherwise, abort processing the document unless overridden by the end-user or some implementation specific parameter traceable to an end-user or to a user or system configuration setting.

• if the value attribute is not specified, then the feature specification must be interpreted as if the value required were specified;

If the profile is a content profile then the following semantics apply:

• if the value of the value attribute is optional, then the feature may but need not appear in a document that claims conformance with that profile;

• if the value of the value attribute is required, then the feature must appear in a document that claims conformance with that profile;

• if the value of the value attribute is prohibited, then the feature must not appear in a document that claims conformance with that profile;

• if the value attribute is not specified, then the feature specification must be interpreted as if the value optional were specified;

The value use of the value attribute is deprecated. If it appears in a profile specification, then it must be interpreted as if required had been specified.

If some defined (i.e., standardized) or otherwise well known feature is not specified by a ttp:feature element in a content profile, then it must be interpreted as if the feature were specified with the value attribute equal to optional. However, if not specified in a processor profile, no claim about support or absence of support for the feature is implied.

If a document instance makes use of a feature defined by E.1 Feature Designations and if the intended use of the document requires the recognition and processing of that feature, then the document must include a required feature specification in one of its declared or referenced profiles.

The ttp:feature element is illustrated by the following example.

<ttp:profile use="http://www.w3.org/ns/ttml/profile/ttml3-presentation">
  <ttp:features xml:base="http://www.w3.org/ns/ttml/feature/">
    <ttp:feature value="required">#fontStyle-italic</ttp:feature>
    <ttp:feature value="required">#textDecoration-under</ttp:feature>
    <ttp:feature value="prohibited">#textOutline-blurred</ttp:feature>
  </ttp:features>
</ttp:profile>

6.1.4 ttp:extensions

The ttp:extensions element is a container element used to group information about extension support and usage requirements.

The ttp:extensions element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more ttp:extension elements.

<ttp:extensions
  xml:base = <uri> : TT Extension Namespace
  xml:id = ID
  Content: Metadata.class*, ttp:extension*
</ttp:extensions>

If specified, the xml:base attribute must (1) adhere to the <uri> value syntax, (2) express an absolute URI that adheres to [XML Base] and, (3) express an extension namespace as defined by F.1 Extension Designations. If not specified, the xml:base attribute's default value applies, which is the TT Extension Namespace.

The xml:base attribute is used to permit the abbreviation of feature designation URIs expressed by child ttp:extension elements.

6.1.5 ttp:extension

The ttp:extension element is used to specify information about support and usage requirements for a particular extension.

<ttp:extension
  extends = xsd:string
  restricts = xsd:string
  value = ("optional" | "required" | "use" | "prohibited") : see prose below
  xml:id = ID
  Content: #PCDATA
</ttp:extension>

The children of the ttp:extension element must express a non-empty sequence of character information items the concatenation of which adheres to the <uri> value syntax.

If specified, the extends attribute and/or the restricts attribute must (1) adhere to the <uri> value syntax, and (2) express a feature designation or extension designation as defined by E.1 Feature Designations or F.1 Extension Designations, respectively.

The extends attribute may be used to indicate that the extension being defined is, from either (or both) a syntactic or (and) semantic perspective, a proper superset of the feature or extension referenced by the extends attribute. The restricts attribute may be used to indicate that the extension being defined is, from either (or both) a syntactic or (and) semantic perspective, a proper subset of the feature or extension referenced by the restricts attribute. If an extends attribute is specified, then a restricts attribute must not be specified on a ttp:extension element; likewise, if a restricts attribute is specified, then an extends attribute must not be specified.

If the URI expressed by (1) the content of the ttp:extension element, (2) the extends attribute, or (3) the restricts attribute is a relative URI, then, when combined with the extension namespace value expressed by the xml:base attribute of the nearest ancestor ttp:extensions element, it must express an absolute URI. In either case (original absolute URI or resulting absolutized URI), the URI expressed by the ttp:extension element must further adhere to the syntax of an extension designation as defined by F.1 Extension Designations, while the URI expressed by the extends attribute and/or the restricts attribute must adhere to the syntax of a feature designation or an extension designation as defined by E.1 Feature Designations or F.1 Extension Designations, respectively.

If the URI expressed by the content of the ttp:extension element, by the extends attribute, or by the restricts attribute is a relative URI, then an xml:base attribute should be specified on the nearest ancestor ttp:extensions element.

The value attribute specifies constraints on support for or use of the designated extension according to the profile type.

If the profile is a processor profile then the following semantics apply:

• if the value of the value attribute is optional, then a processor may but need not implement or otherwise support the extension in order to process the document;

• if the value is required, then perform the following steps:

  1. if the extension is implemented or otherwise supported by a processor, then continue processing the document;

  2. otherwise, if (1) the extends attribute is specified on this ttp:extension element, (2) the value of the extends attribute designates an extension that is implemented or otherwise supported by a processor, and (3) the computed value of the ttp:permitFeatureNarrowing property of the root tt element is not false, then continue processing the document;

  3. otherwise, if (1) the restricts attribute is specified on this ttp:extension element, (2) the value of the restricts attribute designates an extension that is implemented or otherwise supported by a processor, and (3) the computed value of the ttp:permitFeatureWidening property of the root tt element is not false, then continue processing the document;

  4. otherwise, abort processing the document unless overridden by the end-user or some implementation specific parameter traceable to an end-user or to a user or system configuration setting.

• if the value attribute is not specified, then the extension specification must be interpreted as if the value required were specified;

If the profile is a content profile then the following semantics apply:

• if the value of the value attribute is optional, then the extension may but need not appear in a document that claims conformance with that profile;

• if the value of the value attribute is required, then the extension must appear in a document that claims conformance with that profile;

• if the value of the value attribute is prohibited, then the extension must not appear in a document that claims conformance with that profile;

• if the value attribute is not specified, then the extension specification must be interpreted as if the value optional were specified;

The value use of the value attribute is deprecated. If it appears in a profile specification, then it must be interpreted as if required had been specified.

If some well known extension is not specified by a ttp:extension element in a content profile, then it must be interpreted as if the extension were specified with the value attribute equal to optional. However, if not specified in a processor profile, no claim about support or absence of support for the extension is implied.

If a document instance makes use of an extension designatable by F.1 Extension Designations and if the intended use of the document requires the recognition and processing of that extension, then the document must include a required extension specification in one of its declared or referenced profiles.

The ttp:extension element is illustrated by the following example.

<ttp:profile use="http://www.w3.org/ns/ttml/profile/ttml3-transformation">
  <ttp:extensions xml:base="http://example.org/ttml/extension/">
    <ttp:extension value="use">#prefilter-by-language</ttp:extension>
  </ttp:extensions>
</ttp:profile>

6.2.1 ttp:contentProfiles

The ttp:contentProfiles attribute may be used by a content author to express one or more content profiles of the Timed Text Markup Language (TTML) where the enclosing document instance claims conformance to all of a set of specified content profiles.

If specified, the value of this attribute must adhere to the following syntax, where each profile-designator item adheres to the <uri> value syntax, and, further, adheres to constraints defined on a profile designator in accordance with 5.2 Profiling.

ttp:contentProfiles
  : designators
  | "all(" <lwsp> designators <lwsp> ")"

designators
  : designator (<lwsp> designator)*

designator
  : <profile-designator>

If the list of designators is enclosed in the function syntax all(...) or no function syntax is used, then conformance is claimed with all designated content profiles.

If multiple designators are specified, then the absolutized form of each designator must be distinct; that is, after converting to absolutized form, duplicate designators are not permitted.

A ttp:contentProfiles attribute is considered to be significant only when specified on the tt element.

6.2.2 ttp:contentProfileCombination

The ttp:contentProfileCombination attribute is used to specify the method for combining multiple content profiles.

If specified, the value of this attribute must adhere to the following syntax:

ttp:contentProfileCombination
  : "leastRestrictive"
  | "mostRestrictive"
  | "replace"
  | "ignore"

If not specified, the value of this parameter must be considered to be ignore.

Given two ordered profile specification values, arg1 and arg2, and a content profile combination method, Table 6-1 – Content Profile Combination specifies the result of combining the two specification values, where the order of arguments is determined in accordance with the lexical order of content profiles in a document instance.

A ttp:contentProfileCombination attribute is considered to be significant only when specified on the tt element.

6.2.3 ttp:inferProcessorProfileMethod

The ttp:inferProcessorProfileMethod attribute is used to specify the method for mapping a content profile specification value to a corresponding processor profile specification value.

If specified, the value of this attribute must adhere to the following syntax:

ttp:inferProcessorProfileMethod
  : "loose"
  | "strict"

If this parameter's value is loose, then, when inferring a processor profile specification from a content profile specification, a loose (liberal) mapping applies.

If this parameter's value is strict, then, when inferring a processor profile specification from a content profile specification, a strict (conservative) mapping applies.

If not specified, the value of this parameter must be considered to be loose.

Given an input content profile specification value, input, and an infer processor profile method, Table 6-2 – Infer Processor Profile Method specifies the result of mapping the input specification value.

A ttp:inferProcessorProfileMethod attribute is considered to be significant only when specified on the tt element.

6.2.4 ttp:inferProcessorProfileSource

The ttp:inferProcessorProfileSource attribute is used to specify the source for mapping a content profile specification value to a corresponding processor profile specification value.

If specified, the value of this attribute must adhere to the following syntax:

ttp:inferProcessorProfileSource
  : "combined"
  | "first"

If this parameter's value is combined, then, when inferring a processor profile, the combined profile specification set of the effective content profile is used as the source of inference.

If this parameter's value is first, then, when inferring a processor profile, the first constituent profile of the combined profile specification set of the effective content profile, where the processor profile inferred from that constituent profile is supported by the content processor, is used as the source of inference, about which see the construct inferred processor profile procedure for further details.

If not specified, the value of this parameter must be considered to be first.

A ttp:inferProcessorProfileSource attribute is considered to be significant only when specified on the tt element.

6.2.5 ttp:permitFeatureNarrowing

The ttp:permitFeatureNarrowing attribute is used to specify whether requirements related to a feature or extension may be satisfied by a (syntactically or semantically) narrower interpretation of the feature or extension.

If specified, the value of this attribute must adhere to the following syntax:

ttp:permitFeatureNarrowing
  : xsd:boolean                             // see [XML Schema Part 2], §3.2.2

If this parameter's value is true, then, a requirement for support of a feature or extension may be satisfied if the definition of the feature or extension specifies an extends attribute, and the feature or extension referenced by that attribute is supported by a processor.

If this parameter's value is false, then, a requirement for support of a feature or extension can not be satisfied by a more narrowly defined feature or extension specified by an extends attribute.

If not specified, the value of this parameter must be considered to be false.

A ttp:permitFeatureNarrowing attribute is considered to be significant only when specified on the tt element.

6.2.6 ttp:permitFeatureWidening

The ttp:permitFeatureWidening attribute is used to specify whether requirements related to a feature or extension may be satisfied by a (syntactically or semantically) wider interpretation of the feature or extension.

If specified, the value of this attribute must adhere to the following syntax:

ttp:permitFeatureWidening
  : xsd:boolean                             // see [XML Schema Part 2], §3.2.2

If this parameter's value is true, then, a requirement for support of a feature or extension may be satisfied if the definition of the feature or extension specifies a restricts attribute, and the feature or extension referenced by that attribute is supported by a processor.

If this parameter's value is false, then, a requirement for support of a feature or extension can not be satisfied by a more widely defined feature or extension specified by a restricts attribute.

If not specified, the value of this parameter must be considered to be false.

A ttp:permitFeatureWidening attribute is considered to be significant only when specified on the tt element.

6.2.7 ttp:profile

The ttp:profile attribute denotes a processor profile of the Timed Text Markup Language (TTML) that applies when processing a document instance.

If specified, the value of this attribute must adhere to the following syntax where the designator adheres to the <uri> value syntax, and, further, must specify a profile designator in accordance with 5.2 Profiling.

ttp:profile
  : designator

designator
  : <profile-designator>

A ttp:profile attribute is considered to be significant only when specified on the tt element.

If a top-level processor profile is defined in a document instance, then the ttp:profile attribute should not be specified on the tt element.

6.2.8 ttp:processorProfiles

The ttp:processorProfiles attribute may be used by a content author to express one or more processor profiles of the Timed Text Markup Language (TTML) where the enclosing document instance requires support for (1) all of a set of specified processor profiles or (2) any one of a set of specified processor profiles.

If specified, the value of this attribute must adhere to the following syntax, where each profile-designator item adheres to the <uri> value syntax, and, further, adheres to constraints defined on a profile designator in accordance with 5.2 Profiling.

ttp:processorProfiles
  : designators
  | "all(" <lwsp> designators <lwsp> ")"
  | "any(" <lwsp> designators <lwsp> ")"

designators
  : designator (<lwsp> designator)*

designator
  : <profile-designator>

If the list of designators is enclosed in the function syntax all(...) or no function syntax is used, then support is required for all designated processor profiles. If the list of designators is enclosed in the function syntax any(...), then support is required for at least one of the designated processor profiles.

If multiple designators are specified, then the absolutized form of each designator must be distinct; that is, after converting to absolutized form, duplicate designators are not permitted.

A ttp:processorProfiles attribute is considered to be significant only when specified on the tt element.

6.2.9 ttp:processorProfileCombination

The ttp:processorProfileCombination attribute is used to specify the method for combining multiple processor profiles.

If specified, the value of this attribute must adhere to the following syntax:

ttp:processorProfileCombination
  : "leastRestrictive"
  | "mostRestrictive"
  | "replace"
  | "ignore"

If not specified, the value of this parameter must be considered to be ignore.

Given two ordered profile specification values, arg1 and arg2, and a processor profile combination method, Table 6-3 – Processor Profile Combination specifies the result of combining the two specification values, where the order of arguments is determined in accordance with the lexical order of processor profiles in a document instance.

A ttp:processorProfileCombination attribute is considered to be significant only when specified on the tt element.

6.2.10 ttp:validation

The ttp:validation attribute is used to specify whether validation processing may or must be performed on a document instance by a validating content processor.

If specified, the value of this attribute must adhere to the following syntax:

ttp:validation
  : "required"
  | "optional"
  | "prohibited"

If this parameter's value is required, then, a validating content processor must perform validation processing on a TTML document instance prior to performing other types of processing, e.g., presentation or transformation processing.

If this parameter's value is optional, then, a validating content processor may, but need not, perform validation processing on a TTML document instance prior to performing other types of processing, e.g., presentation or transformation processing.

If this parameter's value is prohibited, then, a validating content processor must not perform validation processing on a TTML document instance prior to performing other types of processing, e.g., presentation or transformation processing, unless the end-user or application overrides this prohibition.

If validation processing is performed on a TTML document instance and validation fails, then the computed value of the ttp:validationAction property is used to determine what action to take before performing further processing.

If not specified, the value of this parameter must be considered to be optional.

A ttp:validation attribute is considered to be significant only when specified on the tt element.

6.2.11 ttp:validationAction

The ttp:validationAction attribute is used to specify what action is to be taken by a validating content processor when validation of a document instance fails.

If specified, the value of this attribute must adhere to the following syntax:

ttp:validationAction
  : "abort"
  | "warn"
  | "ignore"

If this parameter's value is abort, then, unless abort processing is overridden by the end-user or application, a validating content processor must abort processing of a TTML document instance when a validation error exception occurs.

If this parameter's value is warn, then, a validating content processor should warn the end-user when a validation error or validation warning exception occurs and give the end-user the option to continue or abort processing.

If this parameter's value is ignore, then, a validating content processor should not abort and should not warn the end-user when a validation exception occurs.

If not specified, the value of this parameter is determined as follows: if the computed value of the ttp:validation property is required, then the value must be considered to be abort; if it is optional, then the value must be considered to be warn; otherwise, if it is prohibited, then the value must be considered to be ignore.

A ttp:validationAction attribute is considered to be significant only when specified on the tt element.

7.2.1 ttp:cellResolution

The ttp:cellResolution attribute may be used by an author to express the number of horizontal and vertical cells into which the root container region area is divided for the purpose of expressing presentation semantics in terms of a uniform grid.

If specified, the value of this attribute must adhere to the following syntax:

ttp:cellResolution
  : columns <lwsp> rows                     // columns != 0; rows != 0

columns | rows
  : <digit>+

If not specified, the number of columns and rows must be considered to be 32 and 15, respectively. If specified, then columns or rows must not be zero (0).

A ttp:cellResolution attribute is considered to be significant only when specified on the tt element.

Except where indicated otherwise, when a <length> expressed in cells denotes a dimension parallel to the inline or block progression dimension, the cell's dimension in the inline or block progression dimension applies, respectively.

7.2.2 ttp:clockMode

The ttp:clockMode attribute is used to specify the interpretation of time expressions as real-time time coordinates when operating with time base of clock as defined by 7.2.11 ttp:timeBase.

If specified, the value of this attribute must adhere to the following syntax:

ttp:clockMode
  : "local"
  | "gps"
  | "utc"

If the time base, defined by 7.2.11 ttp:timeBase, is designated as clock, then this parameter applies as follows: if the parameter's value is local, then time expressions are interpreted as local wall-clock time (and date) coordinates; if utc, then time expressions are interpreted as UTC time coordinates [UTC]; if gps, then time expressions are interpreted as GPS time coordinates [GPS].

If not specified, the value of this parameter must be considered to be utc.

A ttp:clockMode attribute is considered to be significant only when specified on the tt element.

7.2.3 ttp:displayAspectRatio

The ttp:displayAspectRatio attribute is used to specify the display aspect ratio of the root container region as elaborated in H Root Container Region Semantics.

If specified, the value of this attribute must adhere to the following syntax:

ttp:displayAspectRatio
  : numerator <lwsp> denominator            // numerator != 0; denominator != 0

numerator | denominator
  : <digit>+

If specified, then both numerator and denominator must be non-zero. If not specified, then the display aspect ratio of the root container region is determined by H Root Container Region Semantics.

A ttp:displayAspectRatio attribute is considered to be significant only when specified on the tt element.

7.2.4 ttp:dropMode

The ttp:dropMode attribute is used to specify constraints on the interpretation and use of frame counts that correspond with [SMPTE ST 12-1] time coordinates when operating with time base of smpte as defined by 7.2.11 ttp:timeBase.

If specified, the value of this attribute must adhere to the following syntax:

ttp:dropMode
  : "dropNTSC"
  | "dropPAL"
  | "nonDrop"

If the time base, defined by 7.2.11 ttp:timeBase, is designated as smpte, then this parameter applies as follows: if the parameter's value is nonDrop, then, within any given second of a time expression, frames count from 0 to N−1, where N is the value specified by the ttp:frameRate parameter, but while ignoring any value specified by the ttp:frameRateMultiplier parameter.

If this parameter's value is dropNTSC, then, within any given second of a time expression except the second 00, frames count from 0 to N−1, where N is the value specified by the ttp:frameRate parameter, but while ignoring any value specified by the ttp:frameRateMultiplier parameter. If the second of a time expression is 00 and the minute of the time expression is not 00, 10, 20, 30, 40, or 50, then frame codes 00 and 01 are dropped during that second; otherwise, these frame codes are not dropped.

If this parameter's value is dropPAL, then, within any given second of a time expression except the second 00, frames count from 0 to N−1, where N is the value specified by the ttp:frameRate parameter, but while ignoring any value specified by the ttp:frameRateMultiplier parameter. If the second of a time expression is 00 and the minute of the time expression is even but not 00, 20, or 40, then frame codes 00 through 03 are dropped during that second; otherwise, these frame codes are not dropped.

If not specified, then nonDrop must be assumed to apply.

A ttp:dropMode attribute is considered to be significant only when specified on the tt element.

7.2.5 ttp:frameRate

The ttp:frameRate attribute is used to specify the frame rate of a related media object or the intrinsic frame rate of a document instance in case it is intended to function as an independent media object.

If specified, the value of this attribute must adhere to the following syntax:

ttp:frameRate
  : <digit>+                                // value > 0

The frame rate that applies to a document instance is used to interpret time expressions that are expressed in frames as defined by 12.3.1 <time-expression>.

If the media time base applies and the effective frame rate is integral, then a frame is interpreted as a division of a second of media time, such that if the frame rate is specified as F, then a second of media time is divided into F intervals of equal duration, where each interval is labeled as frame f, with f ∈ [0…F−1].

If not specified, the frame rate must be considered to be equal to some application defined frame rate, or if no application defined frame rate applies, then thirty (30) frames per second. If specified, then the frame rate must be greater than zero (0).

A ttp:frameRate attribute is considered to be significant only when specified on the tt element.

7.2.6 ttp:frameRateMultiplier

The ttp:frameRateMultiplier attribute is used to specify a multiplier to be applied to the frame rate specified by a ttp:frameRate attribute in order to compute the effective frame rate.

If specified, the value of this attribute must adhere to the following syntax:

ttp:frameRateMultiplier
  : numerator <lwsp> denominator            // numerator != 0; denominator != 0

numerator | denominator
  : <digit>+

A frame rate multiplier is used when the desired frame rate cannot be expressed as an integral number of frames per second.

If not specified, the frame rate multiplier must be considered to be equal to some application defined frame rate multiplier, or if no application defined frame rate multiplier applies, then one (1:1). Both numerator and denominator must be non-zero.

A ttp:frameRateMultiplier attribute is considered to be significant only when specified on the tt element.

7.2.7 ttp:markerMode

The ttp:markerMode attribute is used to specify constraints on the interpretation and use of time expressions that correspond with [SMPTE ST 12-1] time coordinates when operating with time base of smpte as defined by 7.2.11 ttp:timeBase.

If specified, the value of this attribute must adhere to the following syntax:

ttp:markerMode
  : "continuous"
  | "discontinuous"

If the time base, defined by 7.2.11 ttp:timeBase, is designated as smpte, then this parameter applies as follows: if the parameter's value is continuous, then [SMPTE ST 12-1] time coordinates may be assumed to be linear and either monotonically increasing or decreasing; however, if discontinuous, then any assumption must not be made regarding linearity or monotonicity of time coordinates.

If not specified, the value of this parameter must be considered to be discontinuous.

A ttp:markerMode attribute is considered to be significant only when specified on the tt element.

If a value of continuous applies, then time expressions may be converted to real time coordinates by taking into account the computed frame rate and drop mode as expressed by the ttp:dropMode parameter. In this case, the content processor must create and maintain a synthetic smpte document syncbase within which these time expressions are interpreted as further described in 12.4 Timing Semantics.

If a value of discontinuous applies, then time expressions must not be converted to real time coordinates, arithmetical operators (addition, multiplication) are not defined on time expressions, and, consequently, any (well-formed) expression of a duration must be considered to be invalid.

7.2.8 ttp:pixelAspectRatio

The ttp:pixelAspectRatio attribute is used to specify the pixel aspect ratio of the root container region as elaborated in H Root Container Region Semantics

If specified, the value of this attribute must adhere to the following syntax:

ttp:pixelAspectRatio
  : numerator <lwsp> denominator            // numerator != 0; denominator != 0

numerator | denominator
  : <digit>+

If specified, then both numerator and denominator must be non-zero. If not specified, then the pixel aspect ratio of the root container region is determined by H Root Container Region Semantics.

A ttp:pixelAspectRatio attribute is considered to be significant only when specified on the tt element.

The ttp:pixelAspectRatio attribute should not be specified unless a tts:extent attribute consisting of two <length> specifications using px (pixel) units is also specified on the tt element, without which the use of a ttp:pixelAspectRatio attribute is deprecated.

7.2.9 ttp:subFrameRate

The ttp:subFrameRate attribute is used to specify the sub-frame rate of a related media object or the intrinsic sub-frame rate of a document instance in case it is intended to function as an independent media object.

If specified, the value of this attribute must adhere to the following syntax:

ttp:subFrameRate
  : <digit>+                                // value > 0

The sub-frame rate that applies to a document instance is used to interpret time expressions that are expressed in sub-frames as defined by 12.3.1 <time-expression>.

If the media time base applies and the effective frame rate is integral, a sub-frame is interpreted as a division of a frame of media time, such that if the sub-frame rate is specified as S, then a frame of media time is divided into S intervals of equal duration, where each interval is labeled as sub-frame s, with s ∈ [0…S−1].

If not specified, the sub-frame rate must be considered to be equal to some application defined sub-frame rate, or if no application defined sub-frame rate applies, then one (1). If specified, then the sub-frame rate must be greater than zero (0).

A ttp:subFrameRate attribute is considered to be significant only when specified on the tt element.

7.2.10 ttp:tickRate

The ttp:tickRate attribute is used to specify the tick rate of a related media object or the intrinsic tick rate of content of a document instance in case it is intended to function as an independent media object.

If specified, the value of this attribute must adhere to the following syntax:

ttp:tickRate
  : <digit>+                                // value > 0

The tick rate that applies to a document instance is used to interpret time expressions that are expressed in ticks by using the t metric as defined by 12.3.1 <time-expression>.

If the media time base applies, a tick is interpreted as an integral division of a second of media time, such that if the tick rate is specified as T, then a second of media time is divided into T intervals of equal duration, where each interval is labeled as tick t, with t ∈ [0…T−1].

If not specified, then if a frame rate is specified, the tick rate must be considered to be the effective frame rate multiplied by the sub-frame rate (i.e., ticks are interpreted as sub-frames); or, if no frame rate is specified, the tick rate must be considered to be one (1) tick per second of media time. If specified, then the tick rate must not be zero (0).

A ttp:tickRate attribute is considered to be significant only when specified on the tt element.

7.2.11 ttp:timeBase

The ttp:timeBase attribute is used to specify the document temporal coordinate space.

If specified, the value of this attribute must adhere to the following syntax:

ttp:timeBase
  : "media"
  | "smpte"
  | "clock"

If the time base is designated as media, then a time expression denotes a coordinate in some media object's time line, where the media object may be an external media object with which the content of a document instance is to be synchronized, or it may be the content of a document instance itself in a case where the timed text content is intended to establish an independent time line.

If the time base is designated as smpte, then a time expression denotes a [SMPTE ST 12-1] time coordinate with which the content of a document instance is to be synchronized. In this case, the value of the ttp:markerMode and ttp:dropMode parameters apply, as defined by 7.2.7 ttp:markerMode and 7.2.4 ttp:dropMode, respectively.

If the time base is designated as clock, then the time expression denotes a coordinate in some real-world time line as established by some real-time clock, such as the local wall-clock time or UTC (Coordinated Universal Time) or GPS (Global Positioning System) time lines.

If not specified, the default time base must be considered to be media.

A ttp:timeBase attribute is considered to be significant only when specified on the tt element.

When operating with either media or smpte time bases, a diachronic presentation of a document instance may be subject to transformations of the controlling time line, such as temporal reversal, dilation (expansion), or constriction (compression); however, when operating with the clock time base, no transformations are permitted, and diachronic presentation proceeds on a linear, monotonically increasing time line based on the passage of real time.

8.1.1 tt

The tt element serves as the root document element of a document instance.

The tt element accepts as its children zero or one head element followed by zero or one body element.

<tt
  tts:extent = xsd:string
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve") : default
  {any attributes in TT Parameter Namespace}
  Content: head?, body?
</tt>

The root temporal extent, i.e., the time interval over which a document instance is active, has an implicit duration that is equal to the implicit duration of the body element of the document, if the body element is present, or zero, if the body element is absent.

If the tts:extent attribute is specified on the tt element, then it must adhere to 10.2.16 tts:extent, in which case it specifies the spatial extent of the root container region in which content regions are located and presented. If no tts:extent attribute is specified, then the spatial extent of the root container region is determined by rules specified in H Root Container Region Semantics. The origin of the root container region is determined by the document processing context.

An xml:lang attribute must be specified on the tt element. If the attribute value is empty, it signifies that there is no default language that applies to the text contained within the document instance.

If no xml:space attribute is specified upon the tt element, then it must be considered as if the attribute had been specified with a value of default.

8.1.2 head

The head element is a container element used to group header matter, including metadata, profile, embedded content resources, styling, and layout information.

The head element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Profile.class element group, followed by zero or one resources element, followed by zero or one styling element, followed by zero or one layout element, followed by zero or one animation element.

Any metadata specified by children in the Metadata.class element group applies semantically to the document instance as a whole, and not just the head element.

Any parameters specified by children in the Parameters.class element group applies semantically to the document instance as a whole, and not just the head element.

A resources child element is used to specify embedded content constructs that are referenced from certain style constructs and embedded content elements.

A styling child element is used to specify style constructs that are referenced from other style constructs, by layout constructs, and by content elements.

A layout child element is used to specify layout constructs that are referenced by content elements.

An animation child element is used to specify animation constructs that target animatable content element or Layout elements.

<head
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  Content: Metadata.class*, Profile.class*, resources?, styling?, layout?, animation?
</head>

To the extent that time semantics apply to the content of the head element, the implied time interval of this element is defined to be coterminous with the root temporal extent.

8.1.3 body

The body element functions as a logical container and a temporal structuring element for a sequence of textual content units represented as logical divisions.

The body element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Animation.class element group, followed by zero or more div elements.

Any metadata specified by children in the Metadata.class element group applies semantically to the body element and its descendants as a whole.

Any animation elements specified by children in the Animation.class element group apply semantically to the body element.

<body
  animate = IDREFS
  begin = <time-expression>
  condition = <condition>
  dur = <time-expression>
  end = <time-expression>
  region = IDREF
  style = IDREFS
  timeContainer = ("par" | "seq")
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  {any attributes in TT Metadata Namespace}
  {any attributes in TT Style Namespaces}
  Content: Metadata.class*, Animation.class*, div*
</body>

An author may specify a temporal interval for a body element using the begin, dur, and end attributes. If the begin point of this interval remains unspecified, then the begin point is interpreted as the later of the beginning point of the document temporal coordinate space and the beginning point of the root temporal extent. If the end point of this interval remains unspecified, then the end point is interpreted as the ending point of the root temporal extent.

If relative begin or end times are specified on the body element, then these times are resolved by reference to the beginning of the document temporal coordinate space.

If the root temporal extent is shorter than the computed duration of the body element, then the active time interval of a body element is truncated to the active end point of the root temporal extent.

An author may associate a set of style properties with a body element by means of either the style attribute or inline style attributes or a combination thereof.

If no timeContainer attribute is specified on a body element, then it must be interpreted as having parallel time containment semantics.

8.1.4 div

The div element functions as a logical container and a temporal structuring element for a sequence of textual content units represented as logical sub-divisions or paragraphs.

The div element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Animation.class element group, followed by zero or one element in the Layout.class element group, followed by zero or more elements in the Block.class or Embedded.class element groups.

Any metadata specified by children in the Metadata.class element group applies semantically to the div element and its descendants as a whole.

Any animation elements specified by children in the Animation.class element group apply semantically to the div element.

<div
  animate = IDREFS
  begin = <time-expression>
  condition = <condition>
  dur = <time-expression>
  end = <time-expression>
  region = IDREF
  style = IDREFS
  timeContainer = ("par" | "seq")
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  {any attributes in TT Metadata Namespace}
  {any attributes in TT Style Namespaces}
  Content: Metadata.class*, Animation.class*, Layout.class?, (Block.class|Embedded.class)*
</div>

An author may associate a set of style properties with a div element by means of either the style attribute or inline style attributes or a combination thereof.

If no timeContainer attribute is specified on a div element, then it must be interpreted as having parallel time containment semantics.

8.1.5 p

A p element represents a logical paragraph, serving as a transition between block level and inline level formatting semantics.

The p element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Animation.class element group, followed by zero or one element in the Layout.class element group, followed by zero or more elements in the Inline.class or Embedded.class element groups.

Any metadata specified by children in the Metadata.class element group applies semantically to the p element and its descendants as a whole.

Any animation elements specified by children in the Animation.class element group apply semantically to the p element.

<p
  animate = IDREFS
  begin = <time-expression>
  condition = <condition>
  dur = <time-expression>
  end = <time-expression>
  region = IDREF
  style = IDREFS
  timeContainer = ("par" | "seq")
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  {any attributes in TT Metadata Namespace}
  {any attributes in TT Style Namespaces}
  Content: Metadata.class*, Animation.class*, Layout.class?, (Inline.class|Embedded.class)*
</p>

An author may associate a set of style properties with a p element by means of either the style attribute or inline style attributes or a combination thereof.

If no timeContainer attribute is specified on a p element, then it must be interpreted as having parallel time containment semantics.

If a sequence of children of a p element consists solely of character information items, then that sequence must be considered to be an anonymous span for the purpose of applying style properties that apply to span elements, for details about which, see the [construct anonymous spans] procedure.

8.1.6 span

The span element functions as a logical container and a temporal structuring element for a sequence of textual content units having inline level formatting semantics.

When presented on a visual medium, a span element is intended to generate a sequence of inline areas, each containing one or more glyph area.

The span element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Animation.class element group, followed by zero or more elements in the Inline.class or Embedded.class element groups.

Any metadata specified by children in the Metadata.class element group applies semantically to the span element and its descendants as a whole.

Any animation elements specified by children in the Animation.class element group apply semantically to the span element.

<span
  animate = IDREFS
  begin = <time-expression>
  condition = <condition>
  dur = <time-expression>
  end = <time-expression>
  region = IDREF
  style = IDREFS
  timeContainer = ("par" | "seq")
  xlink:arcrole = <uri-list>
  xlink:href = <uri>
  xlink:role = <uri-list>
  xlink:show = ("new" | "replace" | "embed" | "other" | "none") : new
  xlink:title = xsd:string
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  {any attributes in TT Metadata Namespace}
  {any attributes in TT Style Namespaces}
  Content: Metadata.class*, Animation.class*, (Inline.class|Embedded.class)*
</span>

An author may associate a set of style properties with a span element by means of either the style attribute or inline style attributes or a combination thereof.

If no timeContainer attribute is specified on a span element, then it must be interpreted as having parallel time containment semantics.

The linking attributes xlink:* may be used to link a span element with related content, using the specified location (href), roles, and title. The behavior of link activation is affected by the xlink:show attribute, the precise meaning of which is determined by the document processing context.

If a span element specifies an xlink:href attribute, then a nested span element descendant must not specify an xlink:href attribute, and, if it does, then the latter must be ignored for the purpose of presentation or activation processing.

If a sequence of children of a span element consists solely of character information items, then that sequence must be considered to be an anonymous span for the purpose of applying style properties that apply to span elements, for details about which, see the [construct anonymous spans] procedure.

8.1.7 br

The br element denotes an explicit line break.

Any metadata specified by children in the Metadata.class element group applies semantically to the br element and its descendants as a whole.

The use of Animation.class children is deprecated.

<br
  condition = <condition>
  style = IDREFS
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  {any attributes in TT Metadata Namespace}
  {any attributes in TT Style Namespaces}
  Content: Metadata.class*, Animation.class*
</br>

When presented on a visual medium, the presence of a br element must be interpreted as a forced line break.

8.2.1 condition

The condition attribute is used to conditionally exclude an element (and its descendants) from semantic processing, in which case the element is referred to as a conditionalized element.

The condition attribute may be used with (1) any element in the core vocabulary catalog except profile matter, i.e., elements of the Profile Module, and (2) any element defined by an external module that is listed in the module registry, where that element's type permits the specification of a condition attribute.

The value of a condition attribute must adhere to a <condition> expression which is evaluated at the time of presentation processing (lazy evaluation) or prior to the time of presentation processing (eager evaluation), where eager evaluation may occur only when the value resulting from evaluation cannot change or is known to not change during presentation processing.

For the purpose of presentation processing, if an element specifies a condition attribute, and its <condition> expression value evaluates to false, then the semantics of the element and its descendant elements must be ignored unless those semantics are explicitly excepted, which is to say, the element and its descendant elements are conditionally excluded regardless of the evaluation of any <condition> expressions specified on those descendant elements.

Unless a higher level protocol applies, the following exceptions apply for the purpose of determining which semantics are to be ignored when a <condition> expression value evaluates to false:

• the timing semantics of a timed element are not ignored;

• the chained referential semantics of a style element are not ignored;

8.2.2 xlink:arcrole

The xlink:arcrole attribute is used as defined by [XLink 1.1].

The xlink:arcrole attribute may be used with any span or image element.

8.2.3 xlink:href

The xlink:href attribute is used as defined by [XLink 1.1].

The xlink:href attribute may be used with any span or image element.

8.2.4 xlink:role

The xlink:role attribute is used as defined by [XLink 1.1].

The xlink:role attribute may be used with any span or image element.

8.2.5 xlink:show

The xlink:show attribute is used as defined by [XLink 1.1].

The xlink:show attribute may be used with any span or image element.

8.2.6 xlink:title

The xlink:title attribute is used as defined by [XLink 1.1].

The xlink:title attribute may be used with any span or image element.

8.2.7 xml:base

The xml:base attribute is used as defined by [XML Base].

The xml:base attribute may be used with any element in the core vocabulary catalog that admits (1) a condition attribute, (2) a descendant element in the Metadata.class element group, or (3) a descendant element that admits an xml:base attribute.

8.2.8 xml:id

The xml:id attribute is used as defined by [XML ID].

The xml:id attribute may be used with any element in the core vocabulary catalog.

8.2.9 xml:lang

The xml:lang attribute is used as defined by [XML 1.0], §2.12, Language Identification.

The xml:lang attribute must be specified on the tt element and may be specified by an instance of any other element type in the core vocabulary catalog except parameter vocabulary.

The use of xml:lang on content and metadata elements is illustrated by the following example.

<tt ... xml:lang="">
...
<p xml:lang="en">Jean said hello.</p>
<p xml:lang="fr">Jean dit bonjour.</p>
<p>
  <image src="#talking-image">
    <ttm:item name="altText" xml:lang="en">Talking</ttm:item>
    <ttm:item name="altText" xml:lang="fr">Parlant</ttm:item>
  </image>
</p>
...
</tt>

8.2.10 xml:space

The xml:space attribute is used as defined by [XML 1.0], §2.10, White Space Handling.

The xml:space attribute may be used with any element in the core vocabulary catalog except parameter vocabulary.

The semantics of the value default are fixed to mean that when performing presentation processing of a document instance as described by 11.3.1.4 Synchronic Flow Processing, processing must occur as if the following properties were specified on the affected elements of an equivalent intermediate XSL-FO document:

• suppress-at-line-break="auto"

• linefeed-treatment="treat-as-space"

• white-space-collapse="true"

• white-space-treatment="ignore-if-surrounding-linefeed"

Similarly, the semantics of the value preserve are fixed to mean that when performing presentation processing, processing must occur as if the following properties were specified on the affected elements of an equivalent intermediate XSL-FO document:

• suppress-at-line-break="retain"

• linefeed-treatment="preserve"

• white-space-collapse="false"

• white-space-treatment="preserve"

If an unnormalized horizontal tab 	 (HT) character appears in a character information item of a reduced xml infoset, then, when presented visually, that tab character is treated as if it were a single  (SPACE) character.

When performing other types of processing intended to eventually result in a visual presentation by means other than those described in this specification, the semantics of space collapsing and preservation as described above should be respected. For other types of processing, the treatment of the xml:space attribute is processor dependent, but should respect the semantics described above if possible.

8.3.1 <absolute-profile-designator>

An <absolute-profile-designator> value expression is used to either (1) define the absolute designator associated with a locally defined profile or (2) refer to a remotely defined profile.

<absolute-profile-designator>
  : <absolute-uri>

8.3.2 <absolute-uri>

An <absolute-uri> value expression is used to specify an absolute URI [URI].

<absolute-uri>
  : <uri>                                     // absolute form only

In the context of an <absolute-uri> value expression, the value syntax of the <uri> expression must adhere to the absolute form of a URI as defined by [URI], §4.3.

8.3.3 <arguments>

A <arguments> value is a sub-expression used with a function-expression non-terminal of an <expression> value.

<arguments>
  : "(" <lwsp>? ")"
  | "(" <lwsp>? argument-list <lwsp>? ")"

argument-list
  : <expression> (<lwsp>? "," <lwsp>? <expression>)*

8.3.4 <bound-parameter>

A <bound-parameter> value is one of an enumerated collection of named parameters bound to a value by the content processor.

<bound-parameter>
  : "forced"
  | "mediaAspectRatio"
  | "mediaLanguage"
  | "userLanguage"

forced

Evaluates to a boolean value that denotes whether the content processor is operating with forced subtitles enabled. If used in a document instance, then a usesForced named metadata item should be specified as a child of the head element.

mediaAspectRatio

Evaluates to a numeric value equal to the aspect ratio of the related media object.

mediaLanguage

Evaluates to a string value equal to the (primary) language of the related media object.

userLanguage

Evaluates to a string value equal to the (primary) language of the user as determined by the document processing context.

8.3.5 <condition>

A <condition> value is used to specify an expression that evaluates to a binary value which is used to determine if the semantics of a conditionalized element is respected or ignored during content processing.

<condition>
  : <expression>

A function-expression that appears in a <condition> value must take the form of a <condition-function> expression.

8.3.6 <condition-function>

A <condition-function> value is a sub-expression that may be used in a <condition> value expression.

<condition-function>
  : <media-function>
  | <parameter-function>
  | <supports-function>

8.3.7 <expression>

An <expression> value is a sub-expression of a <condition> value.

<expression>
  : logical-or-expression

logical-or-expression
  : logical-and-expression
  | logical-or-expression <lwsp>? "||" <lwsp>? logical-and-expression

logical-and-expression
  : equality-expression
  | logical-and-expression <lwsp>? "&&" <lwsp>? equality-expression

equality-expression
  : relational-expression
  | equality-expression <lwsp>? "==" <lwsp>? relational-expression
  | equality-expression <lwsp>? "!=" <lwsp>? relational-expression

relational-expression
  : additive-expression
  | relational-expression <lwsp>? "<" <lwsp>? additive-expression
  | relational-expression <lwsp>? ">" <lwsp>? additive-expression
  | relational-expression <lwsp>? "<=" <lwsp>? additive-expression
  | relational-expression <lwsp>? ">=" <lwsp>? additive-expression

additive-expression
  : multiplicitive-expression
  | additive-expression <lwsp>? "+" <lwsp>? multiplicitive-expression
  | additive-expression <lwsp>? "-" <lwsp>? multiplicitive-expression

multiplicitive-expression
  : unary-expression
  | multiplicitive-expression <lwsp>? "*" <lwsp>? unary-expression
  | multiplicitive-expression <lwsp>? "/" <lwsp>? unary-expression
  | multiplicitive-expression <lwsp>? "%" <lwsp>? unary-expression

unary-expression
  : primary-or-function-expression
  | "+" <lwsp>? unary-expression
  | "-" <lwsp>? unary-expression
  | "!" <lwsp>? unary-expression

primary-or-function-expression
  : primary-expression
  | function-expression

primary-expression
  : identifier
  | literal
  | "(" <lwsp>? expression <lwsp>? ")"

function-expression
  : identifier <arguments>

identifier
  : xsd:NCName

literal
  : boolean-literal
  | numeric-literal
  | string-literal

boolean-literal
  : "true"
  | "false"

numeric-literal
  : decimal-literal

decimal-literal
  : decimal-integer-literal "." decimal-digits? exponent-part?
  | decimal-integer-literal exponent-part?
  | "." decimal-digits exponent-part?

decimal-integer-literal
  : "0"
  | non-zero-digit decimal-digits?

decimal-digits
  : decimal-digit
  | decimal-digits decimal-digit

decimal-digit
  : "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

non-zero-digit
  : "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

exponent-part
  : exponent-indicator signed-integer

exponent-indicator
  : "e" | "E"

signed-integer
  : decimal-digits
  | "+" decimal-digits
  | "-" decimal-digits

string-literal
  : <quoted-string>

8.3.8 <fragment-profile-designator>

A <fragment-profile-designator> value expression is used to designate a local profile by reference.

<fragment-profile-designator>
  : <fragment-uri>

8.3.9 <fragment-uri>

A <fragment-uri> value expression is used to specify a fragment URI [URI].

<fragment-uri>
  : <uri>                                     // fragment component only

In the context of a <fragment-uri> value expression, the value syntax of the <uri> expression must adhere to the fragment component of a URI as defined by [URI], §3 and §3.5, i.e., the scheme, authority, path, and query components are empty (not specified), and only the fragment component is non-empty (specified).

8.3.10 <media-function>

A <media-function> value is a sub-expression that may be used in a <condition> value expression in order to perform a media query on the related media object or the document processing context.

<media-function>
  : "media(" <lwsp>? media-query <lwsp>? ")"

media-query
  : <quoted-string>

The media-query argument of a <media-function> value expression must adhere to the syntax of the media_query_list defined by [Media Queries], §3.

A <media-function> value expression evaluates to true if the specified media query evaluates to true, otherwise, the value expression evaluates to false.

If the semantics of a <media-function> expression is not supported, then that expression must evaluate to false.

8.3.11 <profile-designator>

A <profile-designator> value expression is used to designate a profile, either for the purpose of defining a profile or for the purpose of referencing a defined profile.

<profile-designator>
  : <absolute-profile-designator>
  | <relative-profile-designator>
  | <fragment-profile-designator>

8.3.12 <parameter-function>

A <parameter-function> value is a sub-expression that may be used in a <condition> value expression in order to obtain a named parameter of the document processing context.

<parameter-function>
  : "parameter(" <lwsp>? parameter-name <lwsp>? ")"

parameter-name
  : <quoted-string>

When de-quoted, the parameter-name argument of a <parameter-function> value expression must adhere to an xsd:NCName, which must, in turn, be one of the values enumerated by <bound-parameter>.

A <parameter-function> value expression evaluates to the value associated with (bound to) the specified parameter name.

8.3.13 <quoted-string>

A <quoted-string> value expression is used to specify a double or single quoted string.

<quoted-string>
  : double-quoted-string
  | single-quoted-string

double-quoted-string
  : '"' ([^"\\] | escape)* '"'

single-quoted-string
  : "'" ([^'\\] | escape)* "'"

escape
  : '\\' char

8.3.14 <relative-profile-designator>

A <relative-profile-designator> value expression is used to refer to a standardized profile with respect to the TT Profile Namespace, which serves as the base URI with which relative profile designators are absolutized.

<relative-profile-designator>
  : <relative-uri>

8.3.15 <relative-uri>

A <relative-uri> value expression is used to specify a relative URI [URI].

<relative-uri>
  : <uri>                                     // no scheme component present

In the context of a <relative-uri> value expression, the value syntax of the <uri> expression must adhere to the relative form of a URI as defined by [URI], §3, i.e., the scheme and authority components are empty (not specified), but the path, and, optionally, the query and fragment components are specified.

8.3.16 <supports-function>

A <supports-function> value is a sub-expression that may be used in a <condition> value expression in order to obtain a boolean value that denotes whether a specified feature or extension is supported or not.

<supports-function>
  : "supports(" <lwsp>? feature-or-extension-designator <lwsp>? ")"

feature-or-extension-designator
  : <quoted-string>

The feature-or-extension-designator argument of a <supports-function> value expression must express a feature designation or an extension designation as defined by E.1 Feature Designations and F.1 Extension Designations, respectively, and where the feature-namespace or extension-namespace component of the designation is optional, and, if not specified, is considered to be equal to the TT Feature Namespace or TT Extension Namespace, respectively.

A <supports-function> value expression evaluates to true if the specified feature or extension designator is (semantically) supported by the content processor.

8.3.17 <uri>

A <uri> value expression is used to specify a URI [URI].

<uri>
  : xsd:anyURI

The value syntax of the xsd:anyURI data type must adhere to the definition specified by [XML Schema Part 2], §3.2.17.

8.3.18 <uri-list>

A <uri-list> value expression is used to specify a non-empty list of URI [URI] expressions.

<uri-list>
  : <uri> (<lwsp> <uri>)*

9.1.1 audio

The audio element is used to define or refer to an audio resource.

An audio element may appear in two contexts: (1) as a child of a resources element and (2) as a child of an element in the Block.class element group, namely, as a child of a div or p element, or as a child of a span element. The former is referred to as an audio defining context, the latter as an audio presentation context.

When an audio element appears in an audio defining context, it serves as a sharable definition of an audio resource that may be referenced by other audio elements in the enclosing document instance.

When an audio element appears in an audio presentation context, it serves as a non-sharable definition of an audio resource that implies presentation (rendering) semantics, i.e., that it is intended to be played.

The audio element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Animation.class element group, followed by zero or more source elements.

<audio
  animate = IDREFS
  begin = <time-expression>
  clipBegin = <time-expression>
  clipEnd = <time-expression>
  condition = <condition>
  dur = <time-expression>
  end = <time-expression>
  src = <audio>
  style = IDREFS
  timeContainer = ("par" | "seq")
  type = xsd:string
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  {any attributes in TT Style Namespaces}
  {any attributes in TT Metadata Namespace}
  Content: Metadata.class*, Animation.class*, source*
</audio>

An audio element designates an audio resource by (1) referring to a built-in data resource, (2) referring to an external data resource, or (3) defining or referring to an embedded data resource, where the data resource contains audio content.

If an audio element specifies a src attribute, then it must not specify a child source element. Conversely, if an audio element does not specify a src attribute, then it must specify one or more child source elements.

If an audio element specifies a src attribute and its value does not refer to a fragment of the enclosing document instance, then it should specify a type attribute, in which case the value of the type attribute must correspond with the media (content) type of the referenced resource. Otherwise, a type attribute must not be specified.

If specified, the value of the clipBegin attribute must adhere to the offset-time form of a 12.3.1 <time-expression>, in which case, the value of this expression denotes a normal play time offset relative to the beginning of the referenced audio content, and designates the point where audio presentation commences. If this specified value is greater than the intrinsic duration of the referenced audio content, then the resolved value of clipBegin is considered to be the intrinsic duration. If no clipBegin attribute is specified, then a value of 0 applies.

Similarly, if specified, the value of the clipEnd attribute must adhere to the offset-time form of a 12.3.1 <time-expression>, in which case, the value of this expression denotes a normal play time offset relative to the beginning of the referenced audio content, and designates the point where presentation ceases. If this specified value is greater than the intrinsic duration of the referenced audio content, then the resolved value of clipEnd is considered to be the intrinsic duration. If no clipEnd attribute is specified, then a value equal to the intrinsic duration of the audio content applies.

The use of the audio element is illustrated by the following example.

...
<audio src="http://example.com/audio/description.mp3" type="audio/mp3"/>
...

9.1.2 chunk

The chunk element is used to represent a distinct chunk (fragment) of data.

A chunk element may appear as a child of a data element.

<chunk
  condition = <condition>
  encoding = ("base16" | "base32" | "base32hex" | "base64" | "base64url") : base64
  length = xsd:nonNegativeInteger
  xml:base = <uri>
  xml:id = ID
  Content: #PCDATA
</chunk>

If an encoding attribute is specified, then it must denote the actual encoding of the byte sequence represented by the chunk element. If no encoding attribute is specified, then the encoding must be considered to be base64.

If a length attribute is specified, then it must denote the number of decoded bytes in the byte sequence represented by the chunk element. When decoding, if a specified length value does not match the number of decoded bytes, then the chunk and its container data element must return a zero length byte sequence. If no length attribute is specified, then the chunk is considered to have a length equal to the actual number of decoded bytes.

The use of chunked data is illustrated by the following example.

...
<data type="text/plain; charset=us-ascii" length="44">
  <chunk length="19">
    VGhlIHF1aWNrIGJyb3duIGZveA==
  </chunk>
  <chunk length="25">
    IGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nLg==
  </chunk>
</data>
...

9.1.3 data

The data element functions as a generic container for or reference to arbitrary data.

A data element may appear in three contexts: (1) as a child of a resources element, referred to as a data defining context, (2) as a child of a metadata element, referred to as a data binding context for metadata, or (3) as a child of a source element, referred to as a data binding context for source, and where these latter two contexts are referred to collectively as data binding contexts.

When a data element appears in a data defining context, it serves as a sharable definition of a data resource that may be referenced by the src attribute of (1) another data element, (2) an embedded content element, or (3) a source element. In this case, the contextualized active time interval of the data element is the intersection of the active time interval of its parent resources element and the active time interval of its referring element.

When a data element appears in a data binding context, it serves as a non-sharable definition of a data resource that implies binding semantics, i.e., that it is intended to bound to (associated with) its immediate context of reference. In this case, the active time interval of the data element is the same as the active time interval of its closest ancestor timed element.

The data element accepts one of the following three content models: (1) one or more text nodes (i.e., #PCDATA), (2) zero or more elements in the Metadata.class element group followed by one or more chunk elements, or (3) zero or more elements in the Metadata.class element group followed by one or more source elements, where the first is referred to as simple data embedding, the second as chunked data embedding, and the third as sourced data embedding.

When simple data embedding is used, the data resource is obtained by decoding the #PCDATA content. When chunked data embedding is used, the data resource is obtained by concatenating the byte sequences obtained by decoding each child chunk element. When sourced data embedding is used, the data resource is obtained from the first resolvable child source element. Furthermore, a child source element must not contain a data element, but may refer to a data element in a data defining context.

<data
  condition = <condition>
  encoding = ("base16" | "base32" | "base32hex" | "base64" | "base64url") : see prose below
  format = <data-format>
  length = xsd:nonNegativeInteger
  src = <data>
  type = xsd:string : see prose below
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  Content: #PCDATA | (Metadata.class*, chunk+) | (Metadata.class*, source+)
</data>

If simple data embedding is used, i.e., the content of the data element is one or more text nodes, then an encoding attribute may be specified, and, if not specified, must be considered to be base64. If chunked or sourced data embedding is used, i.e., the content of the data element contains any child chunk or source element, then an encoding attribute must not be specified, and, if specified, must be ignored for the purpose of content processing.

If a length attribute is specified, then it must denote the number of decoded bytes in the byte sequence represented by the data element. When decoding, if a specified length value does not match the number of decoded bytes, then a zero length byte sequence must be returned. If no length attribute is specified, then the data resource is considered to have a length equal to the actual number of decoded bytes. A length attribute must not be specified when using sourced data embedding.

If simple or chunked data embedding is used, a type attribute must be specified, and must correspond with the media (content) type of the data resource. In these cases, if there is no defined type, the type application/octet-stream should be used. In the case of sourced data embedding, the media (content) type of the resolved source element is used as the type.

If a type attribute is not specified or resolved or is specified as a generic type, such as application/octet-stream, and additional format information is known about a referenced data resource that cannot be expressed in a Media Type [MIME Media Types] parameter, then a format attribute may be specified as a hint to the content processor.

The use of simple data embedding is illustrated by the following examples.

<head>
  <resources>
    <data xml:id="sharedImageData" type="image/png" length="119">
      iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8
      YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAMSURBVBhXY2BgYAAAAAQAAVzN/2kAAAAASUVORK5CYII=
    </data>
    <image xml:id="sharedImage">
      <source src="#sharedImageData"/>
    </image>
  </resources>
</head>
...
<body xmlns:tts="http://www.w3.org/ns/ttml#styling">
  <div tts:backgroundImage="#sharedImage"/>
  <div tts:backgroundImage="#sharedImage"/>
</body>

<div>
  <metadata xmlns:ttm="http://www.w3.org/ns/ttml#metadata">
    <ttm:desc>caption with metadata containing tunneled data</ttm:desc>
    <data encoding="base64">
      TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
      IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
      dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
      dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
      ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
    </data>
  </metadata>
  <p>Caption with Tunneled Data</p>
</div>

<div>
  <image>
    <source>
      <data type="image/png" length="119">
        iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8
        YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAMSURBVBhXY2BgYAAAAAQAAVzN/2kAAAAASUVORK5CYII=
      </data>
    </source>
  </image>
</div>

9.1.4 font

The font element is used to define or refer to a font resource.

A font element may appear as a child of a resources element, referred to as a font defining context.

The font element accepts as its children zero or more elements in the Metadata.class element group followed by zero or more source elements.

<font
  condition = <condition>
  family = xsd:string
  range = <unicode-range>
  style = ("normal" | "italic" | "oblique") : see prose below
  src = <font>
  type = xsd:string
  weight = ("normal" | "bold") : see prose below
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  Content: Metadata.class*, source*
</font>

A font element defines a font resource by (1) referring to a built-in data resource, (2) referring to an external data resource, or (3) defining or referring to an embedded data resource, where the data resource contains font content.

If a font element specifies a src attribute, then it must not specify a child source element. Conversely, if a font element does not specify a src attribute, then it must specify one or more child source elements.

If a font element specifies a src attribute and its value does not refer to a fragment of the enclosing document instance, then it should specify a type attribute, in which case the value of the type attribute must correspond with the media (content) type of the referenced resource. Otherwise, a type attribute must not be specified.

If any of the family, range, style, or weight attributes are specified, then they override the family name, supported character ranges, style, and weight of the actual font resource. In particular, if the specified attribute value(s) differ from the value(s) of these font characteristics as encoded in the font resource, then the specified attribute value(s) are to be used instead of the font characteristics encoded in the font resource.

If any of the family, range, style, or weight attributes are not specified, then their values must be considered to be equal to the value(s) of the same named font characteristics encoded in the font resource.

For the purpose of dereferencing (downloading) font resources, a content processor may defer the downloading process until such time that the content of the font resource is necessary in order to perform the necessary (transformation or presentation) processing.

The use of the font element is illustrated by the following example.

...
<head>
  <resources>
    <data xml:id="lastResortFont" type="application/font-woff">
      ... base64 encoded data ...
    </data>
    <font family="MyFont" range="u+20-7f,u+90-9f">
      <source src="http://example.com/fonts/myfont.otf" type="font/otf"/>
      <source src="#lastResortFont"/>
    </font>
  </resources>
</head>
...
<p tts:fontFamily="MyFont">use my font or last resort font</p>
...

9.1.5 image

The image element is used to define or refer to an image resource.

An image element may appear in two contexts: (1) as a child of a resources element and (2) as a child of an element in the Block.class element group, namely, as a child of a div or p element, or as a child of a span element. The former is referred to as an image defining context, the latter as an image presentation context.

When an image element appears in an image defining context, it serves as a sharable definition of an image resource that may be referenced by another image element or by a tts:backgroundImage style attribute in the enclosing document instance.

When an image element appears in an image presentation context, it serves as a non-sharable definition of an image resource that implies presentation (rendering) semantics.

When an image element appears as a child of a div element, then its presentation produces a block area in which the image is rendered; i.e., a block boundary is implied before and after the image element. In contrast, when an image element appears as a child of a p or span element, then its presentation produces an inline area in which the image is rendered; i.e., no block boundary is implied before and after the image element.

The presentation of an image resource referenced by a tts:backgroundImage style attribute must not affect content layout.

The image element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Animation.class element group, followed by zero or more source elements.

<image
  animate = IDREFS
  begin = <time-expression>
  condition = <condition>
  dur = <time-expression>
  end = <time-expression>
  region = IDREF
  src = <image>
  style = IDREFS
  timeContainer = ("par" | "seq")
  type = xsd:string
  xlink:arcrole = <uri-list>
  xlink:href = <uri>
  xlink:role = <uri-list>
  xlink:show = ("new" | "replace" | "embed" | "other" | "none") : new
  xlink:title = xsd:string
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  {any attributes in TT Style Namespaces}
  {any attributes in TT Metadata Namespace}
  Content: Metadata.class*, Animation.class*, source*
</image>

An image element defines an image resource by (1) referring to a built-in data resource, (2) referring to an external data resource, or (3) defining or referring to an embedded data resource, where the data resource contains image content.

If an image element specifies a src attribute, then it must not specify a child source element. Conversely, if an image element does not specify a src attribute, then it must specify one or more child source elements.

If an image element specifies a src attribute and its value does not refer to a fragment of the enclosing document instance, then it should specify a type attribute, in which case the value of the type attribute must correspond with the media (content) type of the referenced resource. Otherwise, a type attribute must not be specified.

An image element may specify an tts:extent style attribute in order to specify the presentation width or height of the image when intrinsic width or height information is not available or is intended to be overridden. If this attribute is specified on both an image element in an image presentation context and on the image element in an image defining context to which the former refers, then the attribute specified on the former takes precedence over the one specified on the latter. Presentation of an image to which a tts:extent style attribute applies is subject to a (possibly anamorphic) scaling operation in order to obtain the width and height of the specified extent.

The linking attributes xlink:* may be used to link an image element with related content, using the specified location (href), roles, and title. The behavior of link activation is affected by the xlink:show attribute, the precise meaning of which is determined by the document processing context.

When an image appears in an image defining context the following additional constraints apply:

1. attributes animate, begin, dur, end, region, and timeContainer must not be specified, and, if they appear, must be ignored for the purpose of presentation processing;

2. elements from the Animation.class element group must not appear as child elements, and, if they appear, must be ignored for the purpose of presentation processing.

The use of the image element is illustrated by the following examples.

<div>
  <p>This division has a content image that appears as a block area after this paragraph.</p>
  <image src="http://example.com/images/caption.png" type="image/png"/>
<div>
...
<div tts:backgroundImage="http://example.com/images/background.png">
  <p>This division has a background image that appears under this paragraph.</p>
<div>
...

<head>
  <resources>
    <data xml:id="caption" type="image/png" length="119">
      iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8
      YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAMSURBVBhXY2BgYAAAAAQAAVzN/2kAAAAASUVORK5CYII=
    </data>
  </resources>
</head>
<body>
  <div>
    <p>
      <image>
        <source src="#caption"/>
      </image>
    <p>
    ...
    <p>
      <image>
        <source src="#caption"/>
      </image>
    <p>
  </div>
</body>

<div>
  <image>
    <source src="http://example.com/images/caption.png" type="image/png"/>
    <source>
      <data type="image/png" length="119">
        iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8
        YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAMSURBVBhXY2BgYAAAAAQAAVzN/2kAAAAASUVORK5CYII=
      </data>
    </source>
  </image>
</div>

9.1.6 resources

The resources element is a container element used to group definitions of embedded content, including metadata that applies to this embedded content.

The resources element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Data.class, Embedded.class, or Font.class element groups.

<resources
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  Content: Metadata.class*, (Data.class|Embedded.class|Font.class)*
</resources>

To the extent that time semantics apply to the content of the resources element, the implied time interval of this element is defined to be coterminous with the root temporal extent.

9.1.7 source

The source element is used to specify the source of an embedded content resource.

The source element accepts as its children zero or more elements in the Metadata.class element group followed by zero or one data element.

If a source element specifies a src attribute, then it must not specify a child data element, in which case it is referred to as an external source if the src attribute refers to an external resource, or a non-nested embedded source if the src attribute refers to an embedded resource in the enclosing document instance.

If a source element does not specify a src attribute, then it must specify a child data element, in which case it is referred to as a nested embedded source.

A source element must not have an ancestor source element.

<source
  condition = <condition>
  format = <data-format>
  src = <data>
  type = xsd:string
  xml:base = <uri>
  xml:id = ID
  xml:lang = xsd:string
  xml:space = ("default" | "preserve")
  Content: Metadata.class*, data?
</source>

If a format attribute is specified, then it provides additional hint information about the format (i.e., formal syntax) of the embedded content. Such information may be useful in cases where no standard media (content) type label has been defined or the information cannot be expressed in a Media Type parameter [MIME Media Types]. Depending on the context of use of a source element, the values of this attribute may be further constrained.

If a src attribute is specified and its value refers to a fragment of the enclosing document instance, then there must be a data element child of a resources element which is identified by that fragment, i.e., has an xml:id attribute, the value of which matches the fragment identifier.

If a src attribute is specified and its value does not refer to a fragment of the enclosing document instance, then a type attribute should be specified, in which case it must correspond with the media (content) type of the referenced resource.

If a src attribute is specified and its value does refer to a fragment of the enclosing document instance, then a type attribute must not be specified; rather, the content type of the embedded resource is determined by the value of the type attribute on the referenced or embedded data element.

The use of the source element is illustrated by the following examples.

...
<image>
  <source src="http://example.com/images/caption.png" type="image/png"/>
</image>
...

...
<data xml:id="caption" type="image/png" length="119">
  iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8
  YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAMSURBVBhXY2BgYAAAAAQAAVzN/2kAAAAASUVORK5CYII=
</data>
...
<image>
  <source src="#caption"/>
</image>
...

...
<image>
  <source>
    <data type="image/png" length="119">
      iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8
      YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAMSURBVBhXY2BgYAAAAAQAAVzN/2kAAAAASUVORK5CYII=
    </data>
  </source>
</image>
...

9.2.1 encoding

The encoding attribute is used to specify the encoding format of data.

The encoding attribute may be specified by an instance of the following element types:

• chunk

• data

If specified, the value of an encoding attribute must take one of the following values as defined by [Data Encodings]:

• base16

• base32

• base32hex

• base64

• base64url

If not specified, then base64 semantics apply.

9.2.2 format

The format attribute is used to specify hints about the media (content) format of an embedded content resource beyond media (content) type information provided by a type attribute.

The format attribute may be specified by an instance of the following element types:

• data

• source

The value of a format attribute must adhere to a <data-format> expression.

Depending on the context of use, additional constraints may apply.

9.2.3 src

The src attribute is used to specify the location or an identifier that maps to the location of data resource.

The src attribute may be specified by an instance of the following element types:

• audio

• data

• font

• image

• source

If specified, the value of a src attribute must adhere to the value syntax of the <uri> value syntax.

Depending on the context of use, additional constraints may apply.

9.2.4 type

The type attribute is used to specify the media (content) type of data resource, and may express additional parameters that characterize the data.

The type attribute may be specified by an instance of the following element types: