This specification defines DAPT, a TTML-based file format for the exchange of timed text content in dubbing and audio description workflows.
Status of This Document
This is a
preview
Do not attempt to implement this version of the specification. Do not
reference this version as authoritative in any way.
Instead, see
https://w3c.github.io/dapt/ for the Editor's draft.
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/.
Publication as an Editor's 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.
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 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 Requirements, and to permit usage of visual presentation
features within [TTML2] and its profiles, for example those in [ttml-imsc1.2].
2. Introduction
This section is non-normative.
Creating a dub is a complex, multi-step process that involves:
Transcribing and timing the dialogue in the original language from a completed programme to create a source transcription text
Notating dialogue with character information and other annotations
Generating localization notes to guide further adaptation
Translating the dialogue to a target language
Adapting the translation to the dubbing and subtitling specifications; ex. matching the actor’s lip movements in the case of dubs and considering reading speeds and shot changes.
The result of creating a dubbing script 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 or audio descriptions.
Creating audio description content is also a complex process with similar steps.
An audio description, also known as video description, is an audio service
to assist viewers who can not fully see a visual presentation to understand the content.
It is the result of the audio rendition of one or more descriptions
mixed with the audio associated with the programme prior to any mixing with audio description
(sometimes referred to as main programme audio),
at moments when this does not clash with dialogue, to deliver an audio description mixed audio track.
A description is a set of words that describe 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 [WCAG20].
More information about what audio description is and how it works can be found at [WHP051].
Improve introduction to describe audio description steps and how it relates to dubbing. Maybe reuse the diagrams from the requirements document, or link the requirements doc.
This specification defines DAPT, a TTML-based format for the exchange of timed text content among authoring and prompting tools in the localization and audio description pipeline.
A DAPT file is designed to carry pertinent information for dubbing or audio description such as type of script, dialogue, descriptions, timing, metadata, original language text, transcribed text, language information, and to be extensible for future annotations.
This specification first defines the data model (see 4. DAPT Data Model and corresponding TTML syntax) for DAPT scripts and then its representation as a TTML document with restrictions (see #ttml-format).
2.1 Example documents
2.1.1 Basic document structure
The top level structure of a document is as follows. The xmlns attribute and the tt element indicate that this is a TTML document and the contentProfiles attribute indicates that it adheres to the DAPT profile defined in this specification. The daptm:scriptType attribute indicates the type of script but in this empty example, it is not relevant, as only the structure of the document is shown. The structure is applicable to all types of scripts, dubbing or audio description.
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-top-level.xml</pre></body></html>
The following examples correspond to the timed text scripts produced
at each stage of the workflow described in [DAPT-REQS].
The first example shows a script where timed opportunities for descriptions
or transcriptions have been identified but no text has been written:
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-times-only.xml</pre></body></html>
The following examples will demonstrate different uses in dubbing and audio description workflows.
2.1.2 Audio Description Examples
When descriptions are added this becomes a Pre Recording Script:
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-times-and-text.xml</pre></body></html>
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, smoothly
animating the value on the way in and returning it on the way out:
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-script-with-gain.xml</pre></body></html>
In the above example, the div element's
begin time becomes 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 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:
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-script-with-audio-clipped.xml</pre></body></html>
Or audio attributes can be added to trigger the text to be spoken:
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-script-with-speak.xml</pre></body></html>
2.1.3 Dubbing Examples
From the basic structure of Example 1, a transcription of the audio programme produces an original language dubbing script,
which can look as follows. No specific style or layout is defined, and here the focus is on the transcription of the dialogs.
Characters are identified in the metadata section.
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-original-language.xml</pre></body></html>
After translating the text, the document is modified. It includes translation text, and
in this case the original text is preserved. The main document language is changed to indicate
that the focus is on the translated language:
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-original-language-with-dub-language.xml</pre></body></html>
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:
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/intro-original-language-with-dub-language-and-adaptation.xml</pre></body></html>
3. Documentation Conventions
This document uses the same conventions as [TTML2] for the specification of parameter attributes, styling attributes and metadata elements. In particular:
Section 2.3 of [TTML2] specifies conventions used in the [XML] representation of elements; and
Sections 6.2 and 8.2 of [TTML2] specify conventions used when specifying the syntax of attribute values.
This specification uses Feature designations as defined in Appendices E at [TTML2]:
when making reference to content conformance, these designations refer to the syntactic expression or the semantic capability associated with each designated Feature; and
when making reference to Processor conformance, these designations refer to processing requirements associated with each designated Feature.
If the name of an element referenced in this specification is not namespace qualified, then the TT namespace applies (see 9.3 Namespaces.)
4. DAPT Data Model and corresponding TTML syntax
This section specifies the data model for DAPT and its corresponding TTML syntax. In the model, there are objects which can have properties and be associated with other objects. In the TTML syntax, these objects and properties are expressed as elements and attributes.
Error
Cannot GET /uploads/9wY0pR/figures/class-diagram.svg
Figure 1
Class diagram showing main entities in the DAPT data model.
The definitions of the types of documents and the corresponding daptm:scriptType values are:
Original Language Dialogue List:
When the daptm:scriptType value is DUBBING_ORIGINAL_DIALOGUE_LIST,
the document is a literal transcription of the dialogue and on-screen text in their original spoken/written language(s).
When the daptm:scriptType value is DUBBING_TRANSLATED_DIALOGUE_LIST,
the document represents a translation of the Original Language Dialogue List in a common language.
It can be adapted to produce a Pre-Recording Dub Script,
and/or used as the basis for producing translation subtitles,
or used as the basis for a further translation into the Target Recording Language.
When the daptm:scriptType value is DUBBING_PRE_RECORDING,
the document represents the result of the adaptation of a Translated Dialogue List for dubbing,
e.g. for better lip-sync.
When the daptm:scriptType value is AUDIO_DESCRIPTION,
the document represents text script, times, optional links to audio and mixing instructions
for the purpose of producing an audio description audio track.
The Primary Language is a mandatory property of a DAPT Script
which represents the default language for the Text content of Script Events.
It is represented in TTML with the following structure and constraints:
the xml:lang attribute MUST be present on the tt element and its value MUST NOT be empty.
Note
All text content in a DAPT Script has a specified language.
When multiple languages are used, the Primary Language can correspond to the language of the majority of Script Events,
to the language being spoken for the longest duration, or to the language arbitrarily chosen by the author.
In Dubbing Scripts, it is necessary to identify each character in the programme. This is done with a Character object which has the following properties:
a mandatory Identifier
which is a unique identifier used to reference the character from elsewhere in the document,
for example to indicate when a Character participates in a Script Event,
or to link a Character Style to its Character.
a mandatory Name which is the name of the Character in the programme
an optional Talent Name, which is the name of the actor speaking dialogue for this Character
zero or more Character Style objects
which can be applied to control the visual appearance of Script Events spoken by the Character,
for example during recording by an actor or when transforming the script into subtitles.
A Character is represented in TTML with the following structure and constraints:
There MUST be a ttm:agent element, child of the metadata element that indicates the Script Type in the head element, with the following constraints:
The type attribute MUST be set to character.
The xml:id attribute MUST be present on the ttm:agent and set to the Character Identifier.
The ttm:agentMUST 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 property, the following TTML constraints apply:
Another ttm:agentMUST be added to the metadata element that indicates the Script Type in the head element, with the following:
its type attribute MUST be set to person
its xml:id attribute MUST be set.
it MUST have a ttm:name child element whose typeMUST be set to full and its content set to the Talent Name
the ttm:agent whose type is set to characterMUST have a ttm:actor child, with its agent attribute set to the xml:id of the ttm:agent whose type is set to person.
the ttm:agent whose type is set to character should appear before the ttm:agent whose type is set to person.
A Character Style is represented in TTML with the following structure and constraints:
Each Character Style is represented by one or more <style> element children of the <styling> element.
Each such <style> element is associated with the Character by having a ttm:agent attribute
whose value is the xml:id of the <ttm:agent> element representing the Character.
A Script EventMAY apply Character Styles by including the xml:id of each style
in the style attribute of the <div> element that defines that Script Event.
A Text object MAY apply Character Styles by including the xml:id of each style
in the style attribute of the <p> element that defines that Text object.
A Text object SHOULD NOT apply a Character Style for a Character that is not associated with that Text object's Script Event.
Note
Any style attribute defined in [TTML2] or [ttml-imsc1.2]
(or other profiles using non-W3C namespaces) can be present on the <style> element.
A <style> element MAY omit the ttm:agent attribute if it is not associated with a Character.
Such styles MAY be applied in the same way as any other style, via a reference in the style attribute.
Character Styles are applied to Script Events and Text by using the style attribute to specify the set of applicable styles.
Presentation ProcessorsMUST NOT apply character styles to text if they are not specified using the style attribute.
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:
DAPT Authoring Tool: tool that produces compliant DAPT documents or consumes DAPT compliant document. I don't think they map to TTML2 processors.
DAPT Audio Recorder/Renderer: tool that takes DAPT Audio Description scripts, e.g. with mixing instruction, and produces audio output, e.g. a WAVE file. I think it is a "presentation processor"
DAPT Validator: tool that verify that a DAPT document is compliant to the specification. I'm not sure what it maps to in TTML2 terminology.
Styles are used for characters, texts and contextual texts. From my reading, they are essentially the same property for all three "contexts" where there are used but they have a different name in each context (Style, Text Styles and Contextual Text Styles). This could be represented as one property (e.g. Style) that has a cardinality of 1..* and references a Style Object (with style feature e.g. color). The association is implied by the object it belongs to.
4.3 Script Event
An Script Event object represents dialogue, on screen text or audio descriptions to be spoken and has the following properties:
A mandatory Script Event Identifier which is unique in the script
An optional Begin property and an optional End and an optional Duration property
that together define the Script Event's time interval in the programme timeline
Note
Typically Script Events do not overlap in time. However, there can be cases where they do, e.g. in Dubbing Scripts when different Characters speak different text at the same time.
An optional Script Event Type used to identify in Dubbing Scripts if the Script Event represents spoken text, or on screen text, and in the later case, the type of on-screen text (title, credit, location, ...).
While typically, a Script Event corresponds to one single Character, there are cases where multiple characters can be associated with a Script Event. This is when all Characters speak the same text at the same time.
Zero or more Text objects, each representing either the Original language script or
Translations of the original language script in other languages.
an optional Script Event Description property, as a human-readable description of the Script Event.
Note
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 begin and end attributes SHOULD be present.
The dur attribute MAY be present.
Note
As noted in [ttml2] if both an end attribute and a dur attribute are present,
the end time is the earlier of end and (begin + dur).
Note
If timing attributes are omitted, the following rules apply:
The default value for begin is zero, i.e. the same as the begin time of the parent element.
The default value for end is indefinite,
i.e. it resolves to the same as the end time of the parent timed element,
if there is one.
The topmost timed element is the <body> element,
whose end time is for practical purposes the end of the Related Media Object.
The default value for dur is indefinite, i.e. the end time resolves to the same as the end time of the parent element.
The ttm:agent attribute MAY be present and if present,
MUST contain a reference to each ttm:agent that represents an associated Character.
It MAY contain zero or more p elements representing each Text object.
The style attribute MAY be present. If present, it MAY contain a reference to the <style> defining the Character Style. Additional style references or inline styles MAY be used.
It MAY contain a metadata element representing the On Screen property.
4.4 Text
The Text object contains text content in a single language, and may be styled and associated with a Character.
It indicates whether it is in the Original language or if it is a Translation, as well as its language.
The language for which a dubbing or audio description script is being prepared is called the Target Recording Language.
Styles are used for characters, texts and contextual texts. From my reading, they are essentially the same property for all three "contexts" where there are used but they have a different name in each context (Style, Text Styles and Contextual Text Styles). This could be represented as one property (e.g. Style) that has a cardinality of 1..* and references a Style Object (with style feature e.g. color). The association is implied by the object it belongs to.
A Text object is represented with a p element with the following constraints:
The text content of the paragraph can be structured using TTML elements such as
<br> or <span>
which can include TTML attributes such as tts:ruby used to alter the layout or styling of
sections of text within each paragraph.
Similarly metadata can be added using attributes or <metadata> elements.
Editor's note
Need to specify that <audio> elements are permitted too, for AD mixing.
The style attribute MAY be present.
If present, it MAY contain a reference to the <style> that defines the relevant Character Style.
Additional style references or inline styles MAY be used as defined in [TTML2],
and MAY be applied to sub-sections of the text defined by <span> elements.
The <p> element SHOULD have an xml:lang attribute corresponding to the language of the Text object.
Note
If a <p> element omits the xml:lang attribute then its computed language
is derived by inheritance from its parent element, and so forth up to the root <tt> element,
which is required to set the Primary Language via its xml:lang attribute.
Care should be taken if changing the Primary Language of a Document Instance in case
doing so affects descendant elements unexpectedly.
Authors can mitigate this risk by explicitly setting xml:lang on all <p> elements.
Note
Within a <div> representing a Script Event
the order of <p> children is significant.
<divxml:id="event_3"begin="9663f"end="9682f"style="style_a"ttm:agent="character_3"><pxml:lang="pt-BR"daptm:langSrc="original" >Você vai ter.</p><pxml:lang="fr"daptm:langSrc="translation" >Bah, il arrive.</p></div>
4.5 Text Language Source
The Text Language Source property is an annotation indicating whether a Text object is
in the same language as the relevant part of the Related Media Object's
language (original), or if it is a representation in another language (translation):
Translation - the Text is a representation of the Original language text in a different language.
Note
The Text Language Source property is represented as a daptm:langSrc attribute with the following constraints:
Editor's note
Should we use an abbreviated attribute name?
Editor's note
Initial design is to use an abbreviated name and original|translation,
though I considered using an abbreviated value too, since this attribute will appear on every <p> element.
Abbreviating O for Original is probably a bad idea because the letter O and the number 0 can easily be confused.
I also considered P for Primary but that caused potential confusion between Primary Language and Primary Text Language Source.
daptm:langSrc
: "original"
| "translation"
4.6 On Screen
The On Screen property is an annotation indicating the position in the scene of the character during the Script Event:
ON - the character is on screen for the entire duration
OFF - the character is off screen for the entire duration
ON_OFF - the character starts on screen, but goes off screen at some point
OFF_ON - the character starts off screen, but goes on screen at some point
The On Screen property is represented as a metadata element with the following constraints:
The following attribute corresponding to the On ScreenScript Event property may be present:
The predefined entities are (including the leading ampersand and trailing semicolon):
& for an ampersand &
' for an apostrophe '
> for a greater than sign >
< for a less than sign <
" for a quote symbol "
Note
A Document Instance can also be used as an in-memory model
for processing, in which case the serialisation requirements do not apply.
5.2 Foreign Elements and Attributes
A Document InstanceMAY contain elements and attributes that are neither specifically permitted nor forbidden by a profile.
Note
Document Instances remain subject to the content conformance requirements specified at Section 3.1 of [TTML2].
In particular, a Document Instance can contain elements and attributes not in any TT namespace, i.e. in foreign namespaces, since such elements and attributes are pruned by the algorithm at Section 4 of [TTML2] prior to evaluating content conformance.
Note
For validation purposes it is good practice to define and use a content specification for all foreign namespace elements and attributes used within a Document Instance.
Many dubbing and audio description workflows permit annotation of Script Events or documents with proprietary metadata.
Metadata vocabulary defined in this specification or in [TTML2] MAY be included.
Additional vocabulary in other namespaces MAY also be included.
Note
It is possible to add information such as the title of the programme using [TTML2] constructs.
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/metadata-ttml2.xml</pre></body></html>
Note
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.
<!DOCTYPE html><htmllang="en"><head><metacharset="utf-8"><title>Error</title></head><body><pre>Cannot GET /uploads/9wY0pR/examples/metadata-proprietary.xml</pre></body></html>
5.3 Namespaces
The following namespaces (see [xml-names]) are used in this specification:
The namespace prefix values defined above are for convenience and Document InstancesMAY use any prefix value that conforms to [xml-names].
The namespaces defined by this proposal document are mutable [namespaceState]; all undefined names in these namespaces are reserved for future standardization by the W3C.
5.4 Related Video Object
A Document InstanceMAY be associated with a Related Video Object, i.e. a Related Media Object that consists of a sequence of image frames, each a rectangular array of pixels.
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.
EXAMPLE 1
A media time expression of 00:00:05.1 corresponds to frame ceiling( 5.1 × ( 1000 / 1001 × 30) ) = 153 of a Related Video Object with a frame rate of 1000 / 1001 × 30 ≈ 29.97.
Note
In typical scenario, the same video program (the Related Video Object) will be used for Document Instance authoring, delivery and user playback.
The mapping from media time expression to Related Video Object above allows the author to precisely associate audio description content with video frames, e.g. around existing audio dialogue and sound effects.
In circumstances where the video program is downsampled during delivery, the application can specify that, at playback, the relative video object be considered the delivered video program upsampled to is original rate, thereby allowing audio content to be presented at the same temporal locations it was authored.
5.6 Profile Signaling
TTML documents representing DAPT Scripts MUST specify a ttp:contentProfiles attribute
on the tt element with one value equal to the designator of the DAPT 1.0 profile
to which the Document Instance conforms.
Other values MAY be present to declare conformance to other profiles of [TTML2].
5.6.1 Profile Designator
This profile is associated with the following profile designator:
Profile Name
Profile Designator
DAPT 1.0
http://www.w3.org/ns/ttml/profile/dapt
5.7 Timing constraints
Within a DAPT Script, the following constraints apply in relation to time attributes and time expressions:
5.7.1 ttp:timeBase
The only permitted ttp:timeBase value is media,
since 5.8 Features 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.
5.7.2 timeContainer
The only permitted value of the timeContainer attribute is the default value, par.
Documents SHOULD omit the timeContainer attribute on all elements.
Documents MUST NOT set the timeContainer attribute to any value other than par on any element.
Note
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.
5.7.3 ttp:frameRate
If the document contains any time expression that uses the f metric,
or any time expression that contains a frames component,
the ttp:frameRate attribute MUST be present on the <tt> element.
5.7.4 ttp:tickRate
If the document contains any time expression that uses the t metric,
the ttp:tickRate attribute MUST be present on the <tt> element.
5.7.5 #time-clock-with-frames
This section is non-normative.
As specified in [ttml2], a #time-clock-with-frames expression is translated to
a media time M according to
M = 3600 · hours + 60 · minutes + seconds + (frames ÷ (ttp:frameRateMultiplier · ttp:frameRate)).
Note
For example, the expression 01:23:45:15,
where ttp:frameRate="25" and ttp:frameRateMultiplier is unspecified,
and therefore the default of 1, is equivalent to a media time
All time expressions within a document SHOULD use the same syntax,
either clock-time or offset-time
as defined in [ttml2].
Note
A clock-time has one of the forms:
hh:mm:ss.sss
hh:mm:ss
hh:mm:ss:ff
hh:mm:ss:ff.x
where
hh is hours,
mm is minutes,
ss is seconds,
ss.sss is seconds with a decimal fraction of seconds (any precision),
ff is frames, and
x is sub-frames.
Note
An offset-time has one of the forms:
nn metric
nn.nn metric
where
nn is an integer,
nn.nn is a number with a decimal fraction (any precision), and
metric is one of:
h for hours,
m for minutes,
s for seconds,
ms for milliseconds,
f for frames, and
t for ticks.
5.8 Features
See Conformance for a definition of permitted, prohibited and optional.
Editor's note
Intent is to make it as easy as possible to transform a Document Instance into
IMSC ([ttml-imsc1.2]), so we need to check that there are no IMSC permitted Features that we prohibit, or if there
are, then we can explain the reason.
Editor's note
Editorial task: go through this list of features and check the disposition of each. IMSC-only features should be optional.
This specification does not put additional constraints on the layout and rendering features defined in [ttml-imsc1.2].
Note
Layout of the paragraphs may rely on the default TTML region (i.e. if no layout is used in the head element) or may be explicit by the use of the region attribute, if a region element is defined in a layout element in the head element.
6. Conformance
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.
Profile 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.
MUST satisfy all normative provisions specified by the profile;
MAY include any vocabulary, syntax or attribute value associated with a Feature whose disposition is permitted or optional in the profile;
MUST include any vocabulary, syntax or attribute value associated with a Feature whose disposition is required in the profile.
MUST NOT include any vocabulary, syntax or attribute value associated with a Feature whose disposition is prohibited in the profile.
Note
A Document Instance, by definition, satisfies the requirements of Section 3.1 at [TTML2], and hence a Document Instance that conforms to a profile defined herein is also a conforming TTML2 Document Instance.
MUST satisfy the Generic Processor Conformance requirements at Section 3.2.1 of [TTML2]
MUST satisfy all normative provisions specified by the profile; and
MUST implement presentation semantic support for every Feature designated as permitted or required by the profile, subject to any additional constraints on each Feature as specified by the profile.
MAY implement presentation semantic support for every Feature designated as optional by the profile, subject to any additional constraints on each Feature as specified by the profile.
MUST satisfy the Generic Processor Conformance requirements at Section 3.2.1 of [TTML2];
MUST satisfy all normative provisions specified by the profile; and
MUST implement transformation semantic support for every Feature designated as permitted or required by the profile, subject to any additional constraints on each Feature as specified by the profile.
MAY implement transformation semantic support for every Feature designated as optional by the profile, subject to any additional constraints on each Feature as specified by the profile.
Note
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.
Note
This document does not specify presentation processor or transformation processor behavior when processing or transforming a non-conformant Document Instance.
Note
The permitted and prohibited dispositions do not refer to the specification of a ttp:feature or ttp:extension element as being permitted or prohibited within a ttp:profile element.
Since 5.6 Profile Signaling imposes constraints on profile signalling,
by requiring the presence of the ttp:contentProfiles attribute,
the algorithm for profile resolution can be simplified.
For the purpose of content processing,
the determination of the resolved profile SHOULD take into account both the signaled profile,
as defined in 5.6 Profile Signaling, and profile metadata,
as designated by either (or both) the Document Interchange Context or (and) the Document Processing Context,
which MAY entail inspecting document content.