Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and document use rules apply.
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
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 G. Registry Section.
The Working Group has identified the following at risk features:
Possible resolution to #113.
Possible resolution to #113.
Possible resolution to #114 and #115.
The link to #115 is that this implies the existence of some referenceable embedded audio resource too, which one of the options described in #115.
Possible resolution to #114 and #115.
The link to #115 is that this implies the existence of some referenceable embedded audio resource too, which one of the options described in #115.
Possible resolution to #115.
Possible resolution to #117.
Possible resolution to #117.
At risk features may be be removed before advancement to Proposed Recommendation.
This document was published by the Timed Text Working Group as a Working Draft using the Recommendation track.
Publication as a Working Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Future updates to this specification may incorporate new features.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 03 November 2023 W3C Process Document.
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].
This section is non-normative.
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:
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 4. DAPT Data Model and corresponding TTML syntax) with some constraints and restrictions (see 5. 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.
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:
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:
The audio mixing can occur prior to distribution of the media, or in the client. If the audio description script 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.
DAPT Scripts can be useful in other workflows and scenarios. For example, Original language transcripts could be used as:
Both Original language transcripts and Translated transcripts could be used as:
The top level structure of a document is as follows:
<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.daptm:represents
attribute indicates what the contents of the document are an alternative for,
within the original programme.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.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 structure is applicable to all types of DAPT scripts, dubbing or audio description.
<tt xmlns="http://www.w3.org/ns/ttml"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
xmlns:daptm="http://www.w3.org/ns/ttml/profile/dapt#metadata"
ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/dapt1.0/content"
xml:lang="en"
daptm:langSrc="en"
daptm:represents="dialogue"
daptm:scriptType="originalTranscript">
<head>
<metadata>
<!-- Additional metadata may be placed here -->
<!-- Any characters must be defined here as a set of ttm:agent elements -->
</metadata>
<styling>
<!-- Styling is optional and consists of a set of style elements -->
</styling>
<layout>
<!-- Layout is optional and consists of a set of region elements -->
</layout>
</head>
<body>
<!-- Content goes here -->
</body>
</tt>
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:
...
<body>
<div xml:id="d1" begin="10s" end="13s">
</div>
<div xml:id="d2" begin="18s" end="20s">
</div>
</body>
...
The following examples will demonstrate different uses in dubbing and audio description workflows.
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
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:daptm:langSrc
<tt xmlns="http://www.w3.org/ns/ttml"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
xmlns:daptm="http://www.w3.org/ns/ttml/profile/dapt#metadata"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/dapt1.0/content"
xml:lang="en"
daptm:langSrc=""
daptm:represents="visualNonText, visualText"
daptm:scriptType="preRecording">
<body>
<div begin="10s" end="13s">
<p>
A woman climbs into a small sailing boat.
</p>
</div>
<div begin="18s" end="20s">
<p>
The woman pulls the tiller and the boat turns.
</p>
</div>
</body>
</tt>
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:
<tt ...
daptm:represents="visualNonText, visualText"
daptm:scriptType="asRecorded"
xml:lang="en"
daptm:langSrc="">
...
<div begin="25s" end="28s">
<p>
<animate begin="0.0s" end="0.3s" tta:gain="1;0.39" fill="freeze"/>
<animate begin="2.7s" end="3s" tta:gain="0.39;1"/>
<span begin="0.3s" end="2.7s">
<audio src="clip3.wav"/>
The sails billow in the wind.</span>
</p>
</div>
...
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:
...
<audio src="long_audio.wav" clipBegin="5s" clipEnd="8s"/>
A woman climbs into a small sailing boat.</span>
...
Or audio attributes can be added to trigger the text to be spoken:
...
<div begin="18s" end="20s">
<p>
<span tta:speak="normal">
The woman pulls the tiller and the boat turns.</span>
</p>
</div>
...
It is also possible to embed the audio directly, so that a single document contains the script and recorded audio together:
...
<div begin="25s" end="28s">
<p>
<animate begin="0.0s" end="0.3s" tta:gain="1;0.39" fill="freeze"/>
<animate begin="2.7s" end="3s" tta:gain="0.39;1"/>
<span begin="0.3s" end="2.7s">
<audio><source><data type="audio/wave">
[base64-encoded audio data]
</data></source></audio>
The sails billow in the wind.</span>
</p>
</div>
...
From the basic structure of Example 1,
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
attributes respectively,
which have the same value
because the transcript is not translated.daptm:langSrc
<tt xmlns="http://www.w3.org/ns/ttml"
xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
xmlns:daptm="http://www.w3.org/ns/ttml/profile/dapt#metadata"
ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/dapt1.0/content"
xml:lang="fr"
daptm:langSrc="fr"
daptm:represents="dialogue"
daptm:scriptType="originalTranscript">
<head>
<metadata>
<ttm:agent type="character" xml:id="character_1">
<ttm:name type="alias">ASSANE</ttm:name>
</ttm:agent>
</metadata>
</head>
<body>
<div begin="10s" end="13s">
<p ttm:agent="character_1">
<span>Et c'est grâce à ça qu'on va devenir riches.</span>
</p>
</div>
</body>
</tt>
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
attributes are used
to mark the text as being original or translated.
In this case, they are present on both the daptm:langSrc
<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:
<tt xmlns="http://www.w3.org/ns/ttml"
xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
xmlns:daptm="http://www.w3.org/ns/ttml/profile/dapt#metadata"
ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/dapt1.0/content"
xml:lang="en"
daptm:langSrc="fr"
daptm:represents="dialogue"
daptm:scriptType="translatedTranscript">
<head>
<metadata>
<ttm:agent type="character" xml:id="character_1">
<ttm:name type="alias">ASSANE</ttm:name>
</ttm:agent>
</metadata>
</head>
<body>
<div begin="10s" end="13s" ttm:agent="character_1">
<p xml:lang="fr" daptm:langSrc="fr"> <!-- original -->
<span>Et c'est grâce à ça qu'on va devenir riches.</span>
</p>
<p xml:lang="en" daptm:langSrc="fr"> <!-- translated -->
<span>And thanks to that, we're gonna get rich.</span>
</p>
</div>
</body>
</tt>
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:
<tt xmlns="http://www.w3.org/ns/ttml"
xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
xmlns:daptm="http://www.w3.org/ns/ttml/profile/dapt#metadata"
ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/dapt1.0/content"
xml:lang="en"
daptm:langSrc="fr"
daptm:represents="dialogue"
daptm:scriptType="preRecording">
<head>
<metadata>
<ttm:agent type="character" xml:id="character_1">
<ttm:name type="alias">ASSANE</ttm:name>
</ttm:agent>
</metadata>
</head>
<body>
<div begin="10s" end="13s" ttm:agent="character_1" daptm:onScreen="ON_OFF">
<p xml:lang="fr" daptm:langSrc="fr">
<span>Et c'est grâce à ça qu'on va devenir riches.</span>
</p>
<p xml:lang="en" daptm:langSrc="fr">
<span begin="0s">And thanks to that,</span><span begin="1.5s"> we're gonna get rich.</span>
</p>
</div>
</body>
</tt>
This document uses the following conventions:
<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).attributePrefix:attributeName
.
The entity is also described as an attribute in the prose.daptm:foo
as a string with two possible values:
bar
and baz
.
daptm:foo
: "bar"
| "baz"
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]
.
Content in registry table sections has different requirements for updates than other Recommendation track content, as defined in [w3c-process].
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.
Figure 1 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].
See also #115 - if we are going to support non-inline embedded audio resources, should we make an object for them and add it into the Data Model?
A DAPT Script is a transcript or script that corresponds to a document processed within an authoring workflow or processed by a client, and conforms to the constraints of this specification. It has properties and objects defined in the following sections: Represents, Script Type, Default Language, Text Language Source, Script Events and, for Dubbing Scripts, Characters.
A DAPT Document is a [TTML2] timed text content document instance representing a DAPT Script. A DAPT Document has the structure and constraints defined in this and the following sections.
A [TTML2] timed text content document instance has
a root <tt>
element
in the TT namespace.
The 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.
To represent this property, the daptm:represents
attribute MUST be present on the <tt>
element:
daptm:represents
: <content-descriptor> ( <lwsp>? "," <lwsp>? <content-descriptor>)*
<content-descriptor> # see registry table below
<lwsp> # as TTML2
The permitted values for <content-descriptor>
are listed in the following registry table:
<content-descriptor> |
Status | Description | Used in | Notes |
---|---|---|---|---|
dialogue |
Provisional | Verbal communication, in audio | Dubbing, translation and hard of hearing subtitles and captions, pre- and post- production scripts | For example, a spoken conversation. |
nonDialogueSounds |
Provisional | Sounds that are not verbal communication, in audio | Translation and hard of hearing subtitles and captions, pre- and post- production scripts | For example, significant sounds, such as a door being slammed in anger. |
visualNonText |
Provisional | Parts of the visual image that are not textual | Audio Description | For example, a significant object in the scene |
visualText |
Provisional | Textual parts of the visual image | Audio Description | For example, a signpost, a clock, a newspaper headline, an instant message etc. |
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 Default Language is represented in a DAPT Document by the following structure and constraints:
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 Script Type property is a mandatory property of a DAPT Script which describes the type of documents used in Dubbing and Audio Description workflows, among the following: Original Language Transcript, Translated Transcript, Pre-recording Script, As-recorded Script.
To represent this property, the daptm:scriptType
attribute MUST be present on the <tt>
element:
daptm:scriptType
: "originalTranscript"
| "translatedTranscript"
| "preRecording"
| "asRecorded"
The definitions of the types of documents and the corresponding daptm:scriptType
attribute values are:
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.
Script Events in this type of transcript SHOULD contain Original Text objects and SHOULD NOT contain Translation Text objects.
When the daptm:scriptType
attribute value is translatedTranscript
,
the document represents a translation of the Original Language Transcript in a common language.
It can be adapted to produce a Pre-Recording Script, and/or used as the basis for a further translation into the Target Recording Language.
Script Events in this type of transcript SHOULD contain Translation Text objects. They MAY also contain Original Text objects.
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.
Script Events in this type of script SHOULD contain Text objects in the Target Recording Language. They MAY also contain Original Text objects from the Original Language Transcript in the case that their language is not the Target Recording Language, for context, to assist further processing.
When the daptm:scriptType
attribute value is asRecorded
,
the document represents the actual audio recording.
Script Events in this type of script SHOULD contain Text objects in the Target Recording Language and MAY also contain Original Text objects from the Original Language Transcript or Translation Text objects in other languages for context and quality verification. They MAY also contain links to audio and mixing instructions for the purpose of producing an audio track incorporating the recordings.
The following example is orphaned - move to the top of the section, before the enumerated script types?
<tt daptm:scriptType="originalTranscript">
...
</tt>
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.
A DAPT Script MAY contain zero or more Character objects, each describing a character that can be referenced by a Script Event.
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.
It is good practice to locate all the Character objects within
a single <metadata>
element parent.
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 Character is represented in a DAPT Document by the following structure and constraints:
<ttm:agent>
element present at the path
/tt/head/metadata/ttm:agent
, with the following constraints:
type
attribute MUST be set to character
.xml:id
attribute MUST be present on the <ttm:agent>
element and set to the Character Identifier.<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.
...
<metadata>
<ttm:agent type="character" xml:id="character_1">
<ttm:name type="alias">DESK CLERK</ttm:name>
</ttm:agent>
</metadata>
...
...
<metadata>
<ttm:agent type="person" xml:id="actor_A">
<ttm:name type="full">Matthias Schoenaerts</ttm:name>
</ttm:agent>
<ttm:agent type="character" xml:id="character_2">
<ttm:name type="alias">BOOKER</ttm:name>
<ttm:actor agent="actor_A"/>
</ttm:agent>
</metadata>
...
<ttm:agent>
element corresponding to the Talent Name
MUST be present at the path
/tt/head/metadata/ttm:agent
, with the following constraints:
type
attribute MUST be set to person
xml:id
attribute MUST be set.<ttm:name>
child element whose
type
MUST be set to full
and its content set to the Talent Name<ttm:agent>
element corresponding to that Talent Name,
referenced separately by each of the Characters.<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.<ttm:agent>
elements SHOULD be contained in the first <metadata>
element in the <head>
element.
<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.We should define our own classes of conformant implementation types, to avoid using the generic "presentation processor" or "transformation processor" ones. We could link to them.
At the moment, I can think of the following classes:
A Script Event object represents dialogue, on screen text or audio descriptions to be spoken and has the following properties:
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.
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.
In a transcript, when the event corresponds to in-image content, for example an audio description, no Character Identifier is needed. However it may be helpful in a Pre-recording Script or an As-recorded Script context to indicate a Character signifying who voices the recording.
Zero or more Text objects, each being either Original or Translation.
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.
A Script Event is represented in a DAPT Document at the path
/tt/head/body//div
,
with the following structure and constraints:
Based on discussion at #216 (comment), I think we should have an explicit signal to indicate when a div represents a Script Event.
<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.<div>
element corresponding to the Script Event,
with the following constraints:
xml:id
attribute MUST be present containing the Script Event Identifier.The begin
, end
and dur
attributes represent respectively the Begin, End and Duration of the Script Event.
The begin
and end
attributes SHOULD be present.
The dur
attribute MAY be present.
See 4.1.6.1 Timing Properties for additional notes on timing properties.
ttm:agent
attribute MAY be present and if present,
MUST contain a reference to each ttm:agent
attribute that represents an associated Character.
...
<div xml:id="event_1"
begin="9663f" end="9682f"
ttm:agent="character_4">
...
</div>
...
<p>
elements representing each Text object.<metadata>
element representing the On Screen property.<div>
element children.The Text object contains text content typically in a single language. This language may be the Original language or a Translation language.
Text is defined as Original if it is any of:
Text is defined as Translation if it is a representation of an Original Text object in a different language.
Text can be identified as being Original or Translation by inspecting its language and its Text Language Source together, according to the semantics defined in Text Language Source.
The source language of Translation Text objects and, where applicable, Original Text objects is indicated using the Text Language Source property.
A Text object may be styled.
Zero or more Mixing Instruction objects used to modify the programme audio during the Text MAY be present.
A Text object is represented in a DAPT Document by a <p>
element at the path
/tt/head/body//div/p
, with the following constraints:
<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].
<p>
element SHOULD have a daptm:langSrc
attribute
representing the Text object's Text Language Source,
that is, indicating whether the Text is Original or a Translation and
if its source had an inherent language.
<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
attributes on inner daptm:langSrc
<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.
<audio>
elements representing each Audio Recording object.<animate>
elements representing each Mixing Instruction object.The Text Language Source property is an annotation indicating the source language of a Text object, if applicable, or that the source content had no inherent language:
Text Language Source is an inheritable property.
The Text Language Source property is represented in a DAPT Document by a daptm:langSrc
attribute
with the following syntax, constraints and semantics:
daptm:langSrc
: <empty-string> | <language-identifier>
<empty-string>
: "" # default
<language-identifier> # valid BCP-47 language tag
<p>
and <span>
elements.<tt>
, <p>
and <span>
.daptm:langSrc
attribute is as follows:
The inheritance model of the
attribute is intended to match
the inheritance model of the daptm:langSrc
xml:lang
attribute [XML].
xml:lang
attribute,
then it indicates that the Text is Original
and sourced from content with an inherent language.xml:lang
attribute),
it indicates that the Text is a translation,
and the computed value is the language from which the Text was translated.An example of the usage of Text Language Source in a document is present in the Text section.
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:
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:
daptm:onScreen
: "ON" # default
| "OFF"
| "ON_OFF"
| "OFF_ON"
The Script Event Description object is an annotation providing a human-readable description of a Script Event. Script Event Descriptions can themselves be classified with a Description Type.
A Script Event Description object is represented in a DAPT Document by
a <ttm:desc>
element at the <div>
element level.
Zero or more <ttm:desc>
elements MAY be present.
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.
...
<body>
<div begin="10s" end="13s">
<ttm:desc>Scene 1</ttm:desc>
<p xml:lang="en">
<span>A woman climbs into a small sailing boat.</span>
</p>
<p xml:lang="fr" daptm:langSrc="en">
<span>Une femme monte à bord d'un petit bateau à voile.</span>
</p>
</div>
<div begin="18s" end="20s">
<ttm:desc>Scene 1</ttm:desc>
<p xml:lang="en">
<span>The woman pulls the tiller and the boat turns.</span>
</p>
<p xml:lang="fr" daptm:langSrc="en">
<span>La femme tire sur la barre et le bateau tourne.</span>
</p>
</div>
</body>
...
Each Script Event Description can be annotated with one or more Description Types to categorise further the purpose of the Script Event Description.
Each Description Type is represented in a DAPT Document by
a daptm:descType
attribute on the <ttm:desc>
element.
The <ttm:desc>
element MAY have zero or one daptm:descType
attributes.
The daptm:descType
attribute is defined below.
daptm:descType : string
Its permitted values are listed in the following registry table:
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. |
...
<body>
<div begin="10s" end="13s">
<ttm:desc daptm:descType="pronunciationNote">[oːnʲ]</ttm:desc>
<p>Eóin looks around at the other assembly members.</p>
</div>
</body>
...
Amongst a sibling group of <ttm:desc>
elements
there are no constraints on the uniqueness of the daptm:descType
attribute,
however it may be useful as a distinguisher as shown in the following example.
...
<body>
<div begin="10s" end="13s">
<ttm:desc daptm:descType="scene">Scene 1</ttm:desc>
<ttm:desc daptm:descType="plotSignificance">High</ttm:desc>
<p xml:lang="en">
<span>A woman climbs into a small sailing boat.</span>
</p>
<p xml:lang="fr" daptm:langSrc="en">
<span>Une femme monte à bord d'un petit bateau à voile.</span>
</p>
</div>
<div begin="18s" end="20s">
<ttm:desc daptm:descType="scene">Scene 1</ttm:desc>
<ttm:desc daptm:descType="plotSignificance">Low</ttm:desc>
<p xml:lang="en">
<span>The woman pulls the tiller and the boat turns.</span>
</p>
<p xml:lang="fr" daptm:langSrc="en">
<span>La femme tire sur la barre et le bateau tourne.</span>
</p>
</div>
</body>
...
The Script Event Type property provides one or more space-separated keywords representing the type of the Script Event, i.e. spoken text, or on-screen text, and in the latter case, the type of on-screen text (title, credit, location, ...).
The Script Event Type is represented in a DAPT Document by the following attribute:
daptm:eventType : string
Its permitted values are as listed in the following registry table:
daptm:eventType |
Status | Description | Notes |
---|---|---|---|
dialogue | Provisional | ||
spokenText | Provisional | ||
onScreenText | Provisional | ||
title | Provisional | ||
credit | Provisional | ||
location | Provisional |
...
<div xml:id="event_1"
begin="9663f" end="9682f"
ttm:agent="character_4"
daptm:eventType="dialogue">
...
</div>
...
An Audio object is used to specify an audio rendering of a Text. The audio rendering can either be a recorded audio resource, as an Audio Recording object, or a directive to synthesize a rendering of the text via a text to speech engine, which is a Synthesized Audio object. Both are types of Audio object.
It is an error for an Audio not to be in the same language as its Text.
A presentation processor that supports audio plays or inserts the Audio at the specified time on the related media object's timeline.
The Audio object is "abstract": it only can exist as one of its sub-types, Audio Recording or Synthesized Audio.
An Audio Recording is an Audio object that references an audio resource. It has the following properties:
audio/basic
;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.
When a list of Sources is provided, a presentation processor MUST play no more than one of the Sources for each Audio Recording.
Implementations can use the Type, and if present,
any relevant additional formatting information,
to decide which Source to play.
For example, given two Sources, one being a WAV file, and the other an MP3,
an implementation that can play only one of those formats,
or is configured to have a preference for one or the other,
would select the playable or preferred version.
An Audio Recording is represented in a DAPT Document by an
<audio>
element child of a <p>
or <span>
element
corresponding to the Text to which it applies.
The following constraints apply to the <audio>
element:
begin
, end
and dur
attributes
represent respectively the Begin, End and Duration properties;clipBegin
and clipEnd
attributes
represent respectively the In Time and Out Time properties,
as illustrated by Example 5;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.
<audio src="https://example.com/audio.wav" type="audio/wave"/>
<source>
child element with a
src
attribute that is not a fragment identifier
and a type
attribute respectively;
<audio>
<source src="https://example.com/audio.wav" type="audio/wave"/>
<source src="https://example.com/audio.aac" type="audio/aac"/>
</audio>
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"?
While working on the specification for adding audio recordings I reminded myself of the various ways in which an audio recording can be embedded and referenced, of which there are at least 5 in total. Requirement R15 of [DAPT](https://www.w3.org/TR/dapt-reqs/#requirements) is clear that both referenced and embedded options need to be available, but should we be syntactically restricting the options for each? Will raise as separate issues.
Originally posted by @nigelmegitt in #105 (comment)
The following two options exist in TTML2 for referencing external audio resources:
src
attribute in <audio>
element.<audio src="https://example.com/audio_recording.wav" type="audio/wave"/>
<source>
element child of <audio>
element.<audio>
<source src="https://example.com/audio_recording.wav" type="audio/wave"/>
</audio>
This second option has an additional possibility of specifying a format
attribute in case type
is inadequate. It also permits multiple <source>
child elements, and we specify that in this case the implementation must choose no more than one.
[Edited 2023-03-29 to account for the "play no more than one" constraint added after the issue was opened]
Possible resolution to #113.
Possible resolution to #113.
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.
<tt>
<head>
<resources>
<data type="audio/wave" xml:id="audio1">
[base64-encoded WAV audio resource]
</data>
</resources>
</head>
<body>
..
<audio src="#audio1"/>
..
</body>
</tt>
<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;
<tt>
<head>
<resources>
<data type="audio/wave" xml:id="audio1wav">
[base64-encoded WAV audio resource]
</data>
<data type="audio/mpeg" xml:id="audio1mp3">
[base64-encoded MP3 audio resource]
</data>
</resources>
</head>
<body>
..
<audio>
<source src="#audio1wav"/>
<source src="#audio1mp3"/>
</audio>
..
</body>
</tt>
<source>
child element with a
<data>
element child
that specifies a type
attribute and contains the audio recording data.
<audio>
<source>
<data type="audio/wave">
[base64-encoded WAV audio resource]
</data>
</source>
</audio>
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"?
While working on the specification for adding audio recordings I reminded myself of the various ways in which an audio recording can be embedded and referenced, of which there are at least 5 in total. Requirement R15 of [DAPT](https://www.w3.org/TR/dapt-reqs/#requirements) is clear that both referenced and embedded options need to be available, but should we be syntactically restricting the options for each? Will raise as separate issues.
Originally posted by @nigelmegitt in #105 (comment)
Given some embedded audio resources:
<head>
<resources>
<audio xml:id="audioRecording1" type="audio/wave">
<source>
<data>[base64 encoded audio data]</data>
</source>
</audio>
<data xml:id="audioRecording2" type="audio/wave">
[base64 encoded audio data]
</data>
</resources>
</head>
The following two options exist in TTML2 for referencing embedded audio resources:
src
attribute in <audio>
element referencing embedded <audio>
or <data>
:<audio src="#audioRecording1"/>
...
<audio src="#audioRecording2"/>
<source>
element child of <audio>
element.<audio>
<source src="#audioRecording1"/>
</audio>
This second option has an additional possibility of specifying a format
attribute in case type
is inadequate. It also permits multiple <source>
child elements, though it is unclear what the semantic is intended to be if multiple resources are specified - presumably, the implementation gets to choose one somehow.
While working on the specification for adding audio recordings I reminded myself of the various ways in which an audio recording can be embedded and referenced, of which there are at least 5 in total. Requirement R15 of [DAPT](https://www.w3.org/TR/dapt-reqs/#requirements) is clear that both referenced and embedded options need to be available, but should we be syntactically restricting the options for each? Will raise as separate issues.
Originally posted by @nigelmegitt in #105 (comment)
If we are going to support embedded audio resources, they can either be defined in /tt/head/resources
and then referenced, or the data can be included inline.
Do we need both options?
Example of embedded:
<head>
<resources>
<audio xml:id="audioRecording1" type="audio/wave">
<source>
<data>[base64 encoded audio data]</data>
</source>
</audio>
<data xml:id="audioRecording2" type="audio/wave">
[base64 encoded audio data]
</data>
</resources>
</head>
This would then be referenced in the body content using something like (see also #114):
<audio src="#audioRecording2"/>
Example of inline:
<audio type="audio/wave">
<source type="audio/wave">
<data>[base64 encoded audio data]</data>
</source>
</audio>
Possible resolution to #114 and #115.
The link to #115 is that this implies the existence of some referenceable embedded audio resource too, which one of the options described in #115.
Possible resolution to #114 and #115.
The link to #115 is that this implies the existence of some referenceable embedded audio resource too, which one of the options described in #115.
Possible resolution to #115.
See also #115 - if we are going to support non-inline embedded audio resources, should we make an object for them and add it into the Data Model?
In TTML2's <data>
element, an encoding
can be specified, being one of:
Do we need to require processor support for all of them, or will the default base64
be adequate?
Also, it is possible to specify a length
attribute that provides some feasibility of error checking, since the decoded data must be the specified length in bytes. Is requiring support for this a net benefit? Would it be used?
Possible resolution to #117.
Possible resolution to #117.
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.A Synthesized Audio is an Audio object that represents a machine generated audio rendering of the parent Text content. It has the following properties:
normal
,
fast
or
slow
;A Synthesized Audio is represented in a DAPT Document by
the application of a
tta:speak
style attribute on the element representing the Text object to be spoken,
where the computed value of the attribute is
normal
, fast
or slow
.
This attribute also represents the Rate Property.
The tta:pitch
style attribute represents the Pitch property.
The TTML representation of a Synthesized Audio is illustrated by Example 6.
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.
A Mixing Instruction object is a static or animated adjustment of the audio relating to the containing object. It has the following properties:
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:
tta:gain
attribute represents the Gain property;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:
begin
, end
and dur
attributes
represent respectively the Begin, End and Duration properties;fill
attribute represents the Fill property;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;tta:pan
attribute represents the Pan property,
and uses the animation-value-list
syntax to express the list of values to be applied during the animation period.The TTML representation of animated Mixing Instructions is illustrated by Example 4.
See also D. Audio Mixing.
A DAPT Document MUST be serialised as a well-formed XML 1.0 [xml] document encoded using the UTF-8 character encoding as specified in [UNICODE].
The resulting [xml] document MUST NOT contain any of the following physical structures:
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.
The requirements in this section are intended to facilitate forwards and backwards compatibility, specifically to permit:
A DAPT document that conforms to more than one version of the specification could specify conformance to multiple DAPT content profiles.
Unrecognised vocabulary is the set of elements and attributes that are not associated with features that the processor supports.
A transformation processor MUST prune unrecognised vocabulary that is
neither an attribute nor a descendant of
a <metadata>
element.
A transformation processor SHOULD preserve unrecognised vocabulary that is
either an attribute or a descendant of
a <metadata>
element.
See also 5.6.2 ttp:contentProfiles
which prohibits the signalling of profile
conformance to profiles that the transformation processor does not support.
After attribute value computation, a presentation processor SHOULD ignore unrecognised vocabulary.
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 6.4 Using computed attribute values it is important that processor implementations do not ignore such attributes when present on other elements.
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 5.3 Namespaces and those attributes in the global namespace that are not otherwise defined in DAPT or in [TTML2].
A DAPT Document MAY contain foreign vocabulary that is neither specifically permitted nor forbidden
by the profiles signalled in ttp:contentProfiles
.
For validation purposes it is good practice to define and use a specification for all foreign vocabulary used within a DAPT Document, for example a content profile.
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.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot GET /examples/metadata-TTML2.xml</pre>
</body>
</html>
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.
...
<metadata xmlns:vendorm="http://www.example-vendor.com/ns/ttml#metadata">
<vendorm:programType>Episode</vendorm:programType>
<vendorm:episodeSeason>5</vendorm:episodeSeason>
<vendorm:episodeNumber>8</vendorm:episodeNumber>
<vendorm:internalId>15734</vendorm:internalId>
<vendorm:information>Some proprietary information</vendorm:information>
</metadata>
...
<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.
This section is non-normative.
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 5.2.1 Unrecognised vocabulary.
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:
ttp:contentProfiles
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.
The following namespaces (see [xml-names]) are used in this specification:
Name | Prefix | Value | Defining Specification |
---|---|---|---|
XML | xml |
http://www.w3.org/XML/1998/namespace |
[xml-names] |
TT | tt |
http://www.w3.org/ns/ttml |
[TTML2] |
TT Parameter | ttp |
http://www.w3.org/ns/ttml#parameter |
[TTML2] |
TT Feature | none | http://www.w3.org/ns/ttml/feature/ |
[TTML2] |
TT Audio Style | tta |
http://www.w3.org/ns/ttml#audio |
[TTML2] |
DAPT Metadata | daptm |
http://www.w3.org/ns/ttml/profile/dapt#metadata |
This specification |
DAPT Extension | none | http://www.w3.org/ns/ttml/profile/dapt/extension/ |
This specification |
The namespace prefix values defined above are for convenience and DAPT Documents MAY use any prefix value that conforms to [xml-names].
The namespaces defined by this specification are mutable as described in [namespaceState]; all undefined names in these namespaces are reserved for future standardization by the W3C.
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.
This profile is associated with the following profile designators:
Profile Name | Profile type | Profile Designator |
---|---|---|
DAPT 1.0 Content Profile | content profile | http://www.w3.org/ns/ttml/profile/dapt1.0/content |
DAPT 1.0 Processor Profile | processor profile | http://www.w3.org/ns/ttml/profile/dapt1.0/processor |
The ttp:contentProfiles
attribute
is used to declare the [TTML2] profiles to which the document conforms.
DAPT Documents MUST specify a
attribute
on the ttp:contentProfiles
<tt>
element including at least one value equal to a
content profile designator specified at 5.6.1 Profile Designators.
Other values MAY be present to declare conformance to other profiles of [TTML2],
and MAY include profile designators in proprietary namespaces.
It is an error for a DAPT Document to signal conformance to a content profile to which it does not conform.
Transformation processors MUST NOT include values within the
attribute
associated with profiles that they (the processors) do not support;
by definition they cannot verify conformance of the content to those profiles.ttp:contentProfiles
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.
The ttp:processorProfiles
attribute
is used to declare the processing requirements for a Document Instance.
DAPT Documents MAY specify a
attribute
on the ttp:processorProfiles
<tt>
element.
If present, the
attribute MUST include at least one value equal to a
processor profile designator specified at 5.6.1 Profile Designators.
Other values MAY be present to declare additional processing constraints,
and MAY include profile designators in proprietary namespaces.ttp:processorProfiles
The
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.ttp:processorProfiles
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
attribute is not expected to be present.ttp:processorProfiles
[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 E. Profiles 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:
<ttp:profile>
element;<ttp:feature>
and <ttp:extension>
elements;ttp:permitFeatureNarrowing
attribute;ttp:permitFeatureWidening
attribute;ttp:contentProfileCombination
attribute;ttp:inferProcessorProfileSource
attribute;ttp:processorProfileCombination
attribute.Within a DAPT Script, the following constraints apply in relation to time attributes and time expressions:
The only permitted ttp:timeBase
attribute value is media
,
since E. Profiles 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.
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.
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.
If the document contains any time expression that uses the t
metric,
the ttp:tickRate
attribute MUST be present on the <tt>
element.
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, andt
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
.
This specification does not put additional constraints on the layout and rendering features defined in [TTML-IMSC1.2].
<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].
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 Inline markup and bidirectional text in HTML.
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.
<p>
The title of the book is
"<span tts:unicodeBidi="embed" tts:direction="rtl">نشاط التدويل، W3C</span>"
</p>
An example rendering of the above fragment is shown below.
4. DAPT Data Model and corresponding TTML syntax 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, 4. DAPT Data Model and corresponding TTML syntax 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.
This section is non-normative.
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 5.6.2 ttp:contentProfiles
,
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.
A processor that takes as its input a DAPT document that contains vocabulary relating to features that it does support, but where support for those features is excluded from the content profiles to which the document claims conformance, SHOULD NOT implement those features in the context of that document.
[TTML2] allows <div>
elements to contain any combination of
<div>
elements and <p>
elements.
The DAPT data model describes how each Script Event is represented by
a <div>
element that contains zero or more <p>
elements.
It also permits other intermediate <div>
elements in the path between
the <body>
element and those Script Event <div>
elements.
In addition, attributes not corresponding to properties in the DAPT data model are permitted.
This gives rise to possibilities such as:
<div>
elements that contain children that are not Text objects,
for example other <div>
elements or <metadata>
elements;<div>
elements that do not have attributes required for Script Events, like xml:id
;<div>
elements that have attributes absent from the DAPT data model for Script Events,
like xml:space
;<p>
elements whose parent <div>
element does not appear to be a Script Event.The following processing rules resolve these cases.
Rules for identifying Script Events:
<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;<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;<div>
elements MUST NOT be mapped to a Script Event.Rules for identifying Text objects:
<p>
element that is a child of a <div>
element
that maps to a Script Event MUST be mapped to a Text object.<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.
This section is non-normative.
Some normative provisions relating to this section are defined in [TTML2].
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 its parent element. If a <div>
element specifies a begin
attribute, and that element does not correspond to a Script Event, then the computed times
of its descendant <div>
elements that do correspond to Script Events
are different to what they would be if that intermediate <div>
element's begin
time were ignored.
MAYBE REMOVE Or, also for example, if styling is used in a TTML document, the computed value of the tts:fontSize
attribute when expressed as a percentage is relative to the computed value of the same attribute
on the element's parent.
Furthermore, in this example, the algorithm for generating ISDs (Intermediate Synchronic Documents)
involves reparenting some elements. The computed value that applies is the one before
rehoming has taken place.
Considering this situation more generally, it is possible that, within a DAPT document, there can be TTML elements that do not directly correspond to objects in the DAPT data model, and those elements can specify attributes that affect the computation of attribute values that apply to elements that do correspond to objects in the DAPT data model.
The semantics defined by [TTML2] or, for vocabulary defined herein, this specification, take precedence in this scenario. Implementations MUST compute attribute values based on the contents of the document instance before applying those computed values to DAPT data model objects.
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.
This section is non-normative.
As per 5.2.1 Unrecognised vocabulary,
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.
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.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
[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 E. Profiles 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 E. Profiles 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 E. Profiles.
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.
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 E. Profiles.
This section is non-normative.
With the exception of the following, the privacy considerations of [ttml2] apply:
<audio>
element apply.condition
attribute is required.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.
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.
This section is non-normative.
The security considerations of [ttml2] apply.
This section is non-normative.
Applying the Mixing Instructions can be implemented using [webaudio]. Figure 2 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.
This example is shown as [webaudio] nodes in Figure 3.
The above examples are simplified in at least two ways:
<span>
elements that themselves have Mixing Instructions
applied, then additional nodes would be needed;<animate>
element semantics directly into
[webaudio] API calls to achieve the equivalent effect.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 F. Extensions.
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:
A timed text content document instance, by definition, satisfies the requirements of Section 3.1 at [TTML2], and hence a timed text content document instance that conforms to a profile defined herein is also a conforming TTML2 Document Instance.
A Presentation processor that conforms to the processor profile defined in this specification:
A Transformation processor that conforms to the processor profile defined in this specification:
The dispositions required, permitted, optional and prohibited as used in this specification
map to the [TTML2] <ttp:feature>
and <ttp:extension>
elements'
value
attribute values as follows:
DAPT disposition | or element value attribute value in |
|
---|---|---|
content profile | processor profile | |
required | required | required |
permitted | optional | required |
optional | optional | optional |
prohibited | prohibited | optional |
The use of the terms presentation processor and transformation processor within this document does not imply conformance per se to any of the Standard Profiles defined in [TTML2]. In other words, it is not considered an error for a presentation processor or transformation processor to conform to the profile defined in this document without also conforming to the TTML2 Presentation Profile or the TTML2 Transformation Profile.
The use of the [TTML2] profiling sub-system to describe DAPT conformance within this specification is not intended imply that DAPT processors are required to support any features of that system other than those for which support is explicitly required by DAPT.
This document does not specify presentation processor or transformation processor behavior when processing or transforming a non-conformant timed text content document instance.
The permitted and prohibited dispositions do not refer to the specification of
a
or <ttp:feature>
element
as being permitted or prohibited within a <ttp:extension>
<ttp:profile>
element.
The features and extensions listed in this section express the minimal requirements for DAPT Documents, Presentation Processors, and Transformation Processors. DAPT Documents MAY additionally conform to other profiles, and include syntax not prohibited by the DAPT content profile. Presentation Processors and Transformation Processors MAY support additional syntax and semantics relating to other profiles.
For example, a DAPT Script can include syntax permitted by the IMSC ([TTML-IMSC1.2]) profiles of [TTML2] to enhance the presentation of scripts to actors recording audio, or to add styling important for later usage in subtitle or caption creation.
Editorial task: go through this list of features and check the disposition of each. There should be no prohibited features that are permitted in IMSC.
Feature or Extension | Disposition | Additional provision |
---|---|---|
Relative to the TT Feature namespace | ||
#animate-minimal |
permitted | |
#animate-fill |
permitted | |
#animation-out-of-line |
prohibited | See 4.10 Mixing Instruction. |
#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 5.6.2 ttp:contentProfiles
and F.3 #contentProfiles-root. |
#contentProfiles-combined |
optional | See 5.6.5 Other TTML2 Profile Vocabulary. |
#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 5.7.3 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 5.6.5 Other TTML2 Profile Vocabulary. |
#permitFeatureWidening |
optional | See 5.6.5 Other TTML2 Profile Vocabulary. |
#pitch |
permitted | |
#presentation-audio |
permitted | |
#processorProfiles |
optional | See 5.6.4 ttp:processorProfiles . |
#processorProfiles-combined |
optional | See 5.6.5 Other TTML2 Profile Vocabulary. |
#profile |
partially permitted |
See 5.6.3 ttp:profile .
|
#profile-full-version-2 |
partially permitted | See 5.6.5 Other TTML2 Profile Vocabulary. |
#profile-version-2 |
partially permitted | See 5.6.5 Other TTML2 Profile Vocabulary. |
#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 5.7.4 ttp:tickRate . |
#time-clock |
permitted | |
#time-clock-with-frames |
prohibited | |
#time-offset-with-frames |
permitted | See 5.7.3 ttp:frameRate . |
#time-offset-with-ticks |
permitted | See 5.7.4 ttp:tickRate . |
#time-offset |
permitted | |
#time-wall-clock |
prohibited | |
#timeBase-clock |
prohibited | |
#timeBase-media |
required |
See 5.7.1 NOTE: [TTML1] specifies that the default timebase is |
#timeBase-smpte |
prohibited | |
#timeContainer |
prohibited | See 5.7.2 timeContainer . |
#timing |
permitted | See 5.7.5 Time expressions. |
#transformation |
permitted | See constraints at #profile. |
Relative to the DAPT Extension namespace | ||
#agent |
permitted | This is the profile expression of 4.2 Character. |
#contentProfiles-root |
required |
This is the profile expression of 5.6.2 ttp:contentProfiles .
|
#onScreen |
permitted | This is the profile expression of 4.6 On Screen. |
#profile-root |
prohibited |
This is the profile expression of 5.6.3 ttp:profile .
|
#represents-root |
required | This is the profile expression of 4.1.1 Represents. |
#scriptEventMapping |
optional |
This is the profile expression of 6.3 Handling <div> and <p> elements.
|
#scriptType-root |
required | This is the profile expression of 4.1.3 Script Type. |
#serialization |
required | This is the profile expression of 5.1 Document Encoding. |
#source-data |
prohibited |
This is the profile expression of the prohibition of <source>
child elements of <data> elements as specified in
4.9.1 Audio Recording.
|
#textLanguageSource |
permitted | This is the profile expression of 4.5 Text Language Source as required at 4.4 Text. |
#xmlId-div |
required | This is the profile expression of 4.3 Script Event. |
#xmlLang-audio-nonMatching |
prohibited |
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
4.9.1 Audio Recording.
|
#xmlLang-root |
required | This is the profile expression of 4.1.2 Default Language. |
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.
<?xml version="1.0" encoding="utf-8"?>
<!-- this file defines the "dapt-content" profile of ttml -->
<profile xmlns="http://www.w3.org/ns/ttml#parameter"
designator="http://www.w3.org/ns/ttml/profile/dapt1.0/content"
combine="mostRestrictive"
type="content">
<features xml:base="http://www.w3.org/ns/ttml/feature/">
<!-- required (mandatory) feature support -->
<feature value="required">#structure</feature>
<feature value="required">#timeBase-media</feature>
<!-- optional (voluntary) feature support -->
<feature value="optional">#animate-fill</feature>
<feature value="optional">#animate-minimal</feature>
<feature value="optional">#audio</feature>
<feature value="optional">#audio-description</feature>
<feature value="optional">#audio-speech</feature>
<feature value="optional">#bidi</feature>
<feature value="optional" extends="#bidi">#bidi-version-2</feature>
<feature value="optional">#chunk</feature>
<feature value="optional">#content</feature>
<feature value="optional">#contentProfiles</feature>
<feature value="optional">#contentProfiles-combined</feature>
<feature value="optional">#core</feature>
<feature value="optional">#data</feature>
<feature value="optional">#direction</feature>
<feature value="optional">#embedded-audio</feature>
<feature value="optional">#embedded-data</feature>
<feature value="optional">#frameRate</feature>
<feature value="optional">#frameRateMultiplier</feature>
<feature value="optional">#gain</feature>
<feature value="optional">#metadata</feature>
<feature value="optional">#metadata-item</feature>
<feature value="optional" extends="#metadata">#metadata-version-2</feature>
<feature value="optional">#pan</feature>
<feature value="optional">#permitFeatureNarrowing</feature>
<feature value="optional">#permitFeatureWidening</feature>
<feature value="optional">#pitch</feature>
<feature value="optional">#presentation-audio</feature>
<feature value="optional">#processorProfiles</feature>
<feature value="optional">#processorProfiles-combined</feature>
<feature value="optional">#resources</feature>
<feature value="optional" extends="#animation">#set</feature>
<feature value="optional">#set-fill</feature>
<feature value="optional">#set-multiple-styles</feature>
<feature value="optional">#source</feature>
<feature value="optional">#speak</feature>
<feature value="optional">#speech</feature>
<feature value="optional">#styling</feature>
<feature value="optional">#styling-chained</feature>
<feature value="optional">#styling-inheritance-content</feature>
<feature value="optional">#styling-inline</feature>
<feature value="optional">#styling-referential</feature>
<feature value="optional">#tickRate</feature>
<feature value="optional">#time-clock</feature>
<feature value="optional">#time-offset</feature>
<feature value="optional">#time-offset-with-frames</feature>
<feature value="optional">#time-offset-with-ticks</feature>
<feature value="optional">#timing</feature>
<feature value="optional">#unicodeBidi</feature>
<feature value="optional">#unicodeBidi-isolate</feature>
<feature value="optional" extends="#unicodeBidi">#unicodeBidi-version-2</feature>
<feature value="optional">#xlink</feature>
<!-- prohibited feature support -->
<feature value="prohibited">#animation-out-of-line</feature>
<feature value="prohibited">#clockMode</feature>
<feature value="prohibited">#clockMode-gps</feature>
<feature value="prohibited">#clockMode-local</feature>
<feature value="prohibited">#clockMode-utc</feature>
<feature value="prohibited">#dropMode</feature>
<feature value="prohibited">#dropMode-dropNTSC</feature>
<feature value="prohibited">#dropMode-dropPAL</feature>
<feature value="prohibited">#dropMode-nonDrop</feature>
<feature value="prohibited">#markerMode</feature>
<feature value="prohibited">#markerMode-continuous</feature>
<feature value="prohibited">#markerMode-discontinuous</feature>
<feature value="prohibited">#subFrameRate</feature>
<feature value="prohibited">#time-clock-with-frames</feature>
<feature value="prohibited">#time-wall-clock</feature>
<feature value="prohibited">#timeBase-clock</feature>
<feature value="prohibited">#timeBase-smpte</feature>
<feature value="prohibited">#timeContainer</feature>
</features>
<extensions xml:base="http://www.w3.org/ns/ttml/profile/dapt/extension/">
<!-- required (mandatory) extension support -->
<extension value="required">#contentProfiles-root</extension>
<extension value="required">#represents-root</extension>
<extension value="required">#scriptType-root</extension>
<extension value="required">#serialization</extension>
<extension value="required">#xmlId-div</extension>
<extension value="required">#xmlLang-root</extension>
<!-- optional (voluntary) extension support -->
<extension value="optional">#agent</extension>
<extension value="optional">#onScreen</extension>
<extension value="optional">#scriptEventMapping</extension>
<extension value="optional">#textLanguageSource</extension>
<!-- prohibited extension support -->
<extension value="prohibited">#profile-root</extension>
<extension value="prohibited">#source-data</extension>
<extension value="prohibited">#xmlLang-audio-nonMatching</extension>
</extensions>
</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.
<?xml version="1.0" encoding="utf-8"?>
<!-- this file defines the "dapt-processor" profile of ttml -->
<profile xmlns="http://www.w3.org/ns/ttml#parameter"
designator="http://www.w3.org/ns/ttml/profile/dapt1.0/processor"
combine="mostRestrictive"
type="processor">
<features xml:base="http://www.w3.org/ns/ttml/feature/">
<!-- required (mandatory) feature support -->
<feature value="required">#animate-fill</feature>
<feature value="required">#animate-minimal</feature>
<feature value="required">#audio</feature>
<feature value="required">#audio-description</feature>
<feature value="required">#audio-speech</feature>
<feature value="required">#bidi</feature>
<feature value="required" extends="#bidi">#bidi-version-2</feature>
<feature value="required">#chunk</feature>
<feature value="required">#content</feature>
<feature value="required">#contentProfiles</feature>
<feature value="required">#core</feature>
<feature value="required">#data</feature>
<feature value="required">#direction</feature>
<feature value="required">#embedded-audio</feature>
<feature value="required">#embedded-data</feature>
<feature value="required">#frameRate</feature>
<feature value="required">#frameRateMultiplier</feature>
<feature value="required">#gain</feature>
<feature value="required">#metadata</feature>
<feature value="required">#metadata-item</feature>
<feature value="required" extends="#metadata">#metadata-version-2</feature>
<feature value="required">#pan</feature>
<feature value="required">#pitch</feature>
<feature value="required">#presentation-audio</feature>
<feature value="required">#resources</feature>
<feature value="required" extends="#animation">#set</feature>
<feature value="required">#set-fill</feature>
<feature value="required">#set-multiple-styles</feature>
<feature value="required">#source</feature>
<feature value="required">#speak</feature>
<feature value="required">#speech</feature>
<feature value="required">#structure</feature>
<feature value="required">#styling</feature>
<feature value="required">#styling-chained</feature>
<feature value="required">#styling-inheritance-content</feature>
<feature value="required">#styling-inline</feature>
<feature value="required">#styling-referential</feature>
<feature value="required">#tickRate</feature>
<feature value="required">#time-clock</feature>
<feature value="required">#time-offset</feature>
<feature value="required">#time-offset-with-frames</feature>
<feature value="required">#time-offset-with-ticks</feature>
<feature value="required">#timeBase-media</feature>
<feature value="required">#timing</feature>
<feature value="required">#transformation</feature>
<feature value="required">#unicodeBidi</feature>
<feature value="required">#unicodeBidi-isolate</feature>
<feature value="required" extends="#unicodeBidi">#unicodeBidi-version-2</feature>
<feature value="required">#xlink</feature>
<!-- optional (voluntary) feature support -->
<feature value="optional">#animation-out-of-line</feature>
<feature value="optional">#clockMode</feature>
<feature value="optional">#clockMode-gps</feature>
<feature value="optional">#clockMode-local</feature>
<feature value="optional">#clockMode-utc</feature>
<feature value="optional">#contentProfiles-combined</feature>
<feature value="optional">#dropMode</feature>
<feature value="optional">#dropMode-dropNTSC</feature>
<feature value="optional">#dropMode-dropPAL</feature>
<feature value="optional">#dropMode-nonDrop</feature>
<feature value="optional">#markerMode</feature>
<feature value="optional">#markerMode-continuous</feature>
<feature value="optional">#markerMode-discontinuous</feature>
<feature value="optional">#permitFeatureNarrowing</feature>
<feature value="optional">#permitFeatureWidening</feature>
<feature value="optional">#processorProfiles</feature>
<feature value="optional">#processorProfiles-combined</feature>
<feature value="optional">#subFrameRate</feature>
<feature value="optional">#time-clock-with-frames</feature>
<feature value="optional">#time-wall-clock</feature>
<feature value="optional">#timeBase-clock</feature>
<feature value="optional">#timeBase-smpte</feature>
<feature value="optional">#timeContainer</feature>
</features>
<extensions xml:base="http://www.w3.org/ns/ttml/profile/dapt/extension/">
<!-- required (mandatory) extension support -->
<extension value="required">#agent</extension>
<extension value="required">#contentProfiles-root</extension>
<extension value="required">#onScreen</extension>
<extension value="required">#represents-root</extension>
<extension value="required">#scriptType-root</extension>
<extension value="required">#serialization</extension>
<extension value="required">#textLanguageSource</extension>
<extension value="required">#xmlId-div</extension>
<extension value="required">#xmlLang-root</extension>
<!-- optional (voluntary) extension support -->
<extension value="optional">#profile-root</extension>
<extension value="optional">#scriptEventMapping</extension>
<extension value="optional">#source-data</extension>
<extension value="optional">#xmlLang-audio-nonMatching</extension>
</extensions>
</profile>
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 E. Profiles to describe the normative provisions of DAPT that are not expressed by [TTML2] profile features.
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>
elementand 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.
A transformation processor supports the #contentProfiles-root
extension if
it recognizes and is capable of transforming values of the
attribute on the ttp:contentProfiles
<tt>
element.
A presentation processor supports the #contentProfiles-root
extension if
it implements presentation semantic support of the
attribute on the ttp:contentProfiles
<tt>
element.
A transformation processor supports the #onScreen
extension if
it recognizes and is capable of transforming values of the
attribute on the daptm:onScreen
<div>
element.
A presentation processor supports the #onScreen
extension if
it implements presentation semantic support of the
attribute on the daptm:onScreen
<div>
element.
A transformation processor supports the #profile-root
extension if
it recognizes and is capable of transforming values of the
attribute on the ttp:profile
<tt>
element.
A presentation processor supports the #profile-root
extension if
it implements presentation semantic support of the
attribute on the ttp:profile
<tt>
element.
A transformation processor supports the #represents-root
extension if
it recognizes and is capable of transforming values of the
attribute on the daptm:represents
<tt>
element.
A presentation processor supports the #represents-root
extension if
it implements presentation semantic support of the
attribute on the daptm:represents
<tt>
element.
An example of a transformation processor that supports this extension is
a validating processor that reports an error if the extension is required by a
content profile but the timed text content document instance claiming
conformance to that profile either does not have a
attribute on the daptm:represents
<tt>
element
or has one whose value is not conformant with the requirements defined herein.
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 6.3 Handling <div>
and <p>
elements.
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.
A transformation processor supports the #scriptType-root
extension if
it recognizes and is capable of transforming values of the
attribute on the daptm:scriptType
<tt>
element.
A presentation processor supports the #scriptType-root
extension if
it implements presentation semantic support of the
attribute on the daptm:scriptType
<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 4.1.3 Script Type for a
DAPT Document's
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 daptm:scriptType
<tt>
element
or has one whose value is not defined herein.
A serialized document that is valid with respect to the #serialization
extension is
an XML 1.0 [xml] document encoded using
UTF-8 character encoding as specified in [UNICODE],
that contains no entity declarations and
no entity references other than to predefined entities.
A transformation processor or a presentation processor supports
the #serialization
extension if
it can read a serialized document as defined above.
A transformation processor that writes documents supports
the #serialization
extension if
it can write a serialized document as defined above.
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.
A transformation processor supports the #textLanguageSource
extension if
it recognizes and is capable of transforming values of the
attribute.daptm:langSrc
A presentation processor supports the #textLanguageSource
extension if
it implements presentation semantic support of the
attribute.daptm:langSrc
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.
A transformation processor supports the #xmlLang-audio-nonMatching
extension if
it recognizes and is capable of transforming values of the
xml:lang
attribute on the <audio>
element
that differ from the computed value of the same attribute of its
parent element or any of its descendant or referenced
<source>
or <data>
elements,
known as non-matching values.
A presentation processor supports the #xmlLang-audio-nonMatching
extension if
it implements presentation semantic support of such non-matching
xml:lang
attribute values.
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 4.1.2 Default Language.
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 4.1.2 Default Language.
This section specifies the registry definition, consisting of the custodianship, change process and the core requirements of the registry tables defined in this document.
The custodian of this w3c registry is the Timed Text Working Group (TTWG). If the TTWG is unable to fulfil the role of custodian, for example if it has been closed, the custodian in lieu is the W3C Team.
Changes to this W3C Registry MUST be requested (the change request) using any one of the following options:
The change request MUST include enough information for the custodian to be able to identify all of:
provisional
registry entries for which changes are being proposed, if any;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.
The process for assessing a change request depends on the custodian.
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.
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.
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 G.2 Registry Table Definitions, which lists the fields present in each registry entry.
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 definition MUST define the fields and the key to be used in each registry entry.
The registry entry status field reflects the maturity of that entry. Permitted values are:
Provisional
Final
Deprecated
No other values are permitted.
Registry entries with a status of Provisional
MAY be changed or deleted.
Their status may be changed to
or Final
.Deprecated
Registry entry keys in
entries
that were later deleted MAY be reused.Provisional
Newly created registry entries SHOULD have status
.Provisional
Registry entries with a status of Final
MUST NOT be deleted or changed.
Their status MAY be changed to
.Deprecated
Registry entry keys in
entries MUST NOT be reused.Final
Newly created registry entries MAY have status
.Final
Registry entries with a status of Deprecated
MUST NOT be deleted or changed.
Their status MAY be changed to
unless that would result in a duplicate key within the set of entries whose
status is either Final
or Provisional
.Final
Registry entry keys in
entries
that were previously Deprecated
Provisional
and never
MAY be reused.Final
Registry entry keys in
entries
that were previously Deprecated
MUST NOT be reused.Final
Newly created registry entries MUST NOT have status
.Deprecated
This section defines registry tables and locates their registry entries.
The registry table for daptm:descType
defines a set of values that can be
used in the daptm:descType
attribute.
The key is the "daptm:descType
" field.
The "description" field describes the intended purpose of each value.
The registry entries for this registry table are located in 4.7 Script Event Description.
The registry table for daptm:eventType
defines a set of values that can be
used in the daptm:eventType
attribute.
The key is the "daptm:eventType
" field.
The "description" field describes the intended purpose of each value.
The registry entries for this registry table are located in 4.8 Script Event Type.
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 "Used in" field describes the type of script in which the content type
described are commonly found.
The registry entries for this registry table are located in 4.1.1 Represents.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: