This specification defines DAPT, a TTML-based file format for the exchange of timed text content in dubbing and audio description workflows.
This document incorporates a registry section
and defines registry tables,
as defined in the [[w3c-process]] requirements for w3c registries.
Updates to the document that only change registry tables can be made
without meeting other requirements for Recommendation track updates,
as set out in Updating Registry Tables;
requirements for updating those registry tables are normatively specified
within .
The Working Group has identified the following
at risk features:
At risk features may be be removed before advancement to Proposed Recommendation.
Scope
This specification defines a text-based profile of the Timed Text Markup Language version 2.0 [[TTML2]]
intended to support dubbing and audio description workflows worldwide,
to meet the requirements defined in [[?DAPT-REQS]], and to permit usage of visual presentation
features within [[TTML2]] and its profiles, for example those in [[TTML-IMSC1.2]].
Introduction
Transcripts and Scripts
In general usage, one meaning of the word script is
the written text of a film, television programme, play etc.
A script can be either a record of the completed production,
also known as a transcript,
or as a plan for a yet to be created production.
In this document, we use domain-specific terms, and define more specifically that:
a transcript is the text representation of pre-existing media in another form,
for example the dialogue in a video;
a script is a text representation of the intended content of media prior to its creation,
for example to guide an actor in recording an audio track.
The term DAPT script is used generically to refer to both transcripts and scripts,
and is a point of conformance to the formal requirements of this specification.
DAPT Scripts consist of timed text and associated metadata,
such as the character speaking.
In dubbing workflows, a transcript is generated and translated to create a script.
In audio description workflows, a transcript describes the video image,
and is then used directly as a script for recording an audio equivalent.
DAPT is a TTML-based format for the exchange of transcripts and scripts
(i.e. DAPT Scripts)
among authoring, prompting and playback tools in the localization and audio description pipelines.
A DAPT document is a serializable form of a DAPT Script designed to carry pertinent information for dubbing or audio description
such as type of DAPT script, dialogue, descriptions, timing, metadata, original language transcribed text, translated text, language information, and audio mixing instructions,
and to be extensible to allow user-defined annotations or additional future features.
This specification defines the data model for DAPT scripts and
its representation as a [[TTML2]] document (see [[[#data-model]]])
with some constraints and restrictions (see [[[#profile-constraints]]]).
A DAPT script is expected to be used to make audio visual media accessible
or localized for users who cannot understand it in its original form,
and to be used as part of the solution for meeting user needs
involving transcripts, including accessibility needs described in [[media-accessibility-reqs]],
as well as supporting users who need dialogue translated into a different language via dubbing.
Every part of the DAPT script content is required
to be marked up with some indication of what it represents in the related media,
via the Represents property; likewise the DAPT Script as a whole
is required to list all the types of content that it represents,
for example if it represents audio content or visual content,
and if visual, then if it represents text or non-text etc.
A registry of hierarchical content descriptors is provided.
The authoring workflow for both dubbing and audio description involves similar stages,
that share common requirements as described in [[DAPT-REQS]].
In both cases, the author reviews the content and
writes down what is happening, either in the dialogue or in the video image,
alongside the time when it happens.
Further transformation processes can change the text to a different language and
adjust the wording to fit precise timing constraints.
Then there is a stage in which an audio rendering of the script is generated,
for eventual mixing into the programme audio.
That mixing can occur prior to distribution,
or in the player directly.
The dubbing process which consists in creating a dubbing script
is a complex, multi-step process involving:
Transcribing and timing the dialogue in its own language from a completed programme to create a transcript;
Notating dialogue with character information and other annotations;
Generating localization notes to guide further adaptation;
Translating the dialogue to a target language script;
Adapting the translation to the dubbing;
for example matching the actor’s lip movements in the case of dubs.
A dubbing script is a transcript or script
(depending on workflow stage) used for
recording translated dialogue to be mixed with the non-dialogue programme audio,
to generate a localized version of the programme in a different language,
known as a dubbed version, or dub for short.
Dubbing scripts can be useful as a starting point for creation of subtitles or closed captions in alternate languages.
This specification is designed to facilitate the addition of, and conversion to,
subtitle and caption documents in other profiles of TTML, such as [[TTML-IMSC1.2]],
for example by permitting subtitle styling syntax to be carried in DAPT documents.
Alternatively, styling can be applied to assist voice artists when recording scripted dialogue.
Creating audio description content is also a multi-stage process.
An audio description,
also known as video description
or in [[media-accessibility-reqs]] as described video,
is an audio service
to assist viewers who can not fully see a visual presentation to understand the content.
It is the result of mixing the main programme audio with the audio rendition of each description,
authored to be timed when it does not clash with dialogue,
to deliver an audio description mixed audio track.
Main programme audio refers to the audio associated with the programme prior to any further mixing.
A description is a set of words that describes an aspect of the programme presentation,
suitable for rendering into audio by means of vocalisation and recording
or used as a text alternative source for text to speech translation, as defined in [[WCAG22]].
More information about what audio description is and how it works can be found at [[BBC-WHP051]].
Writing the audio description script typically involves:
watching the video content of the programme,
or series of programmes,
identifying the key moments during which there is an opportunity to speak descriptions,
writing the description text to explain the important visible parts of the programme at that time,
creating an audio version of the descriptions, either by recording a human actor or using text to speech,
defining mixing instructions (applied using [[TTML2]] audio styling) for combining the audio with the programme audio.
The audio mixing can occur prior to distribution of the media,
or in the client.
If the audio descriptionscript is delivered to the player,
the text can be used to provide an alternative rendering,
for example on a Braille display,
or using the user's configured screen reader.
an accessible transcript presented alongside audio or video in a web page or application;
in this usage, the timings could be retained and used for synchronisation with,
or navigation within, the media
or discarded to present a plain text version of the entire timeline.
Example documents
Basic document structure
The top level structure of a document is as follows:
The <tt> root element in the namespace http://www.w3.org/ns/ttml indicates that this is a TTML document
and the ttp:contentProfiles attribute indicates that it adheres to the DAPT content profile defined in this specification.
The daptm:scriptRepresents attribute indicates what the contents of the document are an alternative for,
within the original programme.
The daptm:scriptType attribute indicates the type of transcript or script
but in this empty example, it is not relevant, since only the structure of the document is shown.
The daptm:langSrc attribute indicates the default text language source,
for example the original language of the content,
while the xml:lang attribute indicates the default language
in this script, which in this case is the same.
Both of these attributes are inherited and can be overridden within the content of the document.
The following examples correspond to the timed text transcripts and scripts produced
at each stage of the workflow described in [[DAPT-REQS]].
The first example shows an early stage transcript in which timed opportunities for descriptions
or transcriptions have been identified but no text has been written;
the daptm:represents attribute present on the <body>
element here is inherited by the <div> elements since
they do not specify a different value:
The following examples will demonstrate different uses in dubbing and audio description workflows.
Audio Description Examples
When descriptions are added this becomes a Pre-Recording Script.
Note that in this case, to reflect that most of the audio description content
transcribes the video image where there is no inherent language,
the Text Language Source, represented by the daptm:langSrc attribute,
is set to the empty string at the top level of the document.
It would be semantically equivalent to omit the attribute altogether,
since the default value is the empty string:
After creating audio recordings, if not using text to speech, instructions for playback
mixing can be inserted. For example, The gain of "received" audio can be changed before mixing in
the audio played from inside the <span> element, smoothly
animating the value on the way in and returning it on the way out:
At the document level, the daptm:scriptRepresents attribute indicates
that the document represents both visual text and visual non-text content in the
related media.
It is possible that there are no Script Events that actually represent visual text,
for example because there is no text in the video image.
In the above example, the <div> element's
begin attribute defines the time that is the "syncbase" for its child,
so the times on the <animate> and <span>
elements are relative to 25s here.
The first <animate> element drops the gain from 1
to 0.39 over 0.3s, freezing that value after it ends,
and the second one raises it back in the
final 0.3s of this description. Then the <span> element is
timed to begin only after the first audio dip has finished.
If the audio recording is long and just a snippet needs to be played,
that can be done using clipBegin and clipEnd.
If we just want to play the part of the audio from file from 5s to
8s it would look like:
Or audio attributes can be added to trigger the text to be spoken:
It is also possible to embed the audio directly,
so that a single document contains the script and
recorded audio together:
Dubbing Examples
From the basic structure of ,
transcribing the audio produces an original language dubbing transcript,
which can look as follows.
No specific style or layout is defined, and here the focus is on the transcription of the dialogue.
Characters are identified within the <metadata> element.
Note that the language and the text language source are defined using
xml:lang and daptm:langSrc attributes respectively,
which have the same value
because the transcript is not translated.
After translating the text, the document is modified. It includes translation text, and
in this case the original text is preserved. The main document's default language is changed to indicate
that the focus is on the translated language.
The combination of the xml:lang and daptm:langSrc attributes are used
to mark the text as being original or translated.
In this case, they are present on both the <tt> and <p>
elements to make the example easier to read, but it would also be possible to omit
them in some cases, making use of the inheritance model:
The process of adaptation, before recording, could adjust the wording and/or add further timing to assist in the recording.
The daptm:scriptType attribute is also modified, as in the following example:
Documentation Conventions
This document uses the following conventions:
When referring to an [[XML]] element in the prose,
angled brackets and a specific style are used as follows: <someElement>.
The entity is also described as an element in the prose.
If the name of an element referenced in this specification
is not namespace qualified, then the TT namespace applies (see Namespaces).
When referring to an [[XML]] attribute in the prose,
the attribute name is given with its prefix,
if its namespace has a value,
or without a prefix if its namespace has no value.
Attributes with prefixes are styled as attributePrefix:attributeName
and those without prefixes are styled as attributeName.
The entity is also described as an attribute in the prose.
When defining new [[XML]] attributes, this specification uses the conventions used for
"value syntax expressions" in [[TTML2]]. For example, the following would define a new attribute
called daptm:foo as a string with two possible values:
bar and baz.
daptm:foo
: "bar"
| "baz"
When referring to the position of an element or attribute in the [[XML]] document,
the [[XPath]] LocationPath notation is used.
For example, to refer to the first <metadata> element child of
the <head> element child of
the <tt> element,
the following path would be used:
/tt/head/metadata[0].
Registry sections that include registry table data are indicated as follows:
Content in registry table sections has different requirements
for updates than other Recommendation track content,
as defined in [[w3c-process]].
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]].
(Informative) Class diagram showing main entities in the DAPT data model.
The Script Represents property is a mandatory property of a DAPT Script which
indicates which components of the related media object
the contents of the document represent.
The contents of the document could be used as part of a mechanism
to provide an accessible alternative for those components.
Script Events have a related property, Represents,
and there are constraints about the permitted values of that property that
are dependent on the values of Script Represents.
To represent this property, the daptm:scriptRepresents attribute
MUST be present on the <tt> element,
with a value conforming to the following syntax:
daptm:scriptRepresents
: <content-descriptor> ( <lwsp>+ <content-descriptor>)*
<lwsp> # as TTML2
Default Language
The Default 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 one of the original languages 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 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 Default Language can correspond to the language of the majority of Script Events,
to the language being spoken for the longest duration, or to a language arbitrarily chosen by the author.
The definitions of the types of documents and the corresponding daptm:scriptType attribute values are:
Original Language Transcript:
When the daptm:scriptType attribute value is originalTranscript,
the document is a literal transcription of the dialogue and/or on-screen text in their inherent spoken/written language(s),
or of non-dialogue sounds and non-linguistic visual content.
When the daptm:scriptType attribute value is translatedTranscript,
the document represents a translation of the Original Language Transcript in a common language.
When the daptm:scriptType attribute 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.
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.
If any Script Events are present, the DAPT Document MUST have
one <body> element child of the <tt> element.
If any Character objects are present, the DAPT Document MUST have
one <head> element child of the <tt> element,
and that <head> element MUST have
at least one <metadata> element child.
recommends that
all the Character objects be located within
a single <metadata> element parent,
and in the case that there are more than one
<metadata> element children of
the <head> element,
that the Character objects are located in the first such child.
Shared properties and Value Sets
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.
Some of the value sets in DAPT are reused across more than one property,
and have the same constraints everywhere they occur.
These shared value sets are also 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,
as defined by [[TTML2]].
If any of the timing properties is omitted, the following rules apply,
paraphrasing the timing semantics defined in [[TTML2]]:
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 default value for Duration is indefinite,
i.e. the end time resolves to the same as the end time of the parent object.
The values permitted in the Script Represents and Represents properties depend on the
<content-descriptor> syntactic definition
and its associated registry table.
<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
<content-descriptor> has values that are delimiter separated ordered lists
of tokens.
A <content-descriptor> value B is a content descriptor sub-type
of another <content-descriptor> value A if A's ordered list of descriptor-tokens is
present at the beginning of B's ordered list of descriptor-tokens.
Valid user-defined values MUST begin with x- or be sub-types of
values in the content-descriptor registry table, where the
first additional <descriptor-token> component begins with x-.
Indicates that the DAPT content represents any part of the audio programme.
Dubbing, translation and hard of hearing subtitles and captions, pre- and post- production scripts
audio.dialogue
Provisional
Indicates that the DAPT content represents verbal communication in the audio programme,
for example, a spoken conversation.
Dubbing, translation and hard of hearing subtitles and captions, pre- and post- production scripts
audio.nonDialogueSounds
Provisional
Indicates that the DAPT content represents a part of
the audio programme corresponding to sounds that are not verbal communication,
for example, significant sounds, such as a door being slammed in anger.
Translation and hard of hearing subtitles and captions, pre- and post- production scripts
visual
Provisional
Indicates that the DAPT content represents any part of the visual image of the programme.
Audio Description
visual.dialogue
Provisional
Indicates that the DAPT content represents verbal communication,
within the visual image of the programme,
for example, a signed conversation.
Dubbing or Audio Description, translation and hard of hearing subtitles and captions, pre- and post- production scripts
visual.nonText
Provisional
Indicates that the DAPT content represents non-textual
parts of the visual image of the programme,
for example, a significant object in the scene.
Audio Description
visual.text
Provisional
Indicates that the DAPT content represents textual
content in the visual image of the programme,
for example, a signpost, a clock, a newspaper headline, an instant message etc.
Audio Description
visual.text.title
Provisional
A sub-type of visual.text where the text is the title of the related media.
Audio Description
visual.text.credit
Provisional
A sub-type of visual.text where the text is a credit, e.g. the name of an actor.
Audio Description
visual.text.location
Provisional
A sub-type of visual.text where the text indicates the location where the content is occurring.
Audio Description
Character
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 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.
The requirement for an additional <ttm:agent> element
corresponding to the Talent Name is defined in the following bullet list.
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.
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.
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.
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.
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.
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.
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.
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:
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]].
The <p> element SHOULD have an xml:lang attribute
corresponding to the language of the Text object.
<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>
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.
<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.
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 the source language of
a Text object, if applicable, or that the source content had no inherent language:
If it is empty, the Text represents content without an inherent language,
such as untranslated descriptions of a visual scene or
captions representing non-dialogue sounds.
Otherwise (if it is not empty):
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.
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
: <empty-string> | <language-identifier>
<empty-string>
: "" # default
<language-identifier> # valid BCP-47 language tag
The value MUST be an empty string or a language identifier as defined by [[BCP47]].
The default value is the empty string.
It applies to <p> and <span> elements.
It MAY be specified on the following elements: <tt>, <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.
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 the empty string then it indicates
that the Text is Original
and sourced from content without an inherent language.
Otherwise (the computed value is not empty)
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 ScreenScript Event property may be present:
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.
Since there is no empty <content-descriptor>,
this implies that an empty computed Represents
property can never be valid; one way to construct
a valid DAPT Document is to specify a Represents
property on the DAPT Script so that it is
inherited by all descendants that do not have a 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.
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 specify its language
using the xml:lang attribute.
Each Script Event Description can be annotated with
one or more Description Types
to categorise further the purpose of the Script Event Description.
The <ttm:desc> element MAY have zero or one daptm:descType attributes.
The daptm:descType attribute is defined below.
daptm:descType : string
Its permitted values are listed in the following registry table:
Registry table for the daptm:descType attribute
whose Registry Definition is at
daptm:descType
Status
Description
Notes
pronunciationNote
Provisional
Notes for how to pronounce the content.
scene
Provisional
Contains a scene identifier
plotSignificance
Provisional
Defines a measure of how significant the content is to the plot.
Contents are undefined and may be low, medium or high, or a numerical scale.
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.
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.
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.
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.
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:
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.
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:
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.
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;
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"?
The computed value of the xml:lang attribute MUST be identical
to the computed value of the xml:lang attribute 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.
A tta:pitch attribute on an element
whose computed value of the tta:rate attribute is none
has no effect.
Such an element is not considered to have an associated Synthesized Audio.
The semantics of the Synthesized Audio vocabulary of DAPT are derived from equivalent features in [[SSML]] as indicated in [[TTML2]]. This version
of the specification does not specify how other features of [[SSML]] can be either generated from DAPT or embedded
into DAPT documents. The option to extend [[SSML]] support in future versions of this specification is deliberately left open.
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 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.
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.
Processing of unrecognised or foreign elements and attributes
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.
Unrecognised vocabulary
Unrecognised vocabulary is the set of elements and attributes that are
not associated with features that the processor supports.
The above constraint is specified as being after attribute value computation because it is possible
that an implementation recognises and supports attributes present only on particular elements,
for example those corresponding to the DAPT data model.
As described in it is important that processor implementations
do not ignore such attributes when present on other elements.
Special considerations for foreign vocabulary
Foreign vocabulary is the subset of unrecognised vocabulary that consists of
those elements and attributes whose namespace
is not one of the namespaces listed in and
those attributes whose namespace has no value that are not otherwise defined in DAPT or in [[TTML2]].
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.
Foreign vocabulary MAY also be included,
either as attributes of <metadata> elements or
as descendant elements of <metadata> elements.
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.
It is strongly recommended not to place data
whose semantics depend on the contents of the document
within <metadata> elements.
Such data can be invalidated by transformation processors that
modify the contents of the document but preserve metadata
while being unaware of their semantics.
Defining and using foreign vocabulary that is not metadata
If foreign vocabulary is included in locations other than <metadata> elements
it will be pruned by transformation processors that do not support features associated with that vocabulary,
as required in .
A mechanism is provided to prevent such pruning, and to define semantics for such foreign vocabulary,
allowing it to be located outside a <metadata> element without being pruned,
and to indicate content and processor conformance:
Define a profile including a feature definition for that semantic and vocabulary,
with a profile designator.
Signal document conformance to that profile using the
This allows processors that support the feature to process the vocabulary
in whatever way is appropriate, to avoid pruning it,
and allows processors that do not support the feature to take
appropriate action, for example warning users that some functionality may be lost.
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
EBU-TT Metadata
ebuttm
urn:ebu:tt:metadata
[[EBU-TT-3390]]
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.
Related Media Object
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 Designators
This profile is associated with the following profile designators:
The ttp:contentProfiles attribute
is used to declare the [[TTML2]] profiles to which the document conforms.
DAPT Documents MUST specify a ttp:contentProfiles attribute
on the <tt> element including at least one value equal to a
content profile designator specified at .
Other values MAY be present to declare conformance to other profiles of [[TTML2]],
and MAY include profile designators in proprietary namespaces.
Transformation processors MUST NOT include values within the
ttp:contentProfiles attribute
associated with profiles that they (the processors) do not support;
by definition they cannot verify conformance of the content to those profiles.
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.
DAPT Documents 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.
DAPT Documents MAY specify a ttp:processorProfiles attribute
on the <tt> element.
If present, the ttp:processorProfiles attribute MUST include at least one value equal to a
processor profile designator specified at .
Other values MAY be present to declare additional processing constraints,
and MAY include profile designators in proprietary namespaces.
The ttp:processorProfiles attribute 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 attribute 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 DAPT Documents.
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:
Within a DAPT Script, the following constraints apply in relation to time attributes and time expressions:
ttp:timeBase
The only permitted ttp:timeBase attribute 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 and styles
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.
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].
Bidirectional text
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>
More guidance about usage of this mechanism is available at .
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.
The following example taken from [[TTML2]] demonstrates the syntax for bidirectional text markup within
the <p> and <span> elements.
An example rendering of the above fragment is shown below.
Mapping from TTML to the DAPT Data Model
defines how objects and properties of the DAPT data model are represented in [[TTML2]], i.e. in a DAPT Document.
However, a DAPT data model instance can be represented by multiple [[TTML2]] document instances.
For example, does not mandate that a <div> element representing a Script Event be
a direct child of the <body> element.
That <div> element could be nested in another <div> element.
Therefore, it is possible to serialize the objects and properties of a DAPT Script into various DAPT Documents.
This section defines how to interoperably and unambiguously reconstruct a DAPT model instance from a DAPT Document.
DAPT does not define a complete serialization of the DAPT data model for extensibility reasons,
to allow future versions to do so if needed.
Additionally, a DAPT Document can contain elements or attributes that
are not mentioned in the representations of DAPT objects or properties.
This could be because it has been generated by a processor conformant to some future version of DAPT,
or through a generic [[TTML2]] process,
or because it uses optional features, for example to add styling or layout.
This section defines how to process those elements or attributes.
It is also possible to process DAPT Documents using generic [[TTML2]] processors,
which do not necessarily map the documents to the DAPT data model.
For example a generic TTML2 presentation processor could render an audio mix
based on a DAPT document without needing to model Script Events per se.
In that case, this section can be ignored.
Early identification of non-conformant documents
Normative provisions relating to this section are defined in [[TTML2]].
Since it is a requirement of DAPT that DAPT Documents include a
ttp:contentProfiles attribute on the root element,
and that the attribute includes a DAPT content profile designator,
as specified at ,
it follows that any TTML document that does not include such an attribute,
or does not include such a profile designator,
can be considered not to be a DAPT Document;
therefore a processor requiring strict adherence to DAPT could stop processing
such a document.
Not supporting features excluded by the content profile
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.
Handling <div> and <p> elements
[[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.
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;
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;
Any remaining unmapped <div> elements MUST NOT be mapped to a Script Event.
A <p> element that is a child of a <div> element
that maps to a Script Event MUST be mapped to a Text object.
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.
Future versions of DAPT could include features that use these
structural possibilities differently,
and therefore define other processing rules that are mutually exclusive
with the rules defined here.
Using computed attribute values
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.
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 EventBegin 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 instancebefore
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.
Considerations for transformation and validation processors
Retaining unrecognised vocabulary
As per ,
implementers of DAPT processors are encouraged to maintain unrecognised vocabulary
within <metadata> elements in DAPT Documents.
In practice it is possible that an implementation which both inputs DAPT documents
and outputs DAPT documents might modify the input
document structure and contents, and while doing so,
effectively prune those entities with unrecognised vocabulary from the output document.
Validation warnings and errors
Normative provisions relating to this section are defined in [[TTML2]].
[[TTML2]] defines a validation processor,
a class of implementation whose purpose is
to assess a document instance and decide if it is valid or not.
Typically this would be used within a processing workflow
to check that documents are acceptable for onward usage.
A real world example would likely not return simply "good" or "bad",
but also output informational, warning and error messages
describing unusual, unexpected or problematic contents in the input document.
When implementing a validation processor for a DAPT document,
strict [[TTML2]] validation processing rules can be applied.
Doing this involves checking for the presence and semantic validity of
syntax and content associated with required or optional features defined in the
profile, and checking for the absence of syntax associated with prohibited features.
The [[TTML2]] mechanism for dealing with vocabulary in unrecognised namespaces is
to prune it prior to validation.
This approach can be used; additionally it could be reasonable for
an implementation to report as information those attributes and elements
that have been pruned.
The term "vocabulary" here refers to XML elements and attributes.
Validation warnings could be issued when unsupported or deprecated
vocabulary in recognised namespaces is encountered after pruning,
or when supported vocabulary contains unexpected but not invalid content,
but in these scenarios errors are not expected.
Validation errors are expected when prohibited vocabulary is present,
or when semantically invalid content within permitted vocabulary
is encountered.
[[TTML2]] specifies a formal language for expressing document and processor requirements,
within the Profiling sub-system.
The normative requirements of this specification are defined using the conformance terminology
described above, and are also defined using this TTML2 profile mechanism.
Where TTML2 vocabulary is referenced, the syntactic and semantic requirements relating to that
vocabulary as defined in [[TTML2]] apply.
Whilst there is no requirement for a DAPT processor to implement the
TTML2 profile processing semantics in general,
implementers can use the TTML2 profiles defined in
as a means of verifying that their implementations meet the normative requirements
of DAPT, for example as a checklist.
Conversely, a general purpose [[TTML2]] processor that does support the TTML2
profile processing semantics can use the TTML2 profiles defined in
directly to determine if it is capable of processing a DAPT document.
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 .
DAPT Documents remain subject to the content conformance requirements specified at Section 3.1 of [[TTML2]].
In particular, a DAPT Document can contain foreign vocabulary,
since such elements and attributes are pruned by the algorithm at Section 4 of [[TTML2]] prior to evaluating content conformance.
Conformance of DAPT Processors
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 .
Privacy Considerations
With the exception of the following, the privacy considerations of [[ttml2]] apply:
Appendix P.3 (Resource Fetching), where only the considerations relating to the <audio> element apply.
Appendix P.7 (Access to Processing State) does not apply, since no support for the condition attribute is required.
Appendix P.9 (Privacy of Preference) is extended to include the potential indication that the user has a need for audio description.
Personal Information
DAPT documents typically contain the names of characters or people who feature within the associated media,
either fictional or real.
In general this information would be present within the media itself or be public via other routes.
If there is sensitivity associated with their being known to people with access to
the DAPT documents in which their identity is contained,
then such access should be managed with appropriate confidentiality.
For example those documents could be available within a closed authoring environment and
edited to remove the sensitive information prior to distribution to a wider audience.
If this scenario arises, information security good practices within the closed environment should be applied,
such as encryption of the document "at rest" and when being moved,
access controlled by authentication platforms, etc.
Audio format preference
DAPT documents can reference a set of alternate external audio resources for the same fragment of audio,
where the processor is expected to select one of the alternatives based on features such as format support.
If this pattern is used, it is possible that the processor's choice of audio resource,
being exposed to the origin, reveals information about that processor, such as its preferred audio format.
Security Considerations
The security considerations of [[ttml2]] apply.
Timecode-related metadata
DAPT Documents express time as media time,
which assumes that there is a reference start time (zero) on a media
timeline, and a fixed playrate.
An alternative scheme that is used in some other script formats is to
synchronise media components using timecode,
that match time stamps that are applied,
for example to each frame of video.
Workflows that create DAPT documents from
such timecode-based non-DAPT script formats
need to map those timecode
values onto the DAPT document's timeline.
If this mapping is not correct, presentation of the
DAPT Document will not be synchronised with the related media object.
A reference timecode that matches a known
point on the DAPT document timeline can be used
to achieve correct synchronisation, for example
the timecode corresponding to the start of the programme,
which should match DAPT time zero.
In this scenario, if such a reference point is not known,
but timecodes corresponding to Script Events are known,
it is still possible to construct a DAPT Document,
albeit one whose synchronisation with the related media has not yet been resolved.
The optional DAPT Origin Timecode and
Start of Programme Timecode properties can be used to
identify when there is a possible synchronisation error,
and to resynchronise the document when all
the required information is known.
These properties are provided as metadata only and
are not intended to be used to perform direct synchronisation offsets
during presentation.
In particular, when the related media object uses timecode,
the presence of the timecode properties does not mean that
the player needs to relate these timecode values with
any timecode value embedded in the related media resource.
The optional DAPT Origin Timecode allows a timecode value to be declared
that corresponds to the zero point of the DAPT document timeline,
that is, the time of a hypothetical Script Event whose Begin is
zero seconds.
The properties can be used to provide timecodes from
the related media object or from any other script format used to produce the DAPT document,
and are informational.
However, when they are both provided and differ,
it is an indication that the DAPT document is not synchronized with
the related media object and that processing of the script event begins is needed.
To achieve synchronization, the following needs to be done:
The DAPT Origin Timecode object is represented in a DAPT Document by
a <daptm:daptOriginTimecode> element present at the path
/tt/head/metadata/daptm:daptOriginTimecode,
with the following constraints:
The character content of the element must conform to a clock-time
with a frames component, as defined in <time-expression>.
See also .
No mechanism is defined here for declaring a different frame rate for the DAPT Origin Timecode
than is used for other frame-based time expressions.
If the related media object contains a timecode for the video frame
synchronized to the origin of the DAPT document timeline,
the DAPT origin timecode is equal that timecode.
...
<head>
<metadata>
<daptm:daptOriginTimecode>10:01:20:12</daptm:daptOriginTimecode>
</metadata>
</head>
<body>
<div xml:id="se1" begin="0s" end="1.8s">
<!-- This script event was generated from a source whose begin timecode was 10:01:20:12 -->
</div>
</body>
...
Start of Programme Timecode
The optional Start of Programme Timecode allows a timecode value to be declared
that corresponds to the beginning of the related media object's programme content.
If both DAPT Origin Timecode and Start of Programme Timecode are present,
but their values are different, it is likely that the media times are not
synchronised with the Related Media Object, since this implies that
the equivalent time code to zero seconds in media time is not the start of the programme,
which is the requirement for correctly synchronised media time.
The Start of Programme Timecode object is represented in a DAPT Document by
a <ebuttm:documentStartOfProgramme> element present at the path
/tt/head/metadata/ebuttm:documentStartOfProgramme,
with the syntactic constraints as defined in [[EBU-TT-3390]].
...
<head>
<metadata>
<daptm:daptOriginTimecode>10:01:20:12</daptm:daptOriginTimecode>
<ebuttm:documentStartOfProgramme>10:00:00:00<ebuttm:documentStartOfProgramme>
<!-- It is likely that this document is 1 minute, 20 seconds and 12 frames too early,
compared to the related media -->
</metadata>
</head>
<body>
<div xml:id="se1" begin="0s" end="1.8s">
<!-- This script event was generated from a source whose begin timecode was 10:01:20:12 -->
</div>
</body>
...
Applying the Mixing Instructions can be implemented using [[webaudio]].
shows the flow of programme audio,
and how, when audio-generating elements are active,
the pan and gain (if set) on the Script Event are applied,
then the output is passed to the Text,
which mixes in the audio from any active Audio Recording,
itself subject to its own Mixing Instructions,
then the result has the Text's Mixing Instructions
applied, prior to the output being mixed on to the master bus.
Example simple audio routing between objects
This example is shown as [[webaudio]] nodes in .
Web audio nodes representing the audio processing needed.
The above examples are simplified in at least two ways:
if a Text contains
<span> elements that themselves have Mixing Instructions
applied, then additional nodes would be needed;
the application of animatedMixing Instructions is not
shown explicitly. [[webaudio]] supports the timed variation of
input parameters to its nodes: it is possible to translate the
TTML <animate> element semantics directly into
[[webaudio]] API calls to achieve the equivalent effect.
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 timed text content 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 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:
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.
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.
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
the ttp:timeBase attribute is not specified on the <tt> element.
This is the profile expression of the prohibition of the xml:lang attribute
on the <audio> element having a different computed value to the
parent element and descendant or referenced <source>
and <data> elements, as specified in
.
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 DAPT Document.
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 DAPT Document.
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.
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.
An example of a transformation processor that supports this extension is
a validating processor that reports an error if the extension is permitted by a
content profile but the timed text content document instance claiming
conformance to that profile has a
<div> element with a daptm:represents attribute
whose value is not conformant with the requirements defined herein.
#scriptEventGrouping
A transformation processor supports the #scriptEventGrouping extension if
it recognises and is capable of transforming <div> elements
that contain <div> elements.
Support for the #scriptEventGrouping extension does not imply
support for the #scriptEventMapping extension.
A presentation processor supports the #scriptEventGrouping extension if
it implements presentation semantic support for <div> elements
that contain <div> elements.
#scriptEventMapping
A transformation processor supports the #scriptEventMapping extension
if, when mapping a DAPT document into an internal representation of the DAPT data model,
it implements the processing requirements specified at .
No support for the #scriptEventMapping extension is
required for presentation processors because there are no presentation semantics that
either require, or depend upon, mapping a DAPT document into an internal representation
of the DAPT data model. A presentation processor that does perform such a mapping can also be
considered to be a transformation processor for the purpose of this extension.
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 timed text content document instance claiming
conformance to that profile either does not have a
daptm:scriptRepresents attribute on the <tt> element
or has one whose value is not conformant with the requirements defined herein.
#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 timed text content 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 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.
A presentation processor supports the #textLanguageSource extension if
it implements presentation semantic support of the
daptm:langSrc attribute.
#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-matchingxml: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
and the additional semantics specified in .
A presentation processor supports the #xmlLang-root extension if
it implements presentation semantic support of the
xml:lang attribute on the <tt> element
and the additional semantics specified in .
Registry Section
Registry Definition
This section specifies the registry definition, consisting of
the custodianship, change process and
the core requirements of the registry tables defined in this document.
Details of the requested changes for each registry entry;
The motivation for making the requested changes;
Any other supporting information, for example real world usage statistics;
The proposer of the change MAY open a pull request (or equivalent) on
the version control system, with that pull request
containing the proposed changes. If a pull request is opened then
a corresponding issue MUST also be opened and
the pull request MUST be linked to that issue.
If the change proposer did not open a pull request
on the version control system,
then assessment is paused until a TTWG member
has opened such a pull request,
which MUST represent the requested changes
and MUST be linked to a related issue.
The TTWG follows its Decision Policy to review
the proposal in the pull request.
At the end of the Decision Review Period
if a TTWG Chair declares that there is consensus to approve,
the change request is approved.
In the absence of consensus to approve the expectation is
that a discussion will happen, to include the
change requester.
The result of this discussion can be any one of:
if the discussion resolves the objections,
and a TTWG Chair declares consensus to approve,
the change request can be approved.
An approved change request is enacted by merging its
related pull request into the version control system
and publishing the updated version of this document.
Custodian is the W3C Team
If the custodian is the W3C Team,
the Team MUST seek wide review of the change request and
offer a review period of at least 4 weeks,
before assessing from the responses received
if there is consensus amongst the respondents.
The Team MAY require a pull request on the version control system
to be opened as the basis of the review.
If there is such consensus,
the Team MUST make the proposed changes.
Registry Table Constraints
This section defines constraints on the registry tables
defined in this document.
Each registry table consists of a set of
registry entries.
Each registry table has an associated registry table definition in ,
which lists the fields present in each registry entry.
Registry Entries
Each registry entry has a status, a unique key, and
if appropriate, other fields, for example any notes,
a description, or a reference to some other
defining entity.
The registry table for <content-descriptor> defines a set of values that can be
used in the daptm:represents attribute.
The key is the "<content-descriptor>" field.
The "Description" field describes the type of media content represented by each value.
The "Example usage" field describes the type of script in which the content type
described are commonly found.
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.
