Dubbing and Audio description Profiles of TTML2

A DAPT Script is a transcript or script that corresponds to a document processed within an authoring workflow or processed by a client, and conforms to the constraints of this specification. It has properties and objects defined in the following sections: Script Represents, Script Type, Default Language, Text Language Source, Script Events and, for Dubbing Scripts, Characters.

A DAPT Document is a [TTML2] timed text content document instance representing a DAPT Script. A DAPT Document has the structure and constraints defined in this and the following sections.

daptm:scriptRepresents
: <content-descriptor> ( <lwsp>+ <content-descriptor>)*
<lwsp>                # as TTML2

daptm:scriptType
  : "originalTranscript"
  | "translatedTranscript"
  | "preRecording"
  | "asRecorded"

<tt daptm:scriptType="originalTranscript">
...
</tt>

<content-descriptor>  # see registry table below
: <descriptor-token> ( <descriptor-delimiter> <descriptor-token> )*
<descriptor-token>
: (descriptorTokenChar)+
descriptorTokenChar  # xsd:NMtoken without the "."
: NameStartChar | "-" | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
<descriptor-delimiter>
: "."  # FULL STOP U+002E

This section is mainly relevant to Dubbing workflows.

A character in the programme can be described using a Character object which has the following properties:

• a mandatory Character Identifier which is a Unique Identifier used to reference the character from elsewhere in the document, for example to indicate when a Character participates in a Script Event.
• a mandatory Name which is the name of the Character in the programme
• an optional Talent Name, which is the name of the actor speaking dialogue for this Character.

A Character is represented in a DAPT Document by the following structure and constraints:

• The Character is represented in a DAPT Document by a <ttm:agent> element present at the path /tt/head/metadata/ttm:agent, with the following constraints:
  • The type attribute MUST be set to character.
  • The xml:id attribute MUST be present on the <ttm:agent> element and set to the Character Identifier.
  • The <ttm:agent> element MUST contain a <ttm:name> element with its type attribute set to alias and its content set to the Character Name.

  • If the Character has a Talent Name, it MUST contain a <ttm:actor> child element. That child element MUST have an agent attribute set to the value of the xml:id attribute of a separate <ttm:agent> element corresponding to the Talent Name, that is, whose type attribute is set to person.

    Note

    The requirement for an additional <ttm:agent> element corresponding to the Talent Name is defined in the following bullet list.

  Example 19

  ...
  <metadata>
    <ttm:agent type="character" xml:id="character_1">
      <ttm:name type="alias">DESK CLERK</ttm:name>
    </ttm:agent>
  </metadata>
  ...

  Example 20

  ...
  <metadata>
    <ttm:agent type="person" xml:id="actor_A">
      <ttm:name type="full">Matthias Schoenaerts</ttm:name>
    </ttm:agent>
    <ttm:agent type="character" xml:id="character_2">
      <ttm:name type="alias">BOOKER</ttm:name>
      <ttm:actor agent="actor_A"/>
    </ttm:agent>
  </metadata>
  ...

• If the Character has a Talent Name property:
  • A <ttm:agent> element corresponding to the Talent Name MUST be present at the path /tt/head/metadata/ttm:agent, with the following constraints:
    • its type attribute MUST be set to person
    • its xml:id attribute MUST be set.
    • it MUST have a <ttm:name> child element whose type MUST be set to full and its content set to the Talent Name
  • If more than one Character is associated with the same Talent Name there SHOULD be a single <ttm:agent> element corresponding to that Talent Name, referenced separately by each of the Characters.
  • Each <ttm:agent> element corresponding to a Talent Name SHOULD appear before any of the Character <ttm:agent> elements whose <ttm:actor> child element references it.
• All <ttm:agent> elements SHOULD be contained in the first <metadata> element in the <head> element.
  Note

  There can be multiple <metadata> elements in the <head> element, for example to include proprietary metadata but the above recommends that only one is used to define the characters.
  Editor's note

A Script Event object represents dialogue, on screen text or audio descriptions to be spoken and has the following properties:

• A mandatory Script Event Identifier which is a Unique Identifier.
• An optional Begin property and an optional End and an optional Duration property that together define the Script Event's time interval in the programme timeline
  Note

  Typically Script Events do not overlap in time. However, there can be cases where they do, e.g. in Dubbing Scripts when different Characters speak different text at the same time.

• A Represents property used to identify what content the event represents (e.g. dialogue, on screen text, etc.). Every Script Event MUST have a valid Represents property.
  Note
• Zero or more Character Identifiers indicating the Characters involved in this Script Event.
  Note

  While typically, a Script Event corresponds to one single Character, there are cases where multiple characters can be associated with a Script Event. This is when all Characters speak the same text at the same time.

  Note

  In a transcript, when the event corresponds to in-image content, for example an audio description, no Character Identifier is needed. However it may be helpful in a Pre-recording Script or an As-recorded Script context to indicate a Character signifying who voices the recording.

• Zero or more Text objects, each being either Original or Translation.

  Note

  A Script Event with no Text objects can be created as part of an initial phase of authoring, in workflows where it is helpful to block out the time intervals during which some content could be present. For example, an empty Script Event with timing properties can be created to identify an opportunity for creating an audio description. See also [DAPT-REQS] Process Step 1.

  Note

  Empty Text objects, i.e. ones that have no text content, can be used to indicate explicitly that there is no text content. It is recommended that empty Text objects are not used as a workflow placeholder to indicate incomplete work.

• zero or more Script Event Description objects, each being a human-readable description of the Script Event.
• an optional On Screen property, which is an annotation indicating the position of the subject (e.g. a character) of the Script Event
• Zero or more Mixing Instruction objects used to adjust playback of the programme audio during the Script Event.

A Script Event is represented in a DAPT Document at the path /tt/head/body//div, with the following structure and constraints:

• There MAY be any number of nested <div> element ancestors in the path between the <body> element and the <div> element corresponding to the Script Event. No further semantic is defined for such elements.
• There MUST be one <div> element corresponding to the Script Event, with the following constraints:

  • The xml:id attribute MUST be present containing the Script Event Identifier.

    Note

    See 6.3 Handling <div> and <p> elements for details of how processors deal with <div> elements that do not have an xml:id attribute and are therefore not considered to be Script Events.

  • The begin, end and dur attributes represent respectively the Begin, End and Duration of the Script Event.

    The begin and end attributes SHOULD be present. The dur attribute MAY be present.

    Note

    See 4.1.6.1 Timing Properties for additional notes on timing properties.

  • The ttm:agent attribute MAY be present and if present, MUST contain a reference to each ttm:agent attribute that represents an associated Character.
    Note
    Example 21

    ...
    <div xml:id="event_1"
         begin="9663f" end="9682f"
         ttm:agent="character_4">
    ...
    </div>
    ...

  • The daptm:represents attribute MAY be present representing the Represents property.
    Example 22

    ...
    <div xml:id="event_1"
         begin="9663f" end="9682f"
         daptm:represents="audio.dialogue">
    ...
    </div>
    ...

  • The computed value of the the daptm:represents attribute MUST be a valid non-empty value.
    Note
  • It MAY contain zero or more <p> elements representing each Text object.
  • It MAY contain a <metadata> element representing the On Screen property.
  • It MUST NOT contain any <div> element children.

The Text object contains text content typically in a single language. This language may be the Original language or a Translation language.

Text is defined as Original if it is any of:

• a transcription of dialogue in the programme audio, in the same language as that dialogue;
• a transcription of text visible in the programme video, in the same language as that text;
• an untranslated representation of non-dialogue sound;
• an untranslated description of the scene in the programme video;
• an untranslated representation of content whose language has not been determined (this is not recommended);

Text is defined as Translation if it is a representation of an Original Text object in a different language.

Text can be identified as being Original or Translation by inspecting its language and its Text Language Source together, according to the semantics defined in Text Language Source.

The source language of Translation Text objects and, where applicable, Original Text objects is indicated using the Text Language Source property.

If the Text object, or part of it, represents something more specific, or different, to its parent Script Event, it can have a different Represents property.

A Text object may be styled.

Zero or more Mixing Instruction objects used to modify the programme audio during the Text MAY be present.

A Text object is represented in a DAPT Document by a <p> element at the path /tt/head/body//div/p, with the following constraints:

• The Text of the Script Event is represented by the character content of the <p> element and of all of its <span> descendant elements, after <metadata> elements and foreign elements have been pruned, after replacing <br> elements by line breaks, and after applying White Space Handling as defined in [XML].
  Note
• The <p> element SHOULD have a daptm:langSrc attribute representing the Text object's Text Language Source, that is, indicating whether the Text is Original or a Translation and if its source had an inherent language.
  Note
  Note
• The computed value of daptm:langSrc SHOULD NOT be und.
  Note
• The <p> element SHOULD have an xml:lang attribute corresponding to the language of the Text object.
  Note
  Example 23

  <div xml:id="event_3"
       begin="9663f" end="9682f"
       ttm:agent="character_3">
    <p xml:lang="pt-BR">Você vai ter.</p>
    <p xml:lang="fr" daptm:langSrc="pt-BR">Bah, il arrive.</p>
  </div>

  Note

  In some cases, a single section of untranslated dialogue can contain text in more than one language. Rather than splitting a Script Event into multiple Script Events to deal with this, Text objects in one language can also contain some words in a different language. This is represented in a DAPT Document by setting the xml:lang and daptm:langSrc attributes on inner <span> elements.

  Note

  <span> elements can be used to add specific timing as illustrated in Example 10 to indicate the timing of the audio rendering of the relevant section of text. Per [TTML2], timing of the <span> element is relative to the parent element's computed begin time.

• The daptm:represents attribute MAY be present on the <p> element or any of its descendant <span> elements, representing the Represents property.
• It MAY contain zero or more <audio> elements representing each Audio Recording object.
• It MAY contain zero or more <animate> elements representing each Mixing Instruction object.

The Text Language Source property is an annotation indicating the source language of a Text object, if applicable, or that the source content had no inherent language:

• If it has a value that does not represent a language, such as und or zxx, the Text is Original.
  Note
  Note
• Otherwise (if it has a value that does represent a language):
  • if its value is the same as the language of the Text object, the Text is Original.
  • otherwise (if the value is different to the language of the Text), the Text is a Translation, whose source language is the Text Language Source property's value.

Text Language Source is an inheritable property.

The Text Language Source property is represented in a DAPT Document by a daptm:langSrc attribute with the following syntax, constraints and semantics:

daptm:langSrc
: <language-identifier>
<language-identifier>   # well-formed BCP-47 language tag

• The value MUST be a well-formed language identifier as defined by [BCP47].
• The default value is und.
• It applies to <p> and <span> elements.
• It MAY be specified on the following elements: <tt>, <body>, <div>, <p> and <span>.
• The inheritance model of the daptm:langSrc attribute is as follows:
  • If it is present on an element, the computed value is the specified value.
  • Otherwise (if it is not present on an element), the computed value of the attribute on that element is the computed value of the same attribute on the element's parent, or if the element has no parent it is the default value.
  Note

  The inheritance model of the daptm:langSrc attribute is intended to match the inheritance model of the xml:lang attribute [XML].

• The semantics of the computed value are as follows:
  • If the computed value is a value that does not represent linguistic content then it indicates that the Text is Original. Example values in this category are:
    • und for content whose language has not been determined;
    • zxx for content without an inherent language.
  • Otherwise, if the computed value represents linguistic content, then:
    • if the computed value is the same as the computed value of the xml:lang attribute, then it indicates that the Text is Original and sourced from content with an inherent language.
    • Otherwise (the computed value differs from the computed value of the xml:lang attribute), it indicates that the Text is a translation, and the computed value is the language from which the Text was translated.

The On Screen property is an annotation indicating the position in the scene relating to the subject of a Script Event, for example of the character speaking:

• ON - the Script Event's subject is on screen for the entire duration
• OFF - the Script Event's subject is off screen for the entire duration
• ON_OFF - the Script Event's subject starts on screen, but goes off screen at some point
• OFF_ON - the Script Event's subject starts off screen, but goes on screen at some point

If omitted, the default value is "ON".

The On Screen property is represented in a DAPT Document by a daptm:onScreen attribute on the <div> element, with the following constraints:

• The following attribute corresponding to the On Screen Script Event property may be present:

  daptm:onScreen
    : "ON"     # default
    | "OFF"
    | "ON_OFF"
    | "OFF_ON"

The Represents property indicates which component of the related media object the Script Event or a Text (or a part of) represents.

The Represents property is represented in a DAPT Document by a daptm:represents attribute, whose value MUST be a single <content-descriptor>.

The daptm:represents attribute MAY be present on any of the elements <tt>, <body>, <div>, <p> and <span>.

The Represents property is inheritable. If it is absent from an element then its computed value is the computed value of the Represents property on its parent element, or, if it has no parent element, it is the empty string. If it is present on an element then its computed value is the value specified.

It is an error for a Represents property value not to be a content descriptor sub-type of at least one of the values in the Script Represents property.

The Script Event Description object is an annotation providing a human-readable description of some aspect of the content of a Script Event. Script Event Descriptions can themselves be classified with a Description Type.

A Script Event Description object is represented in a DAPT Document by a <ttm:desc> element at the <div> element level.

Zero or more <ttm:desc> elements MAY be present.

Script Event Descriptions SHOULD NOT be empty.

The <ttm:desc> element MAY specify its language using the xml:lang attribute.

...
  <body daptm:langSrc="zxx">
    <div begin="10s" end="13s" xml:id="a1">
      <ttm:desc>Scene 1</ttm:desc>
      <p xml:lang="en">
        <span>A woman climbs into a small sailing boat.</span>
      </p>
      <p xml:lang="fr" daptm:langSrc="en">
        <span>Une femme monte à bord d'un petit bateau à voile.</span>
      </p>
    </div>
    <div begin="18s" end="20s" xml:id="a2">
      <ttm:desc>Scene 1</ttm:desc>
      <p xml:lang="en">
        <span>The woman pulls the tiller and the boat turns.</span>
      </p>
      <p xml:lang="fr" daptm:langSrc="en">
        <span>La femme tire sur la barre et le bateau tourne.</span>
      </p>
    </div>
  </body>
...

Each Script Event Description can be annotated with one or more Description Types to categorise further the purpose of the Script Event Description.

Each Description Type is represented in a DAPT Document by a daptm:descType attribute on the <ttm:desc> element.

The <ttm:desc> element MAY have zero or one daptm:descType attributes. The daptm:descType attribute is defined below.

daptm:descType : string

The permitted values for daptm:descType are either those listed in the following registry table, or can be user-defined:

Valid user-defined values MUST begin with x-.

...
  <body>
    <div begin="10s" end="13s" xml:id="a123">
      <ttm:desc daptm:descType="pronunciationNote">[oːnʲ]</ttm:desc>
      <p>Eóin looks around at the other assembly members.</p>
    </div>
  </body>
...

Amongst a sibling group of <ttm:desc> elements there are no constraints on the uniqueness of the daptm:descType attribute, however it may be useful as a distinguisher as shown in the following example.

...
  <body daptm:langSrc="zxx">
    <div begin="10s" end="13s" xml:id="a1">
      <ttm:desc daptm:descType="scene">Scene 1</ttm:desc>
      <ttm:desc daptm:descType="plotSignificance">High</ttm:desc>
      <p xml:lang="en">
        <span>A woman climbs into a small sailing boat.</span>
      </p>
      <p xml:lang="fr" daptm:langSrc="en">
        <span>Une femme monte à bord d'un petit bateau à voile.</span>
      </p>
    </div>
    <div begin="18s" end="20s" xml:id="a2">
      <ttm:desc daptm:descType="scene">Scene 1</ttm:desc>
      <ttm:desc daptm:descType="plotSignificance">Low</ttm:desc>
      <p xml:lang="en">
        <span>The woman pulls the tiller and the boat turns.</span>
      </p>
      <p xml:lang="fr" daptm:langSrc="en">
        <span>La femme tire sur la barre et le bateau tourne.</span>
      </p>
    </div>
  </body>
...

An Audio object is used to specify an audio rendering of a Text. The audio rendering can either be a recorded audio resource, as an Audio Recording object, or a directive to synthesize a rendering of the text via a text to speech engine, which is a Synthesized Audio object. Both are types of Audio object.

It is an error for an Audio not to be in the same language as its Text.

A presentation processor that supports audio plays or inserts the Audio at the specified time on the related media object's timeline.

A Mixing Instruction object is a static or animated adjustment of the audio relating to the containing object. It has the following properties:

• Zero or more Gain properties. The gain acts as a multiplier to be applied to the related Audio;
• Zero or more Pan properties. The pan adjusts the stereoscopic (left/right) position;
• An optional Begin and an optional End and an optional Duration property that together define the time interval during which the Mixing Instruction applies;
• An optional Fill property that specifies whether, at the end time of an animated Mixing Instruction, the specified Gain and Pan properties should be retained (freeze) or reverted (remove).

A Mixing Instruction is represented by applying audio style attributes to the element that corresponds to the relevant object, either inline, by reference to a <style> element, or in a child (inline) <animate> element:

• The tta:gain attribute represents the Gain property;
• The tta:pan attribute represents the Pan property.

If the Mixing Instruction is animated, that is, if the adjustment properties change during the containing object's active time interval, then it is represented by one or more child <animate> elements. This representation is required if more than one Gain or Pan property is needed, or if any timing properties are needed.

The <animate> element(s) MUST be children of the element corresponding to the containing object, and have the following constraints:

• The begin, end and dur attributes represent respectively the Begin, End and Duration properties;
• The fill attribute represents the Fill property;
• The tta:gain attribute represents the Gain property, and uses the animation-value-list syntax to express the list of values to be applied during the animation period;
• The tta:pan attribute represents the Pan property, and uses the animation-value-list syntax to express the list of values to be applied during the animation period.

The TTML representation of animated Mixing Instructions is illustrated by Example 4.

See also E. Audio Mixing.

A DAPT Document MUST be serialised as a well-formed XML 1.0 [xml] document encoded using the UTF-8 character encoding as specified in [UNICODE].

The resulting [xml] document MUST NOT contain any of the following physical structures:

• entity declarations; and
• entity references other than to predefined entities.

The requirements in this section are intended to facilitate forwards and backwards compatibility, specifically to permit:

• DAPT processors targeted at one version of the specification to process DAPT documents that include vocabulary or semantics defined in future versions, albeit without supporting the later features;
• DAPT processors targeted at one version of the specification to process DAPT documents authored for an earlier version with similar or identical behaviour to a DAPT processor targeted at that earlier version.

A DAPT document that conforms to more than one version of the specification could specify conformance to multiple DAPT content profiles.

...
  <head>
    <metadata>
      <ttm:title>A example document title</ttm:title>
    </metadata>
  </head>
...

...
  <metadata xmlns:vendorm="https://www.example-vendor.com/ns/ttml#metadata">
    <vendorm:programType>Episode</vendorm:programType>
    <vendorm:episodeSeason>5</vendorm:episodeSeason>
    <vendorm:episodeNumber>8</vendorm:episodeNumber>
    <vendorm:internalId>15734</vendorm:internalId>
    <vendorm:information>Some proprietary information</vendorm:information>
  </metadata>
...

The following namespaces (see [xml-names]) are used in this specification:

The namespace prefix values defined above are for convenience and DAPT Documents MAY use any prefix value that conforms to [xml-names].

The namespaces defined by this specification are mutable as described in [namespaceState]; all undefined names in these namespaces are reserved for future standardization by the W3C.

Within DAPT, the common language terms audio and video are used in the context of a programme. The audio and video are each a part of what is defined in [TTML2] as the Related Media Object that provides the media timeline and is the source of the main programme audio, and any visual timing references needed when adjusting timings relevant to the video image, such as for lip synchronization.

<tt xmlns="https://www.w3.org/ns/ttml" 
    xmlns:ttp="https://www.w3.org/ns/ttml#parameter"
    xmlns:daptm="https://www.w3.org/ns/ttml/profile/dapt#metadata"
    xmlns:ebuttm="urn:ebu:tt:metadata"
    xml:lang="en" 
    ttp:contentProfiles="https://www.w3.org/ns/ttml/profile/dapt1.0/content"
    daptm:scriptRepresents="audio.dialogue"
    daptm:scriptType="originalTranscript">
  <head>
    <metadata>
      <ebuttm:sourceMediaIdentifier>https://example.org/programme.mov</ebuttm:sourceMediaIdentifier>
    </metadata>
  </head>
  <body>
    ...
  </body>
</tt>

If the DAPT Document is intended to be used as the basis for producing an [TTML-IMSC1.2] document, the synchronization provisions of [TTML-IMSC1.2] apply in relation to the video.

Timed content within the DAPT Document is intended to be rendered starting and ending on specific audio samples.

In constrained applications, such as real-time audio mixing and playback, if accurate synchronization to the audio sample cannot be achieved in the rendered output, the combined effects of authoring and playback inaccuracies in timed changes in presentation SHOULD meet the synchronization requirements of [EBU-R37], i.e. audio changes are not to precede image changes by more than 40ms, and are not to follow them by more than 60ms.

Likewise, authoring applications SHOULD allow authors to meet the requirements of [EBU-R37] by defining times with an accuracy such that changes to audio are less than 15ms after any associated change in the video image, and less than 5ms before any associated change in the video image.

Taken together, the above two constraints on overall presentation and on DAPT documents intended for real-time playback mean that content processors SHOULD complete audio presentation changes no more than 35ms before the time specified in the DAPT document and no more than 45ms after the time specified.

Within a DAPT Script, the following constraints apply in relation to time attributes and time expressions:

This specification does not put additional constraints on the layout and rendering features defined in [TTML-IMSC1.2].

Style references or inline styles MAY be used, using any combination of style attributes, <style> elements and inline style attributes as defined in [TTML2] or [TTML-IMSC1.2].

The following metadata elements are permitted in DAPT and specified in [TTML2] as containing #PCDATA, i.e. text data only with no element content. Where bidirectional text is required within the character content within such an element, Unicode control characters can be used to define the base direction within arbitrary ranges of text.

• <ttm:copyright>
• <ttm:desc>
• <ttm:item>
• <ttm:name>
• <ttm:title>

The <p> and <span> content elements permit the direction of text to be specified using the tts:direction and tts:unicodeBidi attributes. Document authors should use this more robust mechanism rather than using Unicode control characters.

Note

The following example taken from [TTML2] demonstrates the syntax for bidirectional text markup within the <p> and <span> elements.

Example 36

<p>
The title of the book is
"<span tts:unicodeBidi="embed" tts:direction="rtl">نشاط التدويل، W3C</span>"
</p>

An example rendering of the above fragment is shown below.

A processor that takes as its input a DAPT document that contains vocabulary relating to features that it does support, but where support for those features is excluded from the content profiles to which the document claims conformance, SHOULD NOT implement those features in the context of that document.

[TTML2] allows <div> elements to contain any combination of <div> elements and <p> elements. The DAPT data model describes how each Script Event is represented by a <div> element that contains zero or more <p> elements. It also permits other intermediate <div> elements in the path between the <body> element and those Script Event <div> elements. In addition, attributes not corresponding to properties in the DAPT data model are permitted.

This gives rise to possibilities such as:

• <div> elements that contain children that are not Text objects, for example other <div> elements or <metadata> elements;
• <div> elements that do not have attributes required for Script Events, like xml:id;
• <div> elements that have attributes absent from the DAPT data model for Script Events, like xml:space;
• <p> elements whose parent <div> element does not appear to be a Script Event.

The following processing rules resolve these cases.

Rules for identifying Script Events:

1. A <div> element that has no <div> element children and includes the TTML representations of all the mandatory properties of a Script Event MUST be mapped to a Script Event, such as having a valid xml:id representing the Script Event Identifier, even if it also contains additional unrecognised vocabulary;
2. A <div> element that contains any <div> element children MUST NOT be mapped to a Script Event; the processor instead MUST iterate through those <div> element children (recursively, in a depth-first traversal) and consider if each one meets the requirements of a Script Event;
3. Any remaining unmapped <div> elements MUST NOT be mapped to a Script Event.

Rules for identifying Text objects:

1. A <p> element that is a child of a <div> element that maps to a Script Event MUST be mapped to a Text object.
2. A <p> element that is not a child of a <div> element that maps to a Script Event MUST NOT be mapped to a Text object.

Some attributes have semantics for computing their value that depend on the computed value of the attribute on some other element. For example if the xml:lang attribute is not specified on an element then its computed value is the computed value of the same attribute on the element's parent.

The daptm:scriptRepresents, daptm:onScreen and daptm:descType attributes are defined only when specified on a particular element.

Or, for another example, the computed times of an element in a DAPT document are relative to the begin time of the element's parent. If a <div> element specifies a begin attribute, then the computed times of its child <div> elements are relative to that parent <div> element's begin time, and so on down the hierarchy. It is important to include those "intermediate" <div> elements' times in the computation even if the processing target is an instance of the DAPT data model in which they have no direct equivalent; otherwise the Script Event Begin and End times would be wrong.

Considering this situation more generally, it is possible that, within a DAPT document, there can be TTML elements that do not directly correspond to objects in the DAPT data model, and those elements can specify attributes that affect the computation of attribute values that apply to elements that do correspond to objects in the DAPT data model.

The semantics defined by [TTML2] or, for vocabulary defined herein, this specification, take precedence in this scenario. Implementations MUST compute attribute values based on the contents of the document instance before applying those computed values to DAPT data model objects. For example a processor that supports TTML2 styling features would need to implement the TTML2 semantics for inheritance and computing relative values of attributes like tts:fontSize.

If an implementation internally creates DAPT data model objects, such as the Script Events shown in the example above, it is important for interoperability that they use the computed values.

Conformant DAPT Documents are [TTML2] timed text content document instances that conform to the normative provisions of this specification. Those provisions are expressed using the profile vocabulary of [TTML2] in the content profile defined in F. Profiles.

Conformant DAPT Processors are [TTML2] content processors that conform to the normative provisions of this specification. Those provisions are expressed using the profile vocabulary of [TTML2] in the processor profile defined in F. Profiles.