Dubbing and Audio description Profiles of TTML2

DAPT Data Model and corresponding TTML syntax

This section specifies the data model for DAPT and its corresponding TTML syntax. In the model, there are objects which can have properties and be associated with other objects. In the TTML syntax, these objects and properties are expressed as elements and attributes, though it is not always the case that objects are expressed as elements and properties as attributes.

illustrates the DAPT data model, hyperlinking every object and property to its corresponding section in this document. Shared properties are shown in italics. All other conventions in the diagram are as per [[?uml]].

Class diagram showing main entities in the DAPT data model.

DAPT Script

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: Workflow Type, Script Type, Primary Language, Script Events and, for Dubbing Scripts, Characters.

A DAPT Document is a TTML Document Instance representing a DAPT Script. A DAPT Document has the structure and constraints defined in the following sections.

Workflow Type

The Workflow Type property is a mandatory property of a DAPT Script which indicates if the workflow is for Dubbing or Audio Description.

To represent this property, the daptm:workflowType attribute MUST be present on the <tt> element:

  daptm:workflowType
    : "dubbing"
    | "audioDescription"

Script Type

The Script Type property is a mandatory property of a DAPT Script which describes the type of documents used in Dubbing and Audio Description workflows, among the following: Original Language Transcript, Translated Transcript, Pre-recording Script, As-recorded Script.

To represent this property, the daptm:scriptType attribute MUST be present on the <tt> element:

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

The definitions of the types of documents and the corresponding daptm:scriptType values are:

Original Language Transcript:
When the daptm:scriptType value is originalTranscript, the document is a literal transcription of the dialogue and on-screen text in their original spoken/written language(s).

Script Events in this type of transcript SHOULD contain Text objects whose Text Language Source is set to Original and SHOULD NOT contain Text objects whose Text Language Source is set to Translation.

If a programme contains dialogue in English and Hebrew, the Original Language Transcript will contain some Script Events in English and some in Hebrew, all marked as Original Text Language Source. None of the Script Events is marked as Translation.
Translated Transcript:
When the daptm:scriptType value is translatedTranscript, the document represents a translation of the Original Language Transcript in a common language.

It can be adapted to produce a Pre-Recording Script, and/or used as the basis for a further translation into the Target Recording Language.

Script Events in this type of transcript SHOULD contain Text objects whose Text Language Source is set to Translation. They MAY also contain Original language Text.

A Script Event in this type of transcript has a Translation Text object in the Target Recording Language and can also contain an Original Text object, for context, to assist in the adaption process. It can also have Translation Text objects in other languages, for example used as intermediate ("pivot") translations, or as additional context to assist in the adaptation process.

If a programme contains dialogue in English and Hebrew, the French Translated Transcript will contain at least the translation in French of all Script Events. It may still retain text content in Hebrew and English to assist further processing.
Pre-recording Script:
When the daptm:scriptType value is preRecording, the document represents the result of the adaptation of an Original Language Transcript or a Translated Transcript for recording, e.g. for better lip-sync in a dubbing workflow, or to ensure that the words can fit within the time available in an audio description workflow.

Script Events in this type of script SHOULD contain Text objects in the Target Recording Language. They MAY also contain Original Text objects from the Original Language Transcript in the case that the Original language is not the Target Recording Language, for context, to assist further processing.

The Script Type of a DAPT Script cannot necessarily be detected by inspecting the text content of the document. For example, the adaptation of a Translated Transcript into a Pre-recording Script can consist in replacing some words in the text content of a Script Event without altering the rest of the document. In either case, Text objects that are translations have Text Language Source properties set to Translation.

The Text objects in Audio Description Script Events are each expected to have a Text Language Source property of Original if their language is the Primary Language or, when representing in-image text, if they are in the same language as that text. If audio description scripts are translated, their translations would be marked as Translation.
As-recorded Script:
When the daptm:scriptType value is asRecorded, the document represents the actual audio recording.

Script Events in this type of script SHOULD contain Text objects in the Target Recording Language and MAY also contain Original Text objects from the Original Language Transcript or Translation Text objects in other languages for context and quality verification. They MAY also contain links to audio and mixing instructions for the purpose of producing an audio track incorporating the recordings.

Even though the output of the dubbing workflow is in the same language as those Text objects with the matching language, the Text Language Source of those Text objects remains Translation since they differ from the original language of the dialogue.

The following example is orphaned - move to the top of the section, before the enumerated script types?

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

Primary Language

The Primary Language is a mandatory property of a DAPT Script which represents the default language for the Text content of Script Events. This language may be the Original language or a Translation language. When it represents a Translation language, it may be the final language for which a dubbing or audio description script is being prepared, called the Target Recording Language or it may be an intermediate, or pivot, language used in the workflow.

The Primary Language is represented in a DAPT Document by the following structure and constraints:

the xml:lang attribute MUST be present on the <tt> element and its value MUST NOT be empty.

All text content in a DAPT Script has a specified language. When multiple languages are used, the Primary Language can correspond to the language of the majority of Script Events, to the language being spoken for the longest duration, or to the language arbitrarily chosen by the author.

Text content is marked either as being either in the Original language or as being a Translation independently of the Primary Language, using the Text Language Source property.

An Original Language Transcript script is prepared for a video containing dialogue in Danish and Swedish. The Primary Language is set to Danish by setting xml:lang="da" on the <tt> element. Script Events that contain Swedish Text override this by setting xml:lang="sv" on the <p> element. Script Events that contain Danish Text can set the xml:lang attribute or omit it, since the inherited language is the Primary Language of the document. In both cases the Script Events' Text objects are <p> elements that represent original language text and therefore set their Text Language Source to Original by setting daptm:langSrc="original".

Script Events

A DAPT Script MAY contain zero or more Script Event objects, each corresponding to dialogue, on screen text, or descriptions for a given time interval.

Characters

A DAPT Script MAY contain zero or more Character objects, each describing a character that can be referenced by a Script Event.

Shared properties

Some of the properties in the DAPT data model are common within more than one object type, and carry the same semantic everywhere they occur. These shared properties are listed in this section.

Would it be better to make a "Timed Object" class and subclass Script Event, Mixing Instruction and Audio Recording from it?

Timing Properties

The following timing properties define when the entities that contain them are active:

The Begin property defines when an object becomes active, and is relative to the active begin time of the parent object. DAPT Scripts begin at time zero on the media timeline.
The End property defines when an object stops being active, and is relative to the active begin time of the parent object.
The Duration property defines the maximum duration of an object.
If both an End and a Duration property are present, the end time is the earlier of End and Begin + Duration.

If any of the timing properties is omitted, the following rules apply:

The default value for Begin is zero, i.e. the same as the begin time of the parent object.
The default value for End is indefinite, i.e. it resolves to the same as the end time of the parent timed object, if there is one. The end time of a DAPT Script is for practical purposes the end of the Related Media Object.
The default value for Duration is indefinite, i.e. the end time resolves to the same as the end time of the parent object.

Character

In Dubbing Scripts, it is necessary to identify each character in the programme. This is done with a Character object which has the following properties:

a mandatory 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, or to link a Character Style to its Character.
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
zero or more Character Style objects which can be applied to control the visual appearance of Script Events spoken by the Character, for example during recording by an actor or when transforming the script into subtitles.

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

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.
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 and set to the Character Identifier.
- The ttm:agent 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 xml:id of the <ttm:agent> element corresponding to the Talent Name, that is, whose type is set to person.
```
...
<metadata>
  <ttm:agent type="character" xml:id="character_1">
    <ttm:name type="alias">DESK CLERK</ttm:name>
  </ttm:agent>
</metadata>
...
          
```
```
...
<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>
...
          
```
All <ttm:agent> elements SHOULD be contained in the first <metadata> element in the <head> element.
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.

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

Each Character Style is represented by one or more <style> elements at the path /tt/head/styling/style.
Each such <style> element is associated with the Character by having a ttm:agent attribute whose value is the xml:id of the <ttm:agent> element representing the Character.
A Script Event MAY apply Character Styles by including the xml:id of each style in the style attribute of the <div> element that defines that Script Event.
A Text object MAY apply Character Styles by including the xml:id of each style in the style attribute of the <p> element that defines that Text object.
A Script Event SHOULD NOT apply a Character Style for a Character that is not associated with that Script Event.
A Text object SHOULD NOT apply a Character Style for a Character that is not associated with that Text object's Script Event.

Any style attribute defined in [[TTML2]] or [[TTML-IMSC1.2]] (or other profiles using non-W3C namespaces) can be present on the <style> element.

A <style> element MAY omit the ttm:agent attribute if it is not associated with a Character. Such styles MAY be applied in the same way as any other style, via a reference in the style attribute.

Character Styles are applied to Script Events and Text by using the style attribute to specify the set of applicable styles. Presentation Processors MUST NOT apply character styles to text if they are not specified using the style attribute.

Given a document that specifies a <style> element with a ttm:agent attribute, and a Script Event with the same ttm:agent attribute value, but that does not reference (directly or by inheritance) that style using a style attribute, a Presentation Processor would not be conformant if it applied that style anyway, solely on the basis of the ttm:agent being the same.

...
<styling>
  <style xml:id="style_a"
         ttm:agent="character_3"
         tts:color="#FFFFFF" tts:backgroundColor="#8F42AD"/>         
</styling>     
...
  <div xml:id="event_6" ttm:agent="character_3" style="style_a" ... >
  <-- Script event contents here, in Character 3's style -->
  </div>

  <div xml:id="event_7" ttm:agent="character_3" style="some_other_style" ... >
  <-- Script event contents here, not in Character 3's style -->
  </div>

Script Event

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 unique in the script
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
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.
An optional Script Event Type used to identify the type of event (e.g. dialogue, on screen text) in Dubbing Scripts.
Zero or more Character Identifiers indicating the Characters involved in this Script Event.
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.
Zero or more Text objects, each representing either the Original language transcript or Translations of the original language script in other languages.

Empty Text objects 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.
an optional Script Event Description property, as 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 by the following structure and constraints:

There MUST be one <div> element, with the following constraints:
- The xml:id attribute MUST be present containing the Script Event Identifier.
- 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.
  
  As noted in [[?TTML2]] if both an end attribute and a dur attribute are present, the end time is the earlier of end and (begin + dur).
  If timing attributes are omitted, the following rules apply:
  - The default value for begin is zero, i.e. the same as the begin time of the parent element.
  - The default value for end is indefinite, i.e. it resolves to the same as the end time of the parent timed element, if there is one. The topmost timed element is the <body> element, whose end time is for practical purposes the end of the Related Media Object.
  - The default value for dur is indefinite, i.e. the end time resolves to the same as the end time of the parent element.
- The ttm:agent attribute MAY be present and if present, MUST contain a reference to each ttm:agent that represents an associated Character.
  Multiple references are specified using a space-separated list.
```
...
<div xml:id="event_1"
     begin="9663f" end="9682f" 
     ttm:agent="character_4">
...
</div>
...
          
```
- It MAY contain zero or more <p> elements representing each Text object.
- The style attribute MAY be present. If present, it MAY contain a reference to the <style> defining the Character Style. Additional style references or inline styles MAY be used.
- It MAY contain a <metadata> element representing the On Screen property.

Text

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

A Text object may be styled and associated with a Character.

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 with the following constraints:

The text content of the <p> is the Text of the Script Event.
The text content of the paragraph can be structured using TTML elements such as <br> or <span> which can include or reference TTML style attributes such as tts:ruby used to alter the layout or styling of sections of text within each paragraph. Similarly metadata can be added using attributes or <metadata> elements.
The style attribute MAY be present. If present, it MAY contain a reference to the <style> that defines the relevant Character Style. Additional style references or inline styles MAY be used as defined in [[TTML2]], and MAY be applied to sub-sections of the text defined by <span> elements.
The referenced or inline styles MAY include the tta:speak or tta:pitch attributes representing a Synthesized Audio object.
Synthesized audio styles may be applied to <span> elements within the text content to vary the rate or pitch of specific sub-sections of the text.
The <p> element MUST have one Text Language Source property.
The <p> element SHOULD have an xml:lang attribute corresponding to the language of the Text object.
If a <p> element omits the xml:lang attribute then its computed language is derived by inheritance from its parent element, and so forth up to the root <tt> element, which is required to set the Primary Language via its xml:lang attribute. Care should be taken if changing the Primary Language of a DAPT Script in case doing so affects descendant elements unexpectedly. Authors can mitigate this risk by explicitly setting xml:lang on all <p> elements.

Within a <div> representing a Script Event the order of <p> children is significant.
```
<div xml:id="event_3"
     begin="9663f" end="9682f" 
     style="style_a"
     ttm:agent="character_3">
  <p xml:lang="pt-BR" daptm:langSrc="original" >Você vai ter.</p>
  <p xml:lang="fr" daptm:langSrc="translation" >Bah, il arrive.</p>
</div>
                
```
In some cases, a single section of original language dialogue can contain some words in other languages. 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 attribute on inner <span> elements.
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.

Text Language Source

The Text Language Source property is an annotation indicating whether a Text object is in the same language as the relevant part of the audio's language (original), or if it is a representation in another language (translation):

Original - the Text is any of:
1. the same language as the dialogue that it represents in the original programme audio;
2. a transcription of text visible in the original programme video, in the same language as that text;
3. representative of non-dialogue sound and is in the Primary Language of the DAPT Script;
4. representative of the scene in the original programme video, and is in the Primary Language of the DAPT Script.
Translation - the Text is a representation of the Original language text in a different language.

The language of a Text object whose Text Language Source is Original can be different to the document's Primary Language. For example a transcript of a short piece of dialogue spoken in a different language to the majority of the dialogue would be annotated with both a different xml:lang value and as being Original.

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

Should we use an abbreviated attribute name?

Initial design is to use an abbreviated name and original|translation, though I considered using an abbreviated value too, since this attribute will appear on every <p> element. Abbreviating O for Original is probably a bad idea because the letter O and the number 0 can easily be confused. I also considered P for Primary but that caused potential confusion between Primary Language and Primary Text Language Source.

daptm:langSrc
  : "original"
  | "translation"

On Screen

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".

When daptm:workflowType is set to audioDescription the subject of each Script Event, i.e. what is being described, is expected to be in the video image, therefore the default of "ON" allows the property to be omitted in those cases without distortion of meaning.

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"

Script Event Description

The Script Event Description property is an annotation providing a human-readable description of a Script Event.

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

The Script Event Description does not need to be unique, i.e. it does not need to have a different value for each Script Event. For example a particular value could be re-used to identify in a human-readable way one or more Script Events that are intended to be processed together, e.g. in a batch recording.

The <ttm:desc> element MAY have a daptm:descType attribute specified to indicate the type of description. The daptm:descType attribute is defined below. Its possible values are as indicated in the registry at YYY.

Registry to be defined.

daptm:descType : string

Multiple <ttm:desc> elements MAY be present with different values of daptm:descType, as in the following example.

Script Event Type

The Script Event Type property provides one or more space-separated keywords representing the type of the Script Event, i.e. spoken text, or on-screen text, and in the latter case, the type of on-screen text (title, credit, location, ...). The possible keywords are indicated in the registry at XXXX.

Registry to be defined.

The Script Event Type is represented in a DAPT Document by the following attribute:

daptm:eventType : string

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

Audio

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.

The Audio object is "abstract": it only can exist as one of its sub-types, Audio Recording or Synthesized Audio.

Audio Recording

An Audio Recording is an Audio object that references an audio resource. It has the following properties:

One or more alternative Sources, each of which is either 1) a link to an external audio resource or 2) an embedded audio recording;
For each Source, one mandatory Type that specifies the type ([[MIME-TYPES]]) of the audio resource, for example audio/basic;
An optional Begin property and an optional End and an optional Duration property that together define the Audio Recording's time interval in the programme timeline, in relation to the parent element's time interval;
An optional In Time and an optional Out Time property that together define a temporal subsection of the audio resource;
The default In Time is the beginning of the audio resource.

The default Out Time is the end of the audio resource.

If the temporal subsection of the audio resource is longer than the duration of the Audio Recording's time interval, then playback MUST be truncated to end when the Audio Recording's time interval ends.

"Extended descriptions" (known in [[media-accessibility-reqs]] as "Extended video descriptions") are longer than the allocated time within the related media. A presentation processor that supports extended descriptions can allow the effective play rate of the audio resource to differ from the play rate of the related media object so that the resulting interval has a long enough duration to accommodate the audio resource's temporal subsection. For example it could pause or slow down playback of the related media object while continuing playback of the audio resource, or it could speed up playback of the audio resource, so that the Audio Recording's time interval does not end before the audio resource's temporal subsection. This behaviour is currently unspecified and therefore implementation-defined.

If the temporal subsection of the audio resource is shorter than the duration of the Audio Recording's time interval, then the audio resource plays once.
Zero or more Mixing Instructions that modify the playback characteristics of the Audio Recording.

When a list of Sources is provided, a presentation processor MUST play no more than one of the Sources for each Audio Recording.

Implementations can use the Type, and if present, any relevant additional formatting information, to decide which Source to play. For example, given two Sources, one being a WAV file, and the other an MP3, an implementation that can play only one of those formats, or is configured to have a preference for one or the other, would select the playable or preferred version.

An Audio Recording is represented in a DAPT Document by an <audio> element child of a <p> or <span> element corresponding to the Text to which it applies. The following constraints apply to the <audio> element:

The begin, end and dur attributes represent respectively the Begin, End and Duration properties;
The clipBegin and clipEnd attributes represent respectively the In Time and Out Time properties, as illustrated by ;
For each Source, if it is a link to an external audio resource, the Source and Type properties are represented by exactly one of:
1. A src attribute that is not a fragment identifier, and a type attribute respectively;
  This mechanism cannot be used if there is more than one Source.
```
                  
```
2. A <source> child element with a src attribute that is not a fragment identifier and a type attribute respectively;
```
                  
```
A src attribute that is not a fragment identifier is a URL that references an external audio resource, i.e. one that is not embedded within the DAPT Script. No validation that the resource can be located is specified in DAPT.

Do we need both mechanisms here? It's not clear what semantic advantage the child <source> element carries in this case. Consider marking use of that child <source> element as "at risk"?
If the Source is an embedded audio resource, the Source and Type properties are represented together by exactly one of:
1. A src attribute that is a fragment identifier that references either an <audio> element or a <data> element, where the referenced element is a child of /tt/head/resources and specifies a type attribute and the xml:id attribute used to reference it;
  This mechanism cannot be used if there is more than one Source.
```
                  
```
2. A <source> child element with a src attribute that is a fragment identifier that references either an <audio> element or a <data> element, where the referenced element is a child of /tt/head/resources and specifies a type attribute and the xml:id attribute used to reference it;
```
                  
```
3. A <source> child element with a <data> element child that specifies a type attribute and contains the audio recording data.
```
                  
```
In each of the cases above the type attribute represents the Type property.

A src attribute that is a fragment identifier is a pointer to an audio resource that is embedded within the DAPT Script

If <data> elements are defined, each one MUST contain either #PCDATA or <chunk> child elements and MUST NOT contain any <source> child elements.

<data> and <source> elements MAY contain a format attribute whose value implementations MAY use in addition to the type attribute value when selecting an appropriate audio resource.

Do we need all 3 mechanisms here? Do we need any? There may be a use case for embedding audio data, since it makes the single document a portable (though large) entity that can be exchanged and transferred with no concern for missing resources, and no need for e.g. manifest files. If we do not need to support referenced embedded audio then only the last option is needed, and is probably the simplest to implement. One case for referenced embedded audio is that it more easily allows reuse of the same audio in different document locations, though that seems like an unlikely requirement in this use case. Another is that it means that all embedded audio is in an easily located part of the document in tt/head/resources, which potentially could carry an implementation benefit? Consider marking the embedded data features as "at risk"?
Mixing Instructions MAY be applied as specified in their TTML representation;
The computed value of xml:lang MUST be identical to the computed value of xml:lang of the parent element and any child <source> elements and any referenced embedded <data> elements.

Synthesized Audio

A Synthesized Audio is an Audio object that represents a machine generated audio rendering of the parent Text content. It has the following properties:

A mandatory Rate that specifies the rate of speech, being normal, fast or slow;
An optional Pitch that allows adjustment of the pitch of the speech.

A Synthesized Audio is represented in a DAPT Document by the application of a tta:speak style attribute on the element representing the Text object to be spoken, where the computed value of the attribute is normal, fast or slow. This attribute also represents the Rate Property.

The tta:pitch style attribute represents the Pitch property.

The TTML representation of a Synthesized Audio is illustrated by .

A tta:pitch attribute on an element whose computed value of tta:rate is none has no effect. Such an element is not considered to have an associated Synthesized Audio.

Mixing Instruction

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 .

Constraints

Document Encoding

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 resulting [[xml]] document can contain character references, and entity references to predefined entities.

The predefined entities are (including the leading ampersand and trailing semicolon):

& for an ampersand & (unicode code point U+0026)
' for an apostrophe ' (unicode code point U+0027)
> for a greater than sign > (unicode code point U+003E)
< for a less than sign < (unicode code point U+003C)
" for a quote symbol " (unicode code point U+0022)

A DAPT Document can also be used as an in-memory model for processing, in which case the serialisation requirements do not apply.

Foreign Elements and Attributes

A DAPT Document MAY contain elements and attributes that are neither specifically permitted nor forbidden by a profile.

DAPT Documents remain subject to the content conformance requirements specified at Section 3.1 of [[TTML2]]. In particular, a DAPT Document can contain elements and attributes not in any TT namespace, i.e. in foreign namespaces, since such elements and attributes are pruned by the algorithm at Section 4 of [[TTML2]] prior to evaluating content conformance.

For validation purposes it is good practice to define and use a content specification for all foreign namespace elements and attributes used within a DAPT Document.

A transformation processor SHOULD preserve such elements or attributes whenever possible.

Do we need to say that a presentation processor may ignore foreign vocab?

Proprietary Metadata

Many dubbing and audio description workflows permit annotation of Script Events or documents with proprietary metadata. Metadata vocabulary defined in this specification or in [[TTML2]] MAY be included. Additional vocabulary in other namespaces MAY also be included.

It is possible to add information such as the title of the programme using [[TTML2]] constructs.

It is possible to add workflow-specific information using a foreign namespace. In the following example, a fictitious namespace vendorm from an "example vendor" is used to provide document-level information not defined by DAPT.

Namespaces

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

Name	Prefix	Value	Defining Specification
XML	`xml`	`http://www.w3.org/XML/1998/namespace`	[[xml-names]]
TT	`tt`	`http://www.w3.org/ns/ttml`	[[TTML2]]
TT Parameter	`ttp`	`http://www.w3.org/ns/ttml#parameter`	[[TTML2]]
TT Feature	none	`http://www.w3.org/ns/ttml/feature/`	[[TTML2]]
TT Audio Style	`tta`	`http://www.w3.org/ns/ttml#audio`	[[TTML2]]
DAPT Metadata	`daptm`	`http://www.w3.org/ns/ttml/profile/dapt#metadata`	This specification
DAPT Extension	none	`http://www.w3.org/ns/ttml/profile/dapt/extension/`	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 proposal document are mutable [[namespaceState]]; all undefined names in these namespaces are reserved for future standardization by the W3C.

Related Media Object (TTML)

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.

A DAPT document can identify the programme acting as the Related Media Object using metadata. For example, it is possible to use the <ebuttm:sourceMediaIdentifier> element defined in [[EBU-TT-3390]].

Synchronization

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 the context of this specification rendering could be visual presentation of text, for example to show an actor what words to speak, or could be audible playback of an audio resource, or could be physical or haptic, such as a Braille display.

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.

Profile Signaling

This section defines how a TTML Document Instance signals that it is a DAPT Document and how it signals any processing requirements that apply. See also , which defines how to establish that a DAPT Document conforms to this specification.

Profile Designator

This profile is associated with the following profile designators:

Profile Name	Profile Designator
DAPT 1.0 Content Profile	`http://www.w3.org/ns/ttml/profile/dapt1.0/content`
DAPT 1.0 Processor Profile	`http://www.w3.org/ns/ttml/profile/dapt1.0/processor`

`ttp:contentProfiles`

The ttp:contentProfiles attribute is used to declare the [[TTML2]] profiles to which the document conforms.

TTML documents representing DAPT Scripts MUST specify a ttp:contentProfiles attribute on the <tt> element including one value equal to the DAPT 1.0 Content Profile designator. Other values MAY be present to declare conformance to other profiles of [[TTML2]], and MAY include profile designators in proprietary namespaces.

`ttp:profile`

The ttp:profile attribute is a mechanism within [[?TTML1]] for declaring the processing requirements for a Document Instance. It has effectively been superceded in [[TTML2]] by ttp:processorProfiles.

TTML documents representing DAPT Scripts MUST NOT specify a ttp:profile attribute on the <tt> element.

`ttp:processorProfiles`

The ttp:processorProfiles attribute is used to declare the processing requirements for a Document Instance.

TTML documents representing DAPT Scripts MAY specify a ttp:processorProfiles attribute on the <tt> element. If present, the ttp:processorProfiles attribute MUST include one value equal to the designator of the DAPT 1.0 Processor Profile. Other values MAY be present to declare additional processing constraints, and MAY include profile designators in proprietary namespaces.

ttp:processorProfiles can be used to signal that features and extensions in additional profiles need to be supported to process the Document Instance successfully. For example, a local workflow might introduce particular metadata requirements, and signal that the processor needs to support those by using an additional processor profile designator.

If the content author does not need to signal that additional processor requirements than those defined by DAPT are needed to process the DAPT document then the ttp:processorProfiles is not expected to be present.

Other TTML2 Profile Vocabulary

[[TTML2]] specifies a vocabulary and semantics that can be used to define the set of features that a document instance can make use of, or that a processor needs to support, known as a Profile.

Except where specified, it is not a requirement of DAPT that this profile vocabulary is supported by processors; nevertheless such support is permitted.

The majority of this profile vocabulary is used to indicate how a processor can compute the set of features that it needs to support in order to process the Document Instance successfully. The vocabulary is itself defined in terms of TTML2 features. Those profile-related features are listed within as being optional. They MAY be implemented in processors and their associated vocabulary MAY be present in Document Instances.

Unless processor support for these features and vocabulary has been arranged (using an out-of-band protocol), the vocabulary is not expected to be present.

The additional profile-related vocabulary for which processor support is not required (but is permitted) in DAPT is:

the <ttp:profile> element;
the <ttp:feature> and <ttp:extension> elements;
the ttp:permitFeatureNarrowing attribute;
the ttp:permitFeatureWidening attribute;
the ttp:contentProfileCombination attribute;
the ttp:inferProcessorProfileSource attribute;
the ttp:processorProfileCombination attribute.

Timing constraints

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

`ttp:timeBase`

The only permitted ttp:timeBase value is media, since prohibits all timeBase features other than #timeBase-media.

This means that the beginning of the document timeline, i.e. time "zero", is the beginning of the Related Media Object.

`timeContainer`

The only permitted value of the timeContainer attribute is the default value, par.

Documents SHOULD omit the timeContainer attribute on all elements.

Documents MUST NOT set the timeContainer attribute to any value other than par on any element.

This means that the begin attribute value for every timed element is relative to the computed begin time of its parent element, or for the <body> element, to time zero.

`ttp:frameRate`

If the document contains any time expression that uses the f metric, or any time expression that contains a frames component, the ttp:frameRate attribute MUST be present on the <tt> element.

`ttp:tickRate`

If the document contains any time expression that uses the t metric, the ttp:tickRate attribute MUST be present on the <tt> element.

Time expressions

All time expressions within a document SHOULD use the same syntax, either clock-time or offset-time as defined in [[ttml2]], with DAPT constraints applied.

A DAPT clock-time has one of the forms:

hh:mm:ss.sss
hh:mm:ss

where hh is hours, mm is minutes, ss is seconds, and ss.sss is seconds with a decimal fraction of seconds (any precision).

Clock time expressions that use frame components, which look similar to "time code", are prohibited due to the semantic confusion that has been observed elsewhere when they are used, particularly with non-integer frame rates, "drop modes" and sub-frame rates.

An offset-time has one of the forms:

nn metric
nn.nn metric

where nn is an integer, nn.nn is a number with a decimal fraction (any precision), and metric is one of:

h for hours,
m for minutes,
s for seconds,
ms for milliseconds,
f for frames, and
t for ticks.

When mapping a media time expression M to a frame F of the video, e.g. for the purpose of accurately timing lip synchronization, the content processor SHOULD map M to the frame F with the presentation time that is the closest to, but not less, than M.

A media time expression of 00:00:05.1 corresponds to frame ceiling( 5.1 × ( 1000 / 1001 × 30) ) = 153 of a video that has a frame rate of 1000 / 1001 × 30 ≈ 29.97.

Layout

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

Layout of the paragraphs may rely on the default TTML region (i.e. if no <layout> element is used in the <head> element) or may be explicit by the use of the region attribute, to refer to a <region> element present at /tt/head/layout/region.

Profiles

This section defines a [[TTML2]] content profile and a processor profile by expressing dispositions against a set of features and extensions. The DAPT extensions are defined in .

The Profile Semantics specified in [[TTML2]] apply.

A TTML Profile specification is a document that lists all the features of TTML that are required / optional / prohibited within “document instances” (files) and “processors” (things that process the files), and any extensions or constraints.

A Document Instance that conforms to the content profile defined herein:

MUST satisfy all normative provisions specified by the profile;
MAY include any vocabulary, syntax or attribute value associated with a feature or extension whose disposition is permitted or optional in the profile;
MUST include any vocabulary, syntax or attribute value associated with a feature or extension whose disposition is required in the profile.
MUST NOT include any vocabulary, syntax or attribute value associated with a feature or extension whose disposition is prohibited in the profile.

A Document Instance, by definition, satisfies the requirements of Section 3.1 at [[TTML2]], and hence a Document Instance that conforms to a profile defined herein is also a conforming TTML2 Document Instance.

A Presentation processor that conforms to the processor profile defined in this specification:

MUST satisfy the Generic Processor Conformance requirements at Section 3.2.1 of [[TTML2]]
MUST satisfy all normative provisions specified by the profile; and
MUST implement presentation semantic support for every feature or extension designated as permitted or required by the profile, subject to any additional constraints on each feature as specified by the profile.
MAY implement presentation semantic support for every feature or extension designated as optional or prohibited by the profile, subject to any additional constraints on each feature as specified by the profile.

A Transformation processor that conforms to the processor profile defined in this specification:

MUST satisfy the Generic Processor Conformance requirements at Section 3.2.1 of [[TTML2]];
MUST satisfy all normative provisions specified by the profile; and
MUST implement transformation semantic support for every feature or extension designated as permitted or required by the profile, subject to any additional constraints on each feature as specified by the profile.
MAY implement transformation semantic support for every feature or extension designated as optional or prohibited by the profile, subject to any additional constraints on each feature as specified by the profile.

The dispositions required, permitted, optional and prohibited as used in this specification map to the [[TTML2]] <ttp:feature> and <ttp:extension> elements' value attribute values as follows:

DAPT disposition	`<ttp:feature>` or `<ttp:extension>` `value` attribute value in
DAPT disposition	content profile	processor profile
required	required	required
permitted	optional	required
optional	optional	optional
prohibited	prohibited	optional

The use of the terms presentation processor and transformation processor within this document does not imply conformance per se to any of the Standard Profiles defined in [[TTML2]]. In other words, it is not considered an error for a presentation processor or transformation processor to conform to the profile defined in this document without also conforming to the TTML2 Presentation Profile or the TTML2 Transformation Profile.

The use of the [[TTML2]] profiling sub-system to describe DAPT conformance within this specification is not intended imply that DAPT processors are required to support any features of that system other than those for which support is explicitly required by DAPT.

This document does not specify presentation processor or transformation processor behavior when processing or transforming a non-conformant Document Instance.

The permitted and prohibited dispositions do not refer to the specification of a <ttp:feature> or <ttp:extension> element as being permitted or prohibited within a <ttp:profile> element.

Disposition of Features and Extensions

The features and extensions listed in this section express the minimal requirements for DAPT Documents, Presentation Processors, and Transformation Processors. DAPT Documents MAY additionally conform to other profiles, and include syntax not prohibited by the DAPT content profile. Presentation Processors and Transformation Processors MAY support additional syntax and semantics relating to other profiles.

For example, a DAPT Script can include syntax permitted by the IMSC ([[TTML-IMSC1.2]]) profiles of [[TTML2]] to enhance the presentation of scripts to actors recording audio, or to add styling important for later usage in subtitle or caption creation.

Editorial task: go through this list of features and check the disposition of each. There should be no prohibited features that are permitted in IMSC.

Feature or Extension	Disposition	Additional provision
Relative to the TT Feature namespace
`#animate-minimal`	permitted
`#animate-fill`	permitted
`#animation-out-of-line`	prohibited	See .
`#audio`	permitted
`#audio-description`	permitted
`#audio-speech`	permitted
`#bidi`	permitted
`#bidi-version-2`	permitted
`#chunk`	permitted
`#clockMode`	prohibited
`#clockMode-gps`	prohibited
`#clockMode-local`	prohibited
`#clockMode-utc`	prohibited
`#content`	permitted
`#contentProfiles`	optional	See and .
`#contentProfiles-combined`	optional	See .
`#core`	permitted
`#data`	permitted
`#direction`	permitted
`#dropMode`	prohibited
`#dropMode-dropNTSC`	prohibited
`#dropMode-dropPAL`	prohibited
`#dropMode-nonDrop`	prohibited
`#embedded-audio`	permitted
`#embedded-data`	permitted
`#frameRate`	permitted	See [[[#ttp-framerate]]].
`#frameRateMultiplier`	permitted
`#gain`	permitted
`#markerMode`	prohibited
`#markerMode-continuous`	prohibited
`#markerMode-discontinuous`	prohibited
`#metadata`	permitted
`#metadata-item`	permitted
`#metadata-version-2`	permitted
`#pan`	permitted
`#permitFeatureNarrowing`	optional	See .
`#permitFeatureWidening`	optional	See .
`#pitch`	permitted
`#presentation-audio`	permitted
`#processorProfiles`	optional	See .
`#processorProfiles-combined`	optional	See .
`#profile`	partially permitted	See .
`#profile-full-version-2`	partially permitted	See .
`#profile-version-2`	partially permitted	See .
`#resources`	permitted
`#set`	permitted
`#set-fill`	permitted
`#set-multiple-styles`	permitted
`#source`	permitted
`#speak`	permitted
`#speech`	permitted
`#structure`	required
`#styling`	permitted
`#styling-chained`	permitted
`#styling-inheritance-content`	permitted
`#styling-inline`	permitted
`#styling-referential`	permitted
`#subFrameRate`	prohibited
`#tickRate`	permitted	See [[[#ttp-tickrate]]].
`#time-clock`	permitted
`#time-clock-with-frames`	prohibited
`#time-offset-with-frames`	permitted	See [[[#ttp-framerate]]].
`#time-offset-with-ticks`	permitted	See [[[#ttp-tickrate]]].
`#time-offset`	permitted
`#time-wall-clock`	prohibited
`#timeBase-clock`	prohibited
`#timeBase-media`	required	See [[[#ttp-timebase]]]. NOTE: [[TTML1]] specifies that the default timebase is `"media"` if `ttp:timeBase` is not specified on `<tt>`.
`#timeBase-smpte`	prohibited
`#timeContainer`	prohibited	See [[[#timecontainer]]].
`#timing`	permitted	See [[[#time-expressions]]].
`#transformation`	permitted	See constraints at #profile.
Relative to the DAPT Extension namespace
`#agent`	permitted	This is the profile expression of .
`#contentProfiles-root`	required	This is the profile expression of .
`#onScreen`	permitted	This is the profile expression of .
`#profile-root`	prohibited	This is the profile expression of .
`#scriptType-root`	required	This is the profile expression of .
`#serialization`	required	This is the profile expression of .
`#source-data`	prohibited	This is the profile expression of the prohibition of `<source>` child elements of `<data>` elements as specified in .
`#textLanguageSource`	required	This is the profile expression of as required at .
`#workflowType-root`	required	This is the profile expression of .
`#xmlId-div`	required	This is the profile expression of .
`#xmlLang-audio-nonMatching`	prohibited	This is the profile expression of the prohibition of `xml:lang` on `<audio>` having a different computed value to the parent element and descendant or referenced `<source>` and `<data>` elements, as specified in .
`#xmlLang-root`	required	This is the profile expression of .

DAPT Content Profile

The DAPT Content Profile expresses the conformance requirements of DAPT Scripts using the profile mechanism of [[TTML2]]. It can be used by a validating processor that supports the DAPT Processor Profile to validate a DAPT Document.

There is no requirement to include the DAPT Content Profile within a Document Instance.

DAPT Processor Profile

The DAPT Processor Profile expresses the processing requirements of DAPT Scripts using the profile mechanism of [[TTML2]]. A processor that supports the required features and extensions of the DAPT Processor Profile can, minimally, process all permitted features within a DAPT Document.

There is no requirement to include the DAPT Processor Profile within a Document Instance.

Extensions

General

The following sections define extension designations, expressed as relative URIs (fragment identifiers) relative to the DAPT Extension Namespace base URI. These extension designations are used in to describe the normative provisions of DAPT that are not expressed by [[TTML2]] profile features.

#agent

A transformation processor supports the #agent extension if it recognizes and is capable of transforming values of the following elements and attributes on the <ttm:agent> element:

xml:id attribute
<ttm:name> element

and if it recognizes and is capable of transforming each of the following value combinations:

<ttm:agent> element with type="person" and child <ttm:name> element with type="full";
<ttm:agent> element with type="character" and child <ttm:name> element with type="alias";

A presentation processor supports the #agent extension if it implements presentation semantic support of the above listed elements, attributes and value combinations.

#contentProfiles-root

A transformation processor supports the #contentProfiles-root extension if it recognizes and is capable of transforming values of the ttp:contentProfiles attribute on the <tt> element.

A presentation processor supports the #contentProfiles-root extension if it implements presentation semantic support of the ttp:contentProfiles attribute on the <tt> element.

This extension is defined as a subset of #contentProfiles to avoid requiring processor support for the ttp:profile attribute and processor profile inference semantics.

#onScreen

A transformation processor supports the #onScreen extension if it recognizes and is capable of transforming values of the daptm:onScreen attribute on the <div> element.

A presentation processor supports the #onScreen extension if it implements presentation semantic support of the daptm:onScreen attribute on the <div> element.

#profile-root

A transformation processor supports the #profile-root extension if it recognizes and is capable of transforming values of the ttp:profile attribute on the <tt> element.

A presentation processor supports the #profile-root extension if it implements presentation semantic support of the ttp:profile attribute on the <tt> element.

#scriptType-root

A transformation processor supports the #scriptType-root extension if it recognizes and is capable of transforming values of the daptm:scriptType attribute on the <tt> element.

A presentation processor supports the #scriptType-root extension if it implements presentation semantic support of the daptm:scriptType attribute on the <tt> element.

An example of a transformation processor that supports this extension is a validating processor that provides appropriate feedback, for example warnings, when the SHOULD requirements defined in for a DAPT Document's daptm:scriptType are not met, and that reports an error if the extension is required by a content profile but the Document Instance claiming conformance to that profile either does not have a daptm:scriptType attribute on the <tt> element or has one whose value is not defined herein.

#serialization

A serialized document that is valid with respect to the #serialization extension is an XML 1.0 [[xml]] document encoded using UTF-8 character encoding as specified in [[UNICODE]], that contains no entity declarations and no entity references other than to predefined entities.

A transformation processor or a presentation processor supports the #serialization extension if it can read a serialized document as defined above.

A transformation processor that writes documents supports the #serialization extension if it can write a serialized document as defined above.

#source-data

A transformation processor supports the #source-data extension if it recognizes and is capable of transforming values of the <source> element child of a <data> element.

A presentation processor supports the #source-data extension if it implements presentation semantic support of the <source> element child of a <data> element.

#textLanguageSource

A transformation processor supports the #textLanguageSource extension if it recognizes and is capable of transforming values of the daptm:langSrc attribute on the <p> element.

A presentation processor supports the #textLanguageSource extension if it implements presentation semantic support of the daptm:langSrc attribute on the <p> element.

#workflowType-root

A transformation processor supports the #workflowType-root extension if it recognizes and is capable of transforming values of the daptm:workflowType attribute on the <tt> element.

A presentation processor supports the #workflowType-root extension if it implements presentation semantic support of the daptm:workflowType attribute on the <tt> element.

An example of a transformation processor that supports this extension is a validating processor that reports an error if the extension is required by a content profile but the Document Instance claiming conformance to that profile either does not have a daptm:workflowType attribute on the <tt> element or has one whose value is not defined herein.

#xmlId-div

A transformation processor supports the #xmlId-div extension if it recognizes and is capable of transforming values of the xml:id attribute on the <div> element.

A presentation processor supports the #xmlId-div extension if it implements presentation semantic support of the xml:id attribute on the <div> element.

#xmlLang-audio-nonMatching

A transformation processor supports the #xmlLang-audio-nonMatching extension if it recognizes and is capable of transforming values of the xml:lang attribute on the <audio> element that differ from the computed value of the same attribute of its parent element or any of its descendant or referenced <source> or <data> elements, known as non-matching values.

A presentation processor supports the #xmlLang-audio-nonMatching extension if it implements presentation semantic support of such non-matching xml:lang attribute values.

#xmlLang-root

A transformation processor supports the #xmlLang-root extension if it recognizes and is capable of transforming values of the xml:lang attribute on the <tt> element.

A presentation processor supports the #xmlLang-root extension if it implements presentation semantic support of the xml:lang attribute on the <tt> element.