W3C TRopen access

2025

W3C · w3c_tr

W3C TR · Standards · License: Open Access

w3c, standard

Dubbing and Audio description Profiles of TTML2 W3C Candidate Recommendation Snapshot 18 December 2025 More details about this document This version: https://www.w3.org/TR/2025/CR-dapt-20251218/ Latest published version: https://www.w3.org/TR/dapt/ Latest editor's draft: https://w3c.github.io/dapt/ History: https://www.w3.org/standards/history/dapt/ Commit history Implementation report: https://www.w3.org/wiki/TimedText/DAPT_Implementation_Report Editors: Cyril Concolato ( Netflix ) Nigel Megitt ( British Broadcasting Corporation ) Feedback: GitHub w3c/dapt ( pull requests , new issue , open issues ) [email protected] with subject line [dapt] … message topic … ( archives ) Copyright © 2025 World Wide Web Consortium . W3C ® liability , trademark and document use rules apply. Abstract This specification defines DAPT , a TTML -based file format for the exchange of timed text content in transcription and translation workflows used in the production of dubbing scripts, audio description, translation subtitles and hard of hearing subtitles (also known as closed captions). Status of This Document 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 standards and drafts index . 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 H. Registry Section . Please see the Working Group's implementation report . For this specification to exit the CR stage, at least 2 independent implementations of every feature defined in this specification but not already present in [ TTML2 ] need to be documented in the implementation report. The Working Group does not require that implementations are publicly available but encourages them to be so. A list of the substantive changes applied since the initial Working Draft is found at substantive-changes-summary.txt . The Working Group has identified the following at risk features: Issue 218 : At-risk: support for `src` attribute in `<audio>` for external resource CR-exit-must-have At risk feature Possible resolution to #113 . Issue 219 : At-risk: support for `<source>` element child of `<audio>` for external resource CR-exit-must-have At risk feature Possible resolution to #113 . Issue 220 : At-risk: support for `src` attribute of `<audio>` element pointing to embedded resource CR-exit-must-have At risk feature 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 . Issue 221 : At-risk: support for `<source>` child of `<audio>` element pointing to embedded resource CR-exit-must-have At risk feature 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 . Issue 222 : At-risk: support for inline audio resources CR-exit-must-have At risk feature Possible resolution to #115 . Issue 223 : At-risk: each of the potential values of `encoding` in `<data>` CR-exit-must-have At risk feature Possible resolution to #117 . Issue 224 : At-risk: support for the `length` attribute on `<data>` CR-exit-must-have At risk feature Possible resolution to #117 . Issue 239 : At-risk: Nested Div (was Script Event Grouping) and Script Event Mapping CR-exit-must-have At risk feature Support for the #nested-div (was #scriptEventGrouping ) and #scriptEventMapping features, together, is at risk pending implementer feedback. At risk features may be removed before advancement to Recommendation. This document was published by the Timed Text Working Group as a Candidate Recommendation Snapshot using the Recommendation track . Publication as a Candidate Recommendation does not imply endorsement by W3C and its Members. A Candidate Recommendation Snapshot has received wide review , is intended to gather implementation experience , and has commitments from Working Group members to royalty-free licensing for implementations. Future updates to this upcoming Recommendation may incorporate new features . This Candidate Recommendation is not expected to advance to Recommendation any earlier than 15 January 2026. 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 that 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 18 August 2025 W3C Process Document . Table of Contents Abstract Status of This Document 1. Scope 2. Introduction 2.1 Transcripts and Scripts 2.1.1 Dubbing scripts 2.1.2 Audio Description scripts 2.1.3 Other uses 2.2 Example documents 2.2.1 Basic document structure 2.2.2 Audio Description Examples 2.2.3 Dubbing Examples 3. Documentation Conventions 4. DAPT Data Model and corresponding TTML syntax 4.1 DAPT Script 4.1.1 Script Represents 4.1.2 Default Language 4.1.3 Script Type 4.1.4 Script Events 4.1.5 Characters 4.1.6 Shared properties and Value Sets 4.1.6.1 Timing Properties 4.1.6.2 <content-descriptor> values 4.1.6.3 Unique identifiers 4.2 Character 4.3 Script Event 4.4 Text 4.5 Text Language Source 4.6 On Screen 4.7 Represents 4.8 Script Event Description 4.9 Audio 4.9.1 Audio Recording 4.9.2 Synthesized Audio 4.10 Mixing Instruction 5. Constraints 5.1 Document Encoding 5.2 Processing of unrecognised or foreign elements and attributes 5.2.1 Unrecognised vocabulary 5.2.2 Special considerations for foreign vocabulary 5.2.3 Proprietary Metadata and Foreign Vocabulary 5.2.3.1 Defining and using foreign vocabulary that is not metadata 5.3 Namespaces 5.4 Related Media Object 5.5 Synchronization 5.6 Profile Signaling 5.6.1 Profile Designators 5.6.2 ttp:contentProfiles 5.6.3 ttp:profile 5.6.4 ttp:processorProfiles 5.6.5 Other TTML2 Profile Vocabulary 5.7 Timing constraints 5.7.1 ttp:timeBase 5.7.2 timeContainer 5.7.3 ttp:frameRate 5.7.4 ttp:tickRate 5.7.5 Time expressions 5.8 Layout and styles 5.9 Bidirectional text 6. Mapping from TTML to the DAPT Data Model 6.1 Early identification of non-conformant documents 6.2 Not supporting features excluded by the content profile 6.3 Handling <div> and <p> elements 6.4 Using computed attribute values 6.5 Considerations for transformation and validation processors 6.5.1 Retaining unrecognised vocabulary 6.5.2 Validation warnings and errors 7. Conformance 7.1 Conformance of DAPT Documents 7.2 Conformance of DAPT Processors A. Index A.1 Terms defined by this specification A.2 Terms defined by reference B. Privacy Considerations B.1 Personal Information B.2 Audio format preference C. Security Considerations D. Timecode-related metadata D.1 DAPT Origin Timecode D.2 Start of Programme Timecode E. Audio Mixing E.1 Web Audio E.2 Pop prevention F. Profiles F.1 Disposition of Features and Extensions F.2 DAPT Content Profile F.3 DAPT Processor Profile G. Extensions G.1 General G.2 #agent G.3 #contentProfiles-root G.4 #daptOriginTimecode G.5 #descType G.6 #onScreen G.7 #profile-root G.8 #represents G.9 #scriptEventMapping G.10 #scriptRepresents-root G.11 #scriptType-root G.12 #serialization G.13 #source-data G.14 #textLanguageSource G.15 #xmlLang-audio-nonMatching G.16 #xmlLang-root H. Registry Section H.1 Registry Definition H.1.1 Custodianship H.1.2 Change Process H.1.2.1 Requesting a change H.1.2.2 Change request assessment process H.1.2.2.1 Custodian is TTWG H.1.2.2.2 Custodian is the W3C Team H.1.3 Registry Table Constraints H.1.3.1 Registry Entries H.1.3.1.1 Status H.1.3.1.1.1 Provisional H.1.3.1.1.2 Final H.1.3.1.1.3 Deprecated H.2 Registry Table Definitions H.2.1 daptm:descType registry table definition H.2.2 <content-descriptor> registry table definition I. Acknowledgments J. References J.1 Normative references J.2 Informative references 1. Scope This specification defines a text-based profile of the Timed Text Markup Language version 2.0 [ TTML2 ] intended to support dubbing and audio description workflows worldwide, to meet the requirements defined in [ DAPT-REQS ], and to permit usage of visual presentation features within [ TTML2 ] and its profiles, for example those in [ TTML-IMSC1.2 ]. 2. Introduction This section is non-normative. 2.1 Transcripts and Scripts In general usage, one meaning of the word script is the written text of a film, television programme, play etc. A script can be either a record of the completed production, also known as a transcript, or as a plan for a yet to be created production. In this document, we use domain-specific terms, and define more specifically that: a transcript is the text representation of pre-existing media in another form, for example the dialogue in a video; a script is a text representation of the intended content of media prior to its creation, for example to guide an actor in recording an audio track. The term DAPT script is used generically to refer to both transcripts and scripts , and is a point of conformance to the formal requirements of this specification. DAPT Scripts consist of timed text and associated metadata, such as the character speaking. In dubbing workflows, a transcript is generated and translated to create a script . In audio description workflows, a transcript describes the video image, and is then used directly as a script for recording an audio equivalent. DAPT is a TTML -based format for the exchange of transcripts and scripts (i.e. DAPT Scripts ) among authoring, prompting and playback tools in the localization and audio description pipelines. A DAPT document is a serializable form of a DAPT Script designed to carry pertinent information for dubbing or audio description such as type of DAPT script , dialogue, descriptions, timing, metadata, original language transcribed text, translated text, language information, and audio mixing instructions, and to be extensible to allow user-defined annotations or additional future features. This specification defines the data model for DAPT scripts and its representation as a [ TTML2 ] document (see 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. Every part of the DAPT script content is required to be marked up with some indication of what it represents in the related media, via the Represents property; likewise the DAPT Script as a whole is required to list all the types of content that it represents, for example if it represents audio content or visual content, and if visual, then if it represents text or non-text etc. A registry of hierarchical content descriptors is provided. The authoring workflow for both dubbing and audio description involves similar stages, that share common requirements as described in [ DAPT-REQS ]. In both cases, the author reviews the content and writes down what is happening, either in the dialogue or in the video image, alongside the time when it happens. Further transformation processes can change the text to a different language and adjust the wording to fit precise timing constraints. Then there is a stage in which an audio rendering of the script is generated, for eventual mixing into the programme audio. That mixing can occur prior to distribution, or in the player directly. 2.1.1 Dubbing scripts The dubbing process which consists in creating a dubbing script is a complex, multi-step process involving: Transcribing and timing the dialogue in its own language from a completed programme to create a transcript ; Notating dialogue with character information and other annotations; Generating localization notes to guide further adaptation; Translating the dialogue to a target language script ; Adapting the translation to the dubbing; for example matching the actor’s lip movements in the case of dubs. A dubbing script is a transcript or script (depending on workflow stage) used for recording translated dialogue to be mixed with the non-dialogue programme audio, to generate a localized version of the programme in a different language, known as a dubbed version, or dub for short. Dubbing scripts can be useful as a starting point for creation of subtitles or closed captions in alternate languages. This specification is designed to facilitate the addition of, and conversion to, subtitle and caption documents in other profiles of TTML , such as [ TTML-IMSC1.2 ], for example by permitting subtitle styling syntax to be carried in DAPT documents . Alternatively, styling can be applied to assist voice artists when recording scripted dialogue. 2.1.2 Audio Description scripts Creating audio description content is also a multi-stage process. An audio description , also known as video description or in [ media-accessibility-reqs ] as described video , is an audio service to assist viewers who can not fully see a visual presentation to understand the content. It is the result of mixing the main programme audio with the audio rendition of each description , authored to be timed when it does not clash with dialogue, to deliver an audio description mixed audio track. Main programme audio refers to the audio associated with the programme prior to any further mixing. A description is a set of words that describes an aspect of the programme presentation, suitable for rendering into audio by means of vocalisation and recording or used as a text alternative source for text to speech translation, as defined in [ WCAG22 ]. More information about what audio description is and how it works can be found at [ BBC-WHP051 ]. Writing the audio description script typically involves: watching the video content of the programme, or series of programmes, identifying the key moments during which there is an opportunity to speak descriptions, writing the description text to explain the important visible parts of the programme at that time, creating an audio version of the descriptions, either by recording a human actor or using text to speech, defining mixing instructions (applied using [ TTML2 ] audio styling) for combining the audio with the programme audio. The audio mixing can occur prior to distribution of the media, or in the client. If the audio 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. 2.1.3 Other uses DAPT Scripts can be useful in other workflows and scenarios. For example, Original language transcripts could be used as: the output format of a speech to text system, even if not intended for translation, or for the production of subtitles or captions; a document known in the broadcasting industry as a "post production script", used primarily for preview, editorial review and sales purposes; Both Original language transcripts and Translated transcripts could be used as: an accessible transcript presented alongside audio or video in a web page or application; in this usage, the timings could be retained and used for synchronization with, or navigation within, the media or discarded to present a plain text version of the entire timeline. 2.2 Example documents 2.2.1 Basic document structure The top level structure of a document is as follows: The <tt> root element in the namespace http://www.w3.org/ns/ttml indicates that this is a TTML document and the ttp:contentProfiles attribute indicates that it adheres to the DAPT content profile defined in this specification. The daptm:scriptRepresents attribute indicates what the contents of the document are an alternative for, within the original programme. The daptm:scriptType attribute indicates the type of transcript or script but in this empty example, it is not relevant, since only the structure of the document is shown. The daptm:langSrc attribute indicates the default text language source, for example the original language of the content, while the xml:lang attribute indicates the default language in this script, which in this case is the same. Both of these attributes are inherited and can be overridden within the content of the document. The structure is applicable to all types of DAPT scripts , dubbing or audio description . Example 1 < 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:scriptRepresents = "audio" daptm:scriptType = "originalTranscript" > < head > < metadata >   </ metadata > < styling >  </ styling > < layout >  </ layout > </ head > < body >  < div xml:id = "d1" begin = "..." end = "..." daptm:represents = "audio.dialogue" > < p >  </ p > < p xml:lang = "fr" daptm:langSrc = "en" >  </ p > </ div > </ 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; the daptm:represents attribute present on the <body> element here is inherited by the <div> elements since they do not specify a different value: Example 2 ... < body daptm:represents = "..." > < div xml:id = "id1" begin = "10s" end = "13s" > </ div > < div xml:id = "id2" begin = "18s" end = "20s" > </ div > </ body > ... The following examples will demonstrate different uses in dubbing and audio description workflows. 2.2.2 Audio Description Examples When descriptions are added this becomes a Pre-Recording Script . Note that in this case, to reflect that most of the audio description content transcribes the video image where there is no inherent language, the Text Language Source , represented by the daptm:langSrc attribute, is set to zxx at the top level of the document, which is a language code defined by [ bcp47 ] as identifying content for which a language classification does not apply: Example 3 < 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 = "zxx" daptm:scriptRepresents = "visual.nonText" daptm:scriptType = "preRecording" > < body > < div begin = "10s" end = "13s" xml:id = "a1" daptm:represents = "visual.nonText" > < p > A woman climbs into a small sailing boat. </ p > </ div > < div begin = "18s" end = "20s" xml:id = "a2" daptm:represents = "visual.nonText" > < p > The woman pulls the tiller and the boat turns. </ p > </ div > </ body > </ tt > Audio description content often includes text present in the visual image, for example if the image contains a written sign, a location, etc. The following example demonstrates such a case: Script Represents is extended to show that the script 's contents represent textual visual information in addition to non-textual visual information. Here a more precise value of Represents is specified on the Script Event to reflect that the text is in fact a location, which is allowed because the more precise value is a sub-type of the new value in Script Represents . Finally, since the text has an inherent language, the Text Language Source is set to reflect that language. Example 4 < 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 = "zxx" daptm:scriptRepresents = "visual.nonText visual.text" daptm:scriptType = "preRecording" > < body > < div begin = "7s" end = "8.5s" xml:id = "at1" daptm:represents = "visual.text.location" daptm:langSrc = "en" > < p > The Lake District, England </ p > </ div > < div begin = "10s" end = "13s" xml:id = "a1" daptm:represents = "visual.nonText" > < p > A woman climbs into a small sailing boat. </ p > </ div > < div begin = "18s" end = "20s" xml:id = "a2" daptm:represents = "visual.nonText" > < 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: Example 5 < tt ... daptm:scriptRepresents = "visual.nonText" daptm:scriptType = "asRecorded" xml:lang = "en" daptm:langSrc = "zxx" > ... < div begin = "25s" end = "28s" xml:id = "a3" daptm:represents = "visual.nonText" > < 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 > ... At the document level, the daptm:scriptRepresents attribute indicates that the document represents both visual text and visual non-text content in the related media. It is possible that there are no Script Events that actually represent visual text, for example because there is no text in the video image. In the above example, the <div> element's begin attribute defines the time that is the "syncbase" for its child, so the times on the <animate> and <span> elements are relative to 25s here. The first <animate> element drops the gain from 1 to 0.39 over 0.3s, freezing that value after it ends, and the second one raises it back in the final 0.3s of this description. Then the <span> element is timed to begin only after the first audio dip has finished. If the audio recording is long and just a snippet needs to be played, that can be done using clipBegin and clipEnd . If we just want to play the part of the audio from file from 5s to 8s it would look like: Example 6 ... <span><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: Example 7 ... < div begin = "18s" end = "20s" xml:id = "a2" > < 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: Example 8 ... < div begin = "25s" end = "28s" xml:id = "a3" > < 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 > ... 2.2.3 Dubbing Examples 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 daptm:langSrc attributes respectively, which have the same value because the transcript is not translated. Example 9 < 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:scriptRepresents = "audio.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" xml:id = "d1" daptm:represents = "audio.dialogue" > < 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 daptm:langSrc attributes are used to mark the text as being original or translated. In this case, they are present on both the <tt> and <p> elements to make the example easier to read, but it would also be possible to omit them in some cases, making use of the inheritance model: Example 10 < 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:scriptRepresents = "audio.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" xml:id = "d1" ttm:agent = "character_1" daptm:represents = "audio.dialogue" > < 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 > 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: Example 11 < 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:scriptRepresents = "audio.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" xml:id = "d1" ttm:agent = "character_1" daptm:onScreen = "ON_OFF" daptm:represents = "audio.dialogue" > < 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 > 3. Documentation Conventions This document uses the following conventions: When referring to an [ XML ] element in the prose, angled brackets and a specific style are used as follows: <someElement> . The entity is also described as an element in the prose. If the name of an element referenced in this specification is not namespace qualified, then the TT namespace applies (see Namespaces ). When referring to an [ XML ] attribute in the prose, the attribute name is given with its prefix, if its namespace has a value, or without a prefix if its namespace has no value. Attributes with prefixes are styled as attributePrefix:attributeName and those without prefixes are styled as attributeName . The entity is also described as an attribute in the prose. When defining new [ XML ] attributes, this specification uses the conventions used for "value syntax expressions" in [ TTML2 ]. For example, the following would define a new attribute called daptm:foo as a string with two possible values: bar and baz . daptm:foo : "bar" | "baz" When referring to the position of an element or attribute in the [ XML ] document, the [ XPath ] LocationPath notation is used. For example, to refer to the first <metadata> element child of the <head> element child of the <tt> element, the following path would be used: /tt/head/metadata[0] . Registry sections that include registry table data are indicated as follows: Content in registry table sections has different requirements for updates than other Recommendation track content, as defined in [ w3c-process ]. 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, 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 ]. DAPT Script Script Represents Script Type Default Language (optional) Text Language Source Character Character Identifier Name (optional) Talent Name Script Event Script Event Identifier Represents (optional) Begin (optional) End (optional) Duration (optional) On Screen Script Event Description Description (optional) Description Type (optional) Language Text Text content (optional) Text Language Source (optional) Language (optional) Represents Audio Synthesized Audio Rate (optional) Pitch Audio Recording Source [ ] Type [ ] (optional) Begin (optional) End (optional) Duration (optional) In Time (optional) Out Time Mixing Instruction (optional) Gain (optional) Pan (optional) Begin (optional) End (optional) Duration (optional) Fill contains 0..* contains 0..* contains 0..* contains 0..* contains 0..* 0..* 0..* contains 0..* contains 0..* contains 0..* is is Figure 1 (Informative) Class diagram showing main entities in the DAPT data model. Issue 116 : Add non-inlined embedded audio resources to the Data Model? question CR-exit-must-have 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? 4.1 DAPT Script A DAPT Script is a transcript or script that corresponds to a document processed within an authoring workflow or processed by a client, and conforms to the constraints of this specification. It has properties and objects defined in the following sections: Script Represents , Script Type , Default Language , Text Language Source , Script Events and, for Dubbing Scripts , Characters . A DAPT Document is a [ TTML2 ] timed text content document instance representing a DAPT Script . A DAPT Document has the structure and constraints defined in this and the following sections. Note A [ TTML2 ] timed text content document instance has a root <tt> element in the TT namespace. 4.1.1 Script Represents The Script Represents property is a mandatory property of a DAPT Script which indicates which components of the related media object the contents of the document represent. The contents of the document could be used as part of a mechanism to provide an accessible alternative for those components. Note Script Events have a related property, Represents , and there are constraints about the permitted values of that property that are dependent on the values of Script Represents . To represent this property, the daptm:scriptRepresents attribute MUST be present on the <tt> element, with a value conforming to the following syntax: daptm:scriptRepresents : < content-descriptor > ( <lwsp>+ <content-descriptor>)* <lwsp> # as TTML2 Example 12 A dubbing script might have daptm:scriptRepresents="audio.dialogue" . An audio description script might have daptm:scriptRepresents="visual.nonText visual.text visual.dialogue" . A post-production script that could be the precursor to a hard of hearing subtitle document might have daptm:scriptRepresents="audio.dialogue audio.nonDialogueSounds" . 4.1.2 Default Language The Default Language is a mandatory property of a DAPT Script which represents the default language for the Text content of Script Events . This language may be one of the original languages or a Translation language. When it represents a Translation language, it may be the final language for which a dubbing or audio description script is being prepared, called the Target Recording Language or it may be an intermediate, or pivot, language used in the workflow. The Default Language is represented in a DAPT Document by the following structure and constraints: the xml:lang attribute MUST be present on the <tt> element and its value MUST NOT be empty. Note 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. Example 13 An Original Language Transcript of dialogue is prepared for a video containing dialogue in Danish and Swedish. The Default Language is set to Danish by setting xml:lang="da" on the <tt> element. Script Events that contain Swedish Text override this by setting xml:lang="sv" on the <p> element. Script Events that contain Danish Text can set the xml:lang attribute or omit it, since the inherited language is the Default Language of the document. In both cases the Script Events' Text objects are <p> elements that represent untranslated content that had an inherent language (in this case dialogue) and therefore set the daptm:langSrc attribute to their source language, implying that they are in the Original language. 4.1.3 Script Type The Script Type property is a mandatory property of a DAPT Script which describes the type of documents used in Dubbing and Audio Description workflows, among the following: Original Language Transcript , Translated Transcript , Pre-recording Script , As-recorded Script . To represent this property, the daptm:scriptType attribute MUST be present on the <tt> element: daptm:scriptType : "originalTranscript" | "translatedTranscript" | "preRecording" | "asRecorded" The definitions of the types of documents and the corresponding daptm:scriptType attribute values are: Original Language Transcript : When the daptm:scriptType attribute value is originalTranscript , the document is a literal transcription of the dialogue and/or on-screen text in their inherent spoken/written language(s), or of non-dialogue sounds and non-linguistic visual content. Script Events in this type of transcript : SHOULD contain Original Text objects; SHOULD NOT contain Translation Text objects. Example 14 If a programme contains dialogue in English and Hebrew, the Original Language Transcript will contain some Script Events in English and some in Hebrew, all containing Original Text objects. The document contains no Translation Text objects. Translated Transcript : 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; MAY also contain Original Text objects. Example 15 If a programme contains dialogue in English and Hebrew, the French Translated Transcript will contain at least the translation in French of all Script Events . It may still retain text content in Hebrew and English to assist further processing. Example 16 If an audio description Original Language Transcript contains Original language Script Events that describe in-image text content, and the desired audio description output needs to be in a different language, the Text objects can be Translation Text objects. In that case, it is appropriate to mark the transcript as a Translated Transcript . It may also be appropriate, as part of the translation activity, to describe within the translated text content the original language of that text, to inform the audience, for example, "A Japanese newspaper headline that means: sailor completes ocean crossing". Pre-recording Script : 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 ; 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; SHOULD NOT contain Audio objects. Note The Script Type of a DAPT Script cannot necessarily be detected by inspecting the text content of the document. For example, the adaptation of a Translated Transcript into a Pre-recording Script can consist in replacing some words in the text content of a Script Event without altering the rest of the document. In either case, Translation Text objects have their Text Language Source properties set to the source language from which they were translated. Note The Original Text objects in Audio Description Script Events have an empty Text Language Source property if they represent visual elements of the scene that do not have an inherent language. Otherwise if they do represent visual elements with an inherent language, such as in-image text, they are required to have a Text Language Source that specifies a language. If audio description scripts are translated, their translations would be represented by Translation Text objects. As-recorded Script : 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 ; MAY also contain Original Text objects from the Original Language Transcript or Translation Text objects in other languages for context and quality verification; MAY also contain links to audio and mixing instructions for the purpose of producing an audio track incorporating the recordings; SHOULD contain Audio Recording objects; SHOULD NOT contain Synthesized Audio objects. Note Translation Text objects within As-recorded Scripts retain their Text Language Source , so that the source language from which they were translated remains available. Editor's note The following example is orphaned - move to the top of the section, before the enumerated script types? Example 17 < tt daptm:scriptType = "originalTranscript" > ... </ tt > 4.1.4 Script Events A DAPT Script MAY contain zero or more Script Event objects, each corresponding to dialogue, on screen text, or descriptions for a given time interval. If any Script Events are present, the DAPT Document MUST have one <body> element child of the <tt> element. 4.1.5 Characters 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. Note 4.2 Character recommends that all the Character objects be located within a single <metadata> element parent, and in the case that there are more than one <metadata> element children of the <head> element, that the Character objects are located in the first such child. 4.1.6 Shared properties and Value Sets Some of the properties in the DAPT data model are common within more than one object type, and carry the same semantic everywhere they occur. These shared properties are listed in this section. Some of the value sets in DAPT are reused across more than one property, and have the same constraints everywhere they occur. These shared value sets are also listed in this section. Editor's note Would it be better to make a "Timed Object" class and subclass Script Event, Mixing Instruction and Audio Recording from it? 4.1.6.1 Timing Properties The following timing properties define when the entities that contain them are active: The Begin property defines when an object becomes active, and is relative to the active begin time of the parent object. DAPT Scripts begin at time zero on the media timeline. The End property defines when an object stops being active, and is relative to the active begin time of the parent object. The Duration property defines the maximum duration of an object. Note If both an End and a Duration property are present, the end time is the earlier of End and Begin + Duration , as defined by [ TTML2 ]. Note If any of the timing properties is omitted, the following rules apply, paraphrasing the timing semantics defined in [ TTML2 ]: The default value for Begin is zero, i.e. the same as the begin time of the parent object. The default value for End is indefinite, i.e. it resolves to the same as the end time of the parent timed object, if there is one. The default value for Duration is indefinite, i.e. the end time resolves to the same as the end time of the parent object. Note The end time of a DAPT Script is for practical purposes the end of the Related Media Object . 4.1.6.2 <content-descriptor> values The values permitted in the Script Represents and Represents properties depend on the < content-descriptor > syntactic definition and its associated registry table. < content-descriptor > has a value conforming to the following syntax: <content-descriptor> # see registry table below : <descriptor-token> ( <descriptor-delimiter> <descriptor-token> )*

< descriptor-token > : (descriptorTokenChar)+

descriptorTokenChar # xsd:NMtoken without the "." : NameStartChar | "-" | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]

<descriptor-delimiter> : "." # FULL STOP U+002E < content-descriptor > has values that are delimiter separated ordered lists of tokens. A < content-descriptor > value B is a content descriptor sub-type ( sub-type ) of another <content-descriptor> value A if A's ordered list of descriptor-tokens is present at the beginning of B's ordered list of descriptor-tokens . Example 18 Table demonstrating example values of < content-descriptor > and whether each is a sub-type of the other. <content-descriptor> A <content-descriptor> B Is B a sub-type of A? visual.text visual No visual.text visual.text Yes visual.text visual.text.location yes For example, in this table, A could be one of the values listed in Script Represents property, and B could be the value of a Represents property. The permitted values for < content-descriptor > are either those listed in the following registry table , or can be user-defined. Valid user-defined values MUST begin with x- or be sub-types of values in the content-descriptor registry table, where the first additional < descriptor-token > component begins with x- . Registry table for the < content-descriptor > component whose Registry Definition is at H.2.2 <content-descriptor> registry table definition < content-descriptor > Status Description Example usage audio Provisional Indicates that the DAPT content represents any part of the audio programme. Dubbing, translation and hard of hearing subtitles and captions, pre- and post- production scripts audio.dialogue Provisional Indicates that the DAPT content represents verbal communication in the audio programme, for example, a spoken conversation. Dubbing, translation and hard of hearing subtitles and captions, pre- and post- production scripts audio.nonDialogueSounds Provisional Indicates that the DAPT content represents a part of the audio programme corresponding to sounds that are not verbal communication, for example, significant sounds, such as a door being slammed in anger. Translation and hard of hearing subtitles and captions, pre- and post- production scripts visual Provisional Indicates that the DAPT content represents any part of the visual image of the programme. Audio Description visual.dialogue Provisional Indicates that the DAPT content represents verbal communication, within the visual image of the programme, for example, a signed conversation. Dubbing or Audio Description, translation and hard of hearing subtitles and captions, pre- and post- production scripts visual.nonText Provisional Indicates that the DAPT content represents non-textual parts of the visual image of the programme, for example, a significant object in the scene. Audio Description visual.text Provisional Indicates that the DAPT content represents textual content in the visual image of the programme, for example, a signpost, a clock, a newspaper headline, an instant message etc. Audio Description visual.text.title Provisional A sub-type of visual.text where the text is the title of the related media. Audio Description visual.text.credit Provisional A sub-type of visual.text where the text is a credit, e.g. the name of an actor. Audio Description visual.text.location Provisional A sub-type of visual.text where the text indicates the location where the content is occurring. Audio Description Note The registry entries are available in JSON form in the version control system at /registries/content-descriptor.json . 4.1.6.3 Unique identifiers Some entities in the data model include unique identifiers. A Unique Identifier has the following requirements: it is unique within the DAPT Script , i.e. the value of a Unique Identifier can only be used one time within the document, regardless of which specific kind of identifier it is. If a Character Identifier has the value "abc" and a Script Event Identifier in the same document has the same value, that is an error. its value has to conform to the requirements of Name as defined by [ XML ] Note It cannot begin with a digit, a combining diacritical mark (an accent), or any of the following characters: . - · // #xB7 ‿ // #x203F ⁀ // #x2040 but those characters can be used elsewhere. A Unique Identifier for an entity is expressed in a DAPT Document by an xml:id attribute on the corresponding element. Note The formal requirements for the semantics and processing of xml:id are defined in [ xml-id ]. 4.2 Character This section is mainly relevant to Dubbing workflows. A character in the programme can be described using a Character object which has the following properties: a mandatory Character Identifier which is a Unique Identifier used to reference the character from elsewhere in the document, for example to indicate when a Character participates in a Script Event . a mandatory Name which is the name of the Character in the programme an optional Talent Name , which is the name of the actor speaking dialogue for this Character . A Character is represented in a DAPT Document by the following structure and constraints: The Character is represented in a DAPT Document by a <ttm:agent> element present at the path /tt/head/metadata/ttm:agent , with the following constraints: The type attribute MUST be set to character . The xml:id attribute MUST be present on the <ttm:agent> element and set to the Character Identifier . The <ttm:agent> element MUST contain a <ttm:name> element with its type attribute set to alias and its content set to the Character Name . If the Character has a Talent Name , it MUST contain a <ttm:actor> child element. That child element MUST have an agent attribute set to the value of the xml:id attribute of a separate <ttm:agent> element corresponding to the Talent Name , that is, whose type attribute is set to person . Note The requirement for an additional <ttm:agent> element corresponding to the Talent Name is defined in the following bullet list. Example 19 ... < metadata > < ttm:agent type = "character" xml:id = "character_1" > < ttm:name type = "alias" > DESK CLERK </ ttm:name > </ ttm:agent > </ metadata > ... Example 20 ... < metadata > < ttm:agent type = "person" xml:id = "actor_A" > < ttm:name type = "full" > Matthias Schoenaerts </ ttm:name > </ ttm:agent > < ttm:agent type = "character" xml:id = "character_2" > < ttm:name type = "alias" > BOOKER </ ttm:name > < ttm:actor agent = "actor_A" /> </ ttm:agent > </ metadata > ... If the Character has a Talent Name property: A <ttm:agent> element corresponding to the Talent Name MUST be present at the path /tt/head/metadata/ttm:agent , with the following constraints: its type attribute MUST be set to person its xml:id attribute MUST be set. it MUST have a <ttm:name> child element whose type MUST be set to full and its content set to the Talent Name If more than one Character is associated with the same Talent Name there SHOULD be a single <ttm:agent> element corresponding to that Talent Name , referenced separately by each of the Characters . Each <ttm:agent> element corresponding to a Talent Name SHOULD appear before any of the Character <ttm:agent> elements whose <ttm:actor> child element references it. All <ttm:agent> elements SHOULD be contained in the first <metadata> element in the <head> element. Note There can be multiple <metadata> elements in the <head> element, for example to include proprietary metadata but the above recommends that only one is used to define the characters. Editor's note The group is considering updating the rule(s) around which metadata element is used to carry DAPT information. The group would like to balance simplicity of implementation (e.g. locating the DAPT metadata in one place) vs. flexibility of authoring (e.g. having different metadata elements for series vs episodes). One approach is the current one: "only one metadata element, the first one". Another approach is "only one metadata element, identified by an attribute". Another approach is "any number of metadata elements". The group welcomes feedback from implementers and users. Note As indicated in 5.2.1 Unrecognised vocabulary , ttm:agent elements can have foreign attributes and elements. This can be used to provide additional, proprietary character information. Issue 44 : Define DAPT-specific conformant implementation types CR must-have 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. 4.3 Script Event A Script Event object represents dialogue, on screen text or audio descriptions to be spoken and has the following properties: A mandatory Script Event Identifier which is a Unique Identifier . An optional Begin property and an optional End and an optional Duration property that together define the Script Event 's time interval in the programme timeline Note Typically Script Events do not overlap in time. However, there can be cases where they do, e.g. in Dubbing Scripts when different Characters speak different text at the same time. A Represents property used to identify what content the event represents (e.g. dialogue, on screen text, etc.). Every Script Event MUST have a valid Represents property. Note The Represents property is inheritable, so the value does not need to be specified on every Script Event explicitly. Zero or more Character Identifiers indicating the Characters involved in this Script Event . Note While typically, a Script Event corresponds to one single Character , there are cases where multiple characters can be associated with a Script Event . This is when all Characters speak the same text at the same time. Note In a transcript , when the event corresponds to in-image content, for example an audio description , no Character Identifier is needed. However it may be helpful in a Pre-recording Script or an As-recorded Script context to indicate a Character signifying who voices the recording. Zero or more Text objects, each being either Original or Translation . Note A Script Event with no Text objects can be created as part of an initial phase of authoring, in workflows where it is helpful to block out the time intervals during which some content could be present. For example, an empty Script Event with timing properties can be created to identify an opportunity for creating an audio description. See also [ DAPT -REQS] Process Step 1 . Note Empty Text objects, i.e. ones that have no text content, can be used to indicate explicitly that there is no text content. It is recommended that empty Text objects are not used as a workflow placeholder to indicate incomplete work. zero or more Script Event Description objects, each being a human-readable description of the Script Event . an optional On Screen property, which is an annotation indicating the position of the subject (e.g. a character ) of the Script Event Zero or more Mixing Instruction objects used to adjust playback of the programme audio during the Script Event . A Script Event is represented in a DAPT Document at the path /tt/head/body//div , with the following structure and constraints: Issue 233 : Consider improving identification of divs corresponding to script events CR must-have Based on discussion at #216 (comment) , I think we should have an explicit signal to indicate when a div represents a Script Event. There MAY be any number of nested <div> element ancestors in the path between the <body> element and the <div> element corresponding to the Script Event . No further semantic is defined for such elements. There MUST be one <div> element corresponding to the Script Event , with the following constraints: The xml:id attribute MUST be present containing the Script Event Identifier . Note See 6.3 Handling <div> and <p> elements for details of how processors deal with <div> elements that do not have an xml:id attribute and are therefore not considered to be Script Events . The begin , end and dur attributes represent respectively the Begin , End and Duration of the Script Event . The begin and end attributes SHOULD be present. The dur attribute MAY be present. Note See 4.1.6.1 Timing Properties for additional notes on timing properties. The ttm:agent attribute MAY be present and if present, MUST contain a reference to each ttm:agent attribute that represents an associated Character . Note Multiple references are specified using a space-separated list. Example 21 ... < div xml:id = "event_1" begin = "9663f" end = "9682f" ttm:agent = "character_4" > ... </ div > ... The daptm:represents attribute MAY be present representing the Represents property. Example 22 ... < div xml:id = "event_1" begin = "9663f" end = "9682f" daptm:represents = "audio.dialogue" > ... </ div > ... The computed value of the the daptm:represents attribute MUST be a valid non-empty value. Note It is possible to specify the daptm:represents attribute on an ancestor element, since Represents is an inheritable property. It MAY contain zero or more <p> elements representing each Text object. It MAY contain a <metadata> element representing the On Screen property. It MUST NOT contain any <div> element children. 4.4 Text The Text object contains text content typically in a single language. This language may be the Original language or a Translation language. Text is defined as Original if it is any of: a transcription of dialogue in the programme audio, in the same language as that dialogue; a transcription of text visible in the programme video, in the same language as that text; an untranslated representation of non-dialogue sound; an untranslated description of the scene in the programme video; an untranslated representation of content whose language has not been determined (this is not recommended ); Note The language of an Original Text object can be different to the document's Default Language . Text is defined as Translation if it is a representation of an Original Text object in a different language. Text can be identified as being Original or Translation by inspecting its language and its Text Language Source together, according to the semantics defined in Text Language Source . The source language of Translation Text objects and, where applicable, Original Text objects is indicated using the Text Language Source property. If the Text object, or part of it, represents something more specific, or different, to its parent Script Event , it can have a different Represents property. The Text object, and every one of its parts, MUST have a valid Represents property. The presence of the property itself is considered optional because if the Text object omits the property then the property is inherited from the parent Script Event . Note Where possible, text representing different parts of the related media object should be put into Text objects in different Script Events each with their own Represents property. The option to assign Represents directly to Text objects or parts of Text objects is provided in case this is impractical. For example, consider a Script Event authored to describe both non-textual parts of the video image and visual text content, that is intended to be voiced in a single pass. If this were split into two or more Script Events then it would be necessary to assign an end time to the first one and a start time to the second one, which may not be simple. In this case the Text could be split instead, either into separate Text objects, or into sub-parts, each having their own distinct Represents property, thus maintaining accuracy. A Text object may be styled. Zero or more Mixing Instruction objects used to modify the programme audio during the Text MAY be present. A Text object is represented in a DAPT Document by a <p> element at the path /tt/head/body//div/p , with the following constraints: The Text of the Script Event is represented by the character content of the <p> element and of all of its <span> descendant elements, after <metadata> elements and foreign elements have been pruned, after replacing <br> elements by line breaks, and after applying White Space Handling as defined in [ XML ]. Note The text content of the paragraph can be structured using TTML elements such as <br> or <span> which can include or reference TTML style attributes such as tts:ruby used to alter the layout or styling of sections of text within each paragraph. Mixed direction text, for example interleaved left to right (ltr) and right to left (rtl) text, can be specified by using the tts:direction attribute on <span> elements. Similarly metadata can be added using attributes or <metadata> elements. The <p> element SHOULD have a daptm:langSrc attribute representing the Text object's Text Language Source , that is, indicating whether the Text is Original or a Translation and if its source had an inherent language. Note If a <p> element omits the daptm:langSrc attribute then its computed value is derived by inheritance from its parent element, and so forth up to the root <tt> element. In scripts that have very little variation in source language, the daptm:langSrc attribute can be set on the root element and omitted from <p> elements except where its value differs. Care should be taken if using this approach, especially when moving between Script Types , because changing it at the root element could affect the interpretation of descendant elements unexpectedly. In tools that allow fine-grained control, authors can mitigate this risk by explicitly setting the daptm:langSrc attribute on all <p> elements. Implementers should take care to ensure that, when changing the daptm:langSrc attribute on an element, they check down the tree and if appropriate specify the attribute on descendant elements so that their meaning does not change unintentionally. Note To represent content with no inherent language, for example an Original audio description where no in-image text is transcribed, the value zxx can be used. If that audio description is subsequently translated then the Translation would have a daptm:langSrc set to the xml:lang of the Original . The computed value of daptm:langSrc SHOULD NOT be the empty string or und . Note A document that does not specify the daptm:langSrc attribute at all has the default value of the empty string which implies that the language of the content represented by the Text has not been determined. 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 Default Language via its xml:lang attribute. Care should be taken if changing the Default Language of a DAPT Script in case doing so affects descendant elements unexpectedly. In tools that allow fine-grained control, authors can mitigate this risk by explicitly setting the xml:lang attribute on all <p> elements. Implementers should take care to ensure that, when changing the xml:lang attribute on an element, they check down the tree and if appropriate specify the attribute on descendant elements so that their meaning does not change unintentionally. Example 23 < div xml:id = "event_3" begin = "9663f" end = "9682f" ttm:agent = "character_3" > < p xml:lang = "pt-BR" > Você vai ter. </ p > < p xml:lang = "fr" daptm:langSrc = "pt-BR" > Bah, il arrive. </ p > </ div > Note In some cases, a single section of untranslated dialogue can contain text in more than one language. Rather than splitting a Script Event into multiple Script Events to deal with this, Text objects in one language can also contain some words in a different language. This is represented in a DAPT Document by setting the xml:lang and daptm:langSrc attributes on inner <span> elements. Note <span> elements can be used to add specific timing as illustrated in Example 10 to indicate the timing of the audio rendering of the relevant section of text. Per [ TTML2 ], timing of the <span> element is relative to the parent element's computed begin time. The daptm:represents attribute MAY be present on the <p> element or any of its descendant <span> elements, representing the Represents property. It MAY contain zero or more <audio> elements representing each Audio Recording object. It MAY contain zero or more <animate> elements representing each Mixing Instruction object. 4.5 Text Language Source The Text Language Source property is an annotation indicating the source language of a Text object, if applicable, or that the source content had no inherent language: If it is empty, the Text represents content without an inherent language, such as untranslated descriptions of a visual scene or captions representing non-dialogue sounds. If it has a value that does not represent a language, such as the empty string, und or zxx , the Text is Original . Note The empty string should be used instead of the value und to represent content whose inherent language has not yet been determined. Note The value zxx represents content without an inherent language, such as untranslated descriptions of a visual scene or captions representing non-dialogue sounds. [ bcp47 ] explains its use as follows: The 'zxx' (Non-Linguistic, Not Applicable) primary language subtag identifies content for which a language classification is inappropriate or does not apply. Some examples might include instrumental or electronic music; sound recordings consisting of nonverbal sounds; audiovisual materials with no narration, dialog, printed titles, or subtitles; machine- readable data files consisting of machine languages or character codes; or programming source code. Otherwise (if it has a value that does represent a language): if its value is the same as the language of the Text object, the Text is Original . otherwise (if the value is different to the language of the Text ), the Text is a Translation , whose source language is the Text Language Source property's value. Text Language Source is an inheritable property. The Text Language Source property is represented in a DAPT Document by a daptm:langSrc attribute with the following syntax, constraints and semantics: daptm:langSrc : <empty-string> | <language-identifier>

<empty-string> : "" # default

<language-identifier> # well-formed BCP-47 language tag The value MUST be an empty string or a well-formed language identifier as defined by [ BCP47 ]. It applies to <p> and <span> elements. It MAY be specified on the following elements: <tt> , <body> , <div> , <p> and <span> . The inheritance model of the daptm:langSrc attribute is as follows: If it is present on an element, the computed value is the specified value. Otherwise (if it is not present on an element), the computed value of the attribute on that element is the computed value of the same attribute on the element's parent, or if the element has no parent it is the default value. Note The inheritance model of the daptm:langSrc attribute is intended to match the inheritance model of the xml:lang attribute [ XML ]. The semantics of the computed value are as follows: If the computed value is a value that does not represent linguistic content then it indicates that the Text is Original . Example values in this category are: An empty string for content whose language has not been determined; zxx for content without an inherent language. Otherwise, if the computed value represents linguistic content, then: if the computed value is the same as the computed value of the xml:lang attribute, then it indicates that the Text is Original and sourced from content with an inherent language. Otherwise (the computed value differs from the computed value of the xml:lang attribute), it indicates that the Text is a translation , and the computed value is the language from which the Text was translated. Note An example of the usage of Text Language Source in a document is present in the Text section. Example 24 Table enumerating example values of the xml:lang and daptm:langSrc attributes for different Original transcript sources and their inherent languages. Transcript source Inherent language of the transcript source xml:lang daptm:langSrc In-image text English en en Video image (non text) none en zxx Sound effect none en zxx Dialogue Arabic ar ar If any of these transcripts were translated, the resulting Text would have its daptm:langSrc attribute set to the computed value of the xml:lang attribute of the source. For example, if the Arabic dialogue were translated into Japanese, it would result in xml:lang="ja" and daptm:langSrc="ar" . 4.6 On Screen The On Screen property is an annotation indicating the position in the scene relating to the subject of a Script Event , for example of the character speaking: ON - the Script Event 's subject is on screen for the entire duration OFF - the Script Event 's subject is off screen for the entire duration ON_OFF - the Script Event 's subject starts on screen, but goes off screen at some point OFF_ON - the Script Event 's subject starts off screen, but goes on screen at some point If omitted, the default value is "ON". Note When the daptm:represents attribute value begins with visual the subject of each Script Event , i.e. what is being described, is expected to be in the video image, therefore the default of "ON" allows the property to be omitted in those cases without distortion of meaning. The On Screen property is represented in a DAPT Document by a daptm:onScreen attribute on the <div> element, with the following constraints: The following attribute corresponding to the On Screen Script Event property may be present: daptm:onScreen : "ON" # default | "OFF" | "ON_OFF" | "OFF_ON" 4.7 Represents The Represents property indicates which component of the related media object the Script Event or a Text (or a part of) represents. The Represents property is represented in a DAPT Document by a daptm:represents attribute, whose value MUST be a single < content-descriptor > . The daptm:represents attribute MAY be present on any of the elements <tt> , <body> , <div> , <p> and <span> . The Represents property is inheritable. If it is absent from an element then its computed value is the computed value of the Represents property on its parent element, or, if it has no parent element, it is the empty string. If it is present on an element then its computed value is the value specified. Note Since there is no empty < content-descriptor >, this implies that an empty computed Represents property can never be valid; one way to construct a valid DAPT Document is to specify a Represents property on the DAPT Script so that it is inherited by all descendants that do not have a Represents property. It is an error for a Represents property value not to be a content descriptor sub-type of at least one of the values in the Script Represents property. 4.8 Script Event Description The Script Event Description object is an annotation providing a human-readable description of some aspect of the content of a Script Event . Script Event Descriptions can themselves be classified with a Description Type . A Script Event Description object is represented in a DAPT Document by a <ttm:desc> element at the <div> element level. Zero or more <ttm:desc> elements MAY be present. Script Event Descriptions SHOULD NOT be empty. 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 <ttm:desc> element MAY specify its language using the xml:lang attribute. Note In the absence of an xml:lang attribute the language of the Script Event Description is inherited from the parent Script Event object. Example 25 ... < body daptm:langSrc = "zxx" > < div begin = "10s" end = "13s" xml:id = "a1" > < ttm:desc > Scene 1 </ ttm:desc > < p xml:lang = "en" > < span > A woman climbs into a small sailing boat. </ span > </ p > < p xml:lang = "fr" daptm:langSrc = "en" > < span > Une femme monte à bord d'un petit bateau à voile. </ span > </ p > </ div > < div begin = "18s" end = "20s" xml:id = "a2" > < ttm:desc > Scene 1 </ ttm:desc > < p xml:lang = "en" > < span > The woman pulls the tiller and the boat turns. </ span > </ p > < p xml:lang = "fr" daptm:langSrc = "en" > < span > La femme tire sur la barre et le bateau tourne. </ span > </ p > </ div > </ body > ... Each Script Event Description can be annotated with one or more Description Types to categorise further the purpose of the Script Event Description. Each Description Type is represented in a DAPT Document by a daptm:descType attribute on the <ttm:desc> element. The <ttm:desc> element MAY have zero or one daptm:descType attributes. The daptm:descType attribute is defined below. daptm:descType : string The permitted values for daptm:descType are either those listed in the following registry table , or can be user-defined: Registry table for the daptm:descType attribute whose Registry Definition is at H.2.1 daptm:descType registry table definition 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. Note The registry entries are available in JSON form in the version control system at /registries/descType.json . Valid user-defined values MUST begin with x- . Example 26 ... < body > < div begin = "10s" end = "13s" xml:id = "a123" > < ttm:desc daptm:descType = "pronunciationNote" > [oːnʲ] </ ttm:desc > < p > Eóin looks around at the other assembly members. </ p > </ div > </ body > ... Amongst a sibling group of <ttm:desc> elements there are no constraints on the uniqueness of the daptm:descType attribute, however it may be useful as a distinguisher as shown in the following example. Example 27 ... < body daptm:langSrc = "zxx" > < div begin = "10s" end = "13s" xml:id = "a1" > < ttm:desc daptm:descType = "scene" > Scene 1 </ ttm:desc > < ttm:desc daptm:descType = "plotSignificance" > High </ ttm:desc > < p xml:lang = "en" > < span > A woman climbs into a small sailing boat. </ span > </ p > < p xml:lang = "fr" daptm:langSrc = "en" > < span > Une femme monte à bord d'un petit bateau à voile. </ span > </ p > </ div > < div begin = "18s" end = "20s" xml:id = "a2" > < ttm:desc daptm:descType = "scene" > Scene 1 </ ttm:desc > < ttm:desc daptm:descType = "plotSignificance" > Low </ ttm:desc > < p xml:lang = "en" > < span > The woman pulls the tiller and the boat turns. </ span > </ p > < p xml:lang = "fr" daptm:langSrc = "en" > < span > La femme tire sur la barre et le bateau tourne. </ span > </ p > </ div > </ body > ... 4.9 Audio An Audio object is used to specify an audio rendering of a Text . The audio rendering can either be a recorded audio resource, as an Audio Recording object, or a directive to synthesize a rendering of the text via a text to speech engine, which is a Synthesized Audio object. Both are types of Audio object. It is an error for an Audio not to be in the same language as its Text . A presentation processor that supports audio plays or inserts the Audio at the specified time on the related media object 's timeline. Note The Audio object is "abstract": it only can exist as one of its sub-types, Audio Recording or Synthesized Audio . 4.9.1 Audio Recording An Audio Recording is an Audio object that references an audio resource. It has the following properties: One or more alternative Sources , each of which is either 1) a link to an external audio resource or 2) an embedded audio recording; For each Source , one mandatory Type that specifies the type ([ MIME-TYPES ]) of the audio resource, for example audio/basic ; An optional Begin property and an optional End and an optional Duration property that together define the Audio Recording 's time interval in the programme timeline, in relation to the parent element's time interval; An optional In Time and an optional Out Time property that together define a temporal subsection of the audio resource; The default In Time is the beginning of the audio resource. The default Out Time is the end of the audio resource. If the temporal subsection of the audio resource is longer than the duration of the Audio Recording 's time interval, then playback MUST be truncated to end when the Audio Recording 's time interval ends. Note "Extended descriptions" (known in [ media-accessibility-reqs ] as "Extended video descriptions") are longer than the allocated time within the related media. A presentation processor that supports extended descriptions can allow the effective play rate of the audio resource to differ from the play rate of the related media object so that the resulting interval has a long enough duration to accommodate the audio resource's temporal subsection. For example it could pause or slow down playback of the related media object while continuing playback of the audio resource, or it could speed up playback of the audio resource, so that the Audio Recording 's time interval does not end before the audio resource's temporal subsection. This behaviour is currently unspecified and therefore implementation-defined. If the temporal subsection of the audio resource is shorter than the duration of the Audio Recording 's time interval, then the audio resource plays once. Zero or more Mixing Instructions that modify the playback characteristics of the Audio Recording . When a list of Sources is provided, a presentation processor MUST play no more than one of the Sources for each Audio Recording . Implementations can use the Type , and if present, any relevant additional formatting information, to decide which Source to play. For example, given two Sources , one being a WAV file, and the other an MP3, an implementation that can play only one of those formats, or is configured to have a preference for one or the other, would select the playable or preferred version. An Audio Recording is represented in a DAPT Document by an <audio> element child of a <p> or <span> element corresponding to the Text to which it applies. The following constraints apply to the <audio> element: The begin , end and dur attributes represent respectively the Begin , End and Duration properties; The clipBegin and clipEnd attributes represent respectively the In Time and Out Time properties, as illustrated by Example 5 ; For each Source , if it is a link to an external audio resource, the Source and Type properties are represented by exactly one of: A src attribute that is not a fragment identifier, and a type attribute respectively; This mechanism cannot be used if there is more than one Source . Example 28 <audio src = "https://example.com/audio.wav" type = "audio/wave" /> A <source> child element with a src attribute that is not a fragment identifier and a type attribute respectively; Example 29 <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 . Editor's note 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"? Issue 113 : Support both `@src` and `<source>` child of `<audio>` (external resources)? question CR-exit-must-have 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] Issue 218 : At-risk: support for `src` attribute in `<audio>` for external resource CR-exit-must-have At risk feature Possible resolution to #113 . Issue 219 : At-risk: support for `<source>` element child of `<audio>` for external resource CR-exit-must-have At risk feature Possible resolution to #113 . For each Source , if it is an embedded audio resource, the Source and Type properties are represented together by exactly one of: A src attribute that is a fragment identifier that references an <audio> 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 . Example 30 < tt > < head > < resources > < audio type = "audio/wave" xml:id = "audio1" > < source > < data > [base64-encoded WAV audio resource] </ data > </ source > </ audio > </ resources > </ head > < body > .. < audio src = "#audio1" /> .. </ body > </ tt > A <source> child element with a src attribute that is a fragment identifier that references 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; Example 31 < 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 > A <source> child element with a <data> element child that specifies a type attribute and contains the audio recording data. Example 32 < 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. Editor's note 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"? Issue 114 : Support both `@src` and `<source>` child of `<audio>` (embedded resources)? question CR-exit-must-have 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. Issue 115 : Support both referenced and inline embedded audio recordings? question CR-exit-must-have 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> Issue 220 : At-risk: support for `src` attribute of `<audio>` element pointing to embedded resource CR-exit-must-have At risk feature 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 . Issue 221 : At-risk: support for `<source>` child of `<audio>` element pointing to embedded resource CR-exit-must-have At risk feature 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 . Issue 222 : At-risk: support for inline audio resources CR-exit-must-have At risk feature Possible resolution to #115 . Issue 116 : Add non-inlined embedded audio resources to the Data Model? question CR-exit-must-have 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? Issue 117 : Embedded data: Do we need to support all the permitted encodings? What about length? question CR-exit-must-have In TTML2's <data> element, an encoding can be specified, being one of: base16 base32 base32hex base64 base64url 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? Issue 223 : At-risk: each of the potential values of `encoding` in `<data>` CR-exit-must-have At risk feature Possible resolution to #117 . Issue 224 : At-risk: support for the `length` attribute on `<data>` CR-exit-must-have At risk feature Possible resolution to #117 . Mixing Instructions MAY be applied as specified in their TTML representation ; The computed value of the xml:lang attribute MUST be identical to the computed value of the xml:lang attribute of the parent element and any child <source> elements and any referenced embedded <data> elements. 4.9.2 Synthesized Audio A Synthesized Audio is an Audio object that represents a machine generated audio rendering of the parent Text content. It has the following properties: A mandatory Rate that specifies the rate of speech, being normal , fast or slow ; An optional Pitch that allows adjustment of the pitch of the speech. A Synthesized Audio is represented in a DAPT Document by the application of a tta:speak style attribute on the element representing the Text object to be spoken, where the computed value of the attribute is normal , fast or slow . This attribute also represents the Rate Property. The tta:pitch style attribute represents the Pitch property. The TTML representation of a Synthesized Audio is illustrated by Example 7 . Note 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 . Note 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. 4.10 Mixing Instruction A Mixing Instruction object is a static or animated adjustment of the audio relating to the containing object. It has the following properties: Zero or more Gain properties. The gain acts as a multiplier to be applied to the related Audio ; Zero or more Pan properties. The pan adjusts the stereoscopic (left/right) position; An optional Begin and an optional End and an optional Duration property that together define the time interval during which the Mixing Instruction applies; An optional Fill property that specifies whether, at the end time of an animated Mixing Instruction , the specified Gain and Pan properties should be retained ( freeze ) or reverted ( remove ). A Mixing Instruction is represented by applying audio style attributes to the element that corresponds to the relevant object, either inline, by reference to a <style> element, or in a child (inline) <animate> element: The tta:gain attribute represents the Gain property; The tta:pan attribute represents the Pan property. If the Mixing Instruction is animated, that is, if the adjustment properties change during the containing object's active time interval, then it is represented by one or more child <animate> elements. This representation is required if more than one Gain or Pan property is needed, or if any timing properties are needed. The <animate> element(s) MUST be children of the element corresponding to the containing object, and have the following constraints: The begin , end and dur attributes represent respectively the Begin , End and Duration properties; The fill attribute represents the Fill property; The tta:gain attribute represents the Gain property, and uses the animation-value-list syntax to express the list of values to be applied during the animation period; The tta:pan attribute represents the Pan property, and uses the animation-value-list syntax to express the list of values to be applied during the animation period. The TTML representation of animated Mixing Instructions is illustrated by Example 4 . See also E. Audio Mixing . 5. Constraints 5.1 Document Encoding A DAPT Document MUST be serialised as a well-formed XML 1.0 [ xml ] document encoded using the UTF-8 character encoding as specified in [ UNICODE ]. The resulting [ xml ] document MUST NOT contain any of the following physical structures: entity declarations ; and entity references other than to predefined entities . Note 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) Note A DAPT Document can also be used as an in-memory model for processing, in which case the serialisation requirements do not apply. 5.2 Processing of unrecognised or foreign elements and attributes The requirements in this section are intended to facilitate forwards and backwards compatibility, specifically to permit: DAPT processors targeted at one version of the specification to process DAPT documents that include vocabulary or semantics defined in future versions, albeit without supporting the later features; DAPT processors targeted at one version of the specification to process DAPT documents authored for an earlier version with similar or identical behaviour to a DAPT processor targeted at that earlier version. A DAPT document that conforms to more than one version of the specification could specify conformance to multiple DAPT content profiles . 5.2.1 Unrecognised vocabulary 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. Note 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 . Note 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. 5.2.2 Special considerations for foreign vocabulary Foreign vocabulary is the subset of unrecognised vocabulary that consists of those elements and attributes whose namespace is not one of the namespaces listed in 5.3 Namespaces and those attributes whose namespace has no value 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 . Note 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 . 5.2.3 Proprietary Metadata and Foreign Vocabulary 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. Note It is possible to add information such as the title of the programme using [ TTML2 ] constructs. Example 33 ... < head > < metadata > < ttm:title > A example document title </ ttm:title > </ metadata > </ head > ... 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 . Example 34 ... < 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 > ... It is strongly recommended not to place data whose semantics depend on the contents of the document within <metadata> elements. Such data can be invalidated by transformation processors that modify the contents of the document but preserve metadata while being unaware of their semantics. 5.2.3.1 Defining and using foreign vocabulary that is not metadata 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: Define a profile including a feature definition for that semantic and vocabulary, with a profile designator. Signal document conformance to that profile using the 5.6.2 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. 5.3 Namespaces The following namespaces (see [ xml-names ]) are used in this specification: Name Prefix Value Defining Specification XML xml http://www.w3.org/XML/1998/namespace [ xml-names ] TT tt http://www.w3.org/ns/ttml [ TTML2 ] TT Parameter ttp http://www.w3.org/ns/ttml#parameter [ TTML2 ] TT Audio Style tta http://www.w3.org/ns/ttml#audio [ TTML2 ] TT Metadata ttm http://www.w3.org/ns/ttml#metadata [ TTML2 ] TT Feature none http://www.w3.org/ns/ttml/feature/ [ TTML2 ] DAPT Metadata daptm http://www.w3.org/ns/ttml/profile/dapt#metadata This specification DAPT Extension none http://www.w3.org/ns/ttml/profile/dapt/extension/ This specification EBU-TT Metadata ebuttm urn:ebu:tt:metadata [ EBU-TT-3390 ] The namespace prefix values defined above are for convenience and DAPT Documents MAY use any prefix value that conforms to [ xml-names ]. The namespaces defined by this specification are mutable as described in [ namespaceState ]; all undefined names in these namespaces are reserved for future standardization by the W3C . 5.4 Related Media Object Within DAPT , the common language terms audio and video are used in the context of a programme. The audio and video are each a part of what is defined in [ TTML2 ] as the Related Media Object that provides the media timeline and is the source of the main programme audio , and any visual timing references needed when adjusting timings relevant to the video image, such as for lip synchronization. Note A DAPT document can identify the programme acting as the Related Media Object using metadata. For example, it is possible to use the <ebuttm:sourceMediaIdentifier> element defined in [ EBU-TT-3390 ]. Example 35 < 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:ebuttm = "urn:ebu:tt:metadata" xml:lang = "en" ttp:contentProfiles = "http://www.w3.org/ns/ttml/profile/dapt1.0/content" daptm:scriptRepresents = "audio.dialogue" daptm:scriptType = "originalTranscript" > < head > < metadata > < ebuttm:sourceMediaIdentifier > https://example.org/programme.mov </ ebuttm:sourceMediaIdentifier > </ metadata > </ head > < body > ... </ body > </ tt > 5.5 Synchronization If the DAPT Document is intended to be used as the basis for producing an [ TTML-IMSC1.2 ] document, the synchronization provisions of [ TTML-IMSC1.2 ] apply in relation to the video. Timed content within the DAPT Document is intended to be rendered starting and ending on specific audio samples. Note 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. 5.6 Profile Signaling This section defines how a TTML Document Instance signals that it is a DAPT Document and how it signals any processing requirements that apply. See also 7.1 Conformance of DAPT Documents , which defines how to establish that a DAPT Document conforms to this specification. 5.6.1 Profile Designators 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 5.6.2 ttp:contentProfiles The ttp:contentProfiles attribute is used to declare the [ TTML2 ] profiles to which the document conforms. DAPT Documents MUST specify a ttp:contentProfiles attribute on the <tt> element including at least one value equal to a content profile designator specified at 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 ttp:contentProfiles attribute associated with profiles that they (the processors) do not support; by definition they cannot verify conformance of the content to those profiles. 5.6.3 ttp:profile The ttp:profile attribute is a mechanism within [ TTML1 ] for declaring the processing requirements for a Document Instance . It has effectively been superceded in [ TTML2 ] by ttp:processorProfiles . DAPT Documents MUST NOT specify a ttp:profile attribute on the <tt> element. 5.6.4 ttp:processorProfiles The ttp:processorProfiles attribute is used to declare the processing requirements for a Document Instance . DAPT Documents MAY specify a ttp:processorProfiles attribute on the <tt> element. If present, the ttp:processorProfiles attribute MUST include at least one value equal to a processor profile designator specified at 5.6.1 Profile Designators . Other values MAY be present to declare additional processing constraints, and MAY include profile designators in proprietary namespaces. Note The ttp:processorProfiles attribute can be used to signal that features and extensions in additional profiles need to be supported to process the Document Instance successfully. For example, a local workflow might introduce particular metadata requirements, and signal that the processor needs to support those by using an additional processor profile designator. Note If the content author does not need to signal that additional processor requirements than those defined by DAPT are needed to process the DAPT document then the ttp:processorProfiles attribute is not expected to be present. 5.6.5 Other TTML2 Profile Vocabulary [ TTML2 ] specifies a vocabulary and semantics that can be used to define the set of features that a document instance can make use of, or that a processor needs to support, known as a Profile . Except where specified, it is not a requirement of DAPT that this profile vocabulary is supported by processors; nevertheless such support is permitted. The majority of this profile vocabulary is used to indicate how a processor can compute the set of features that it needs to support in order to process the Document Instance successfully. The vocabulary is itself defined in terms of TTML2 features. Those profile-related features are listed within F. Profiles as being optional. They MAY be implemented in processors and their associated vocabulary MAY be present in DAPT Documents . Note Unless processor support for these features and vocabulary has been arranged (using an out-of-band protocol), the vocabulary is not expected to be present. The additional profile-related vocabulary for which processor support is not required (but is permitted) in DAPT is: the <ttp:profile> element; the <ttp:feature> and <ttp:extension> elements; the ttp:permitFeatureNarrowing attribute; the ttp:permitFeatureWidening attribute; the ttp:contentProfileCombination attribute; the ttp:inferProcessorProfileSource attribute; the ttp:processorProfileCombination attribute. 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 attribute value is media , since F. 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 . 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. Note [ TTML2 ] specifies the ttp:frameRateMultiplier attribute for defining non-integer frame rates. 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 expressions All time expressions within a document SHOULD use the same syntax, either clock-time or offset-time as defined in [ TTML2 ], with DAPT constraints applied. Note 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). Note 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. 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. 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 . 5.8 Layout and styles 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> 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 ]. 5.9 Bidirectional text The following metadata elements are permitted in DAPT and specified in [ TTML2 ] as containing #PCDATA , i.e. text data only with no element content. Where bidirectional text is required within the character content within such an element, Unicode control characters can be used to define the base direction within arbitrary ranges of text. <ttm:copyright> <ttm:desc> <ttm:item> <ttm:name> <ttm:title> Note 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. Note The following example taken from [ TTML2 ] demonstrates the syntax for bidirectional text markup within the <p> and <span> elements. Example 36 < p > The title of the book is " < span tts:unicodeBidi = "embed" tts:direction = "rtl" > نشاط التدويل، W3C </ span > " </ p > An example rendering of the above fragment is shown below. 6. Mapping from TTML to the DAPT Data Model 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 . Note 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. Note 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. 6.1 Early identification of non-conformant documents 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. 6.2 Not supporting features excluded by the content profile A processor that takes as its input a DAPT document that contains vocabulary relating to features that it does support, but where support for those features is excluded from the content profiles to which the document claims conformance, SHOULD NOT implement those features in the context of that document. 6.3 Handling <div> and <p> elements [ TTML2 ] allows <div> elements to contain any combination of <div> elements and <p> elements. The DAPT data model describes how each Script Event is represented by a <div> element that contains zero or more <p> elements. It also permits other intermediate <div> elements in the path between the <body> element and those Script Event <div> elements. In addition, attributes not corresponding to properties in the DAPT data model are permitted. This gives rise to possibilities such as: <div> elements that contain children that are not Text objects, for example other <div> elements or <metadata> elements; <div> elements that do not have attributes required for Script Events , like xml:id ; <div> elements that have attributes absent from the DAPT data model for Script Events , like xml:space ; <p> elements whose parent <div> element does not appear to be a Script Event . The following processing rules resolve these cases. Rules for identifying Script Events : A <div> element that has no <div> element children and includes the TTML representations of all the non-metadata 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 ; For the purposes of this clause a property is considered to be metadata if its TTML representation is in the daptm namespace or the ttm namespace. A <div> element that contains any <div> element children MUST NOT be mapped to a Script Event ; the processor instead MUST iterate through those <div> element children (recursively, in a depth-first traversal) and consider if each one meets the requirements of a Script Event ; Any remaining unmapped <div> elements MUST NOT be mapped to a Script Event . Rules for identifying Text objects: A <p> element that is a child of a <div> element that maps to a Script Event MUST be mapped to a Text object. A <p> element that is not a child of a <div> element that maps to a Script Event MUST NOT be mapped to a Text object. Note 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. Example 37 This example demonstrates the above possibilities, and the application of the rules: < body > < div xml:id = "d1" >  < p >  </ p > </ div > < div >  < p >  </ p > </ div > < div xml:id = "d2_1" >  < div xml:id = "d2" >  </ div > </ div > < div xml:id = "d3_1" >  < div xml:id = "d3_1_1" > < div xml:id = "d3" begin = "..." end = "..." xml:lang = "ja" foo:bar = "baz" >  </ div > </ div > </ div > < div xml:id = "d4_1" >  < div xml:id = "d4_2" >  </ div > < p >  </ p > </ div > </ body > The result of applying the above rules to this example is: d1 is a Script Event and its child <p> element is a Text object; The <div> element between d1 and d2 's parent <div> element is not a Script Event and its child <p> element is not a Text object; d2 is a Script Event and its parent <div> element is not; d3 is a Script Event and its parent and its grandparent <div> elements are not; d4_1 is not a Script Event and its child <p> element is not a Text object; d4_2 is a Script Event . 6.4 Using computed attribute values Some attributes have semantics for computing their value that depend on the computed value of the attribute on some other element. For example if the xml:lang attribute is not specified on an element then its computed value is the computed value of the same attribute on the element's parent. Table of attributes that can be specified on elements other than those corresponding to DAPT data model entities on which they are defined. Note that additional permitted attributes, such as styling attributes (including fill , tta:gain and tta:pan ), are not listed here. Attribute DAPT data model entity May be specified on Effect on children or descendant elements xml:lang Default Language , Language Any element Inherited, as defined in [ XML ] xml:id Unique Identifier Any element None begin Begin <body> , <div> , <p> , <span> , <audio> , <animate> Sets the epoch for timing properties on its children, as defined in [ TTML2 ] end End <body> , <div> , <p> , <span> , <audio> , <animate> Constrains the computed end time of its descendants, as defined in [ TTML2 ] dur Duration <body> , <div> , <p> , <span> , <audio> , <animate> Constrains the computed end time of its descendants, as defined in [ TTML2 ] daptm:langSrc Text Language Source <tt> , <body> , <div> , <p> , <span> Inherited, as defined in this section daptm:represents Represents <tt> , <body> , <div> , <p> , <span> Inherited, as defined in this section The daptm:scriptRepresents , daptm:onScreen and daptm:descType attributes are defined only when specified on a particular element. Or, for another example, the computed times of an element in a DAPT document are relative to the begin time of the element's parent. If a <div> element specifies a begin attribute, then the computed times of its child <div> elements are relative to that parent <div> element's begin time, and so on down the hierarchy. It is important to include those "intermediate" <div> elements' times in the computation even if the processing target is an instance of the DAPT data model in which they have no direct equivalent; otherwise the Script Event Begin and End times would be wrong. Considering this situation more generally, it is possible that, within a DAPT document, there can be TTML elements that do not directly correspond to objects in the DAPT data model, and those elements can specify attributes that affect the computation of attribute values that apply to elements that do correspond to objects in the DAPT data model. The semantics defined by [ TTML2 ] or, for vocabulary defined herein, this specification, take precedence in this scenario. Implementations MUST compute attribute values based on the contents of the document instance before applying those computed values to DAPT data model objects. For example a processor that supports TTML2 styling features would need to implement the TTML2 semantics for inheritance and computing relative values of attributes like tts:fontSize . Example 38 This example demonstrates these possibilities, which a processor might need to handle: < tt ... xml:lang = "en" > < body > < div xml:id = "d1" begin = "00:01:00" end = "00:01:10" >  < p >  </ p > </ div > < div begin = "00:10:00" xml:lang = "fr" >  < div xml:id = "d2" begin = "00:01:00" end = "00:01:10" >  < p >  </ p > </ div > </ div > </ body > </ tt > Here, the <div> elements that correspond to Script Events , which have ids d1 and d2 , are otherwise (apart from their identifiers) identical, yet their language and Begin properties have different computed values, due to the attributes specified on the <div> element parent of d2 . 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. 6.5 Considerations for transformation and validation processors This section is non-normative. 6.5.1 Retaining unrecognised vocabulary 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. 6.5.2 Validation warnings and errors Normative provisions relating to this section are defined in [ TTML2 ]. [ TTML2 ] defines a validation processor , a class of implementation whose purpose is to assess a document instance and decide if it is valid or not. Typically this would be used within a processing workflow to check that documents are acceptable for onward usage. A real world example would likely not return simply "good" or "bad", but also output informational, warning and error messages describing unusual, unexpected or problematic contents in the input document. When implementing a validation processor for a DAPT document , strict [ TTML2 ] validation processing rules can be applied. Doing this involves checking for the presence and semantic validity of syntax and content associated with required or optional features defined in the profile, and checking for the absence of syntax associated with prohibited features. The [ TTML2 ] mechanism for dealing with vocabulary in unrecognised namespaces is to prune it prior to validation. This approach can be used; additionally it could be reasonable for an implementation to report as information those attributes and elements that have been pruned. Note 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. 7. 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. [ 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 F. 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 F. Profiles directly to determine if it is capable of processing a DAPT document . 7.1 Conformance of DAPT Documents Conformant DAPT Documents are [ TTML2 ] timed text content document instances that conform to the normative provisions of this specification. Those provisions are expressed using the profile vocabulary of [ TTML2 ] in the content profile defined in F. Profiles . Note 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. 7.2 Conformance of DAPT Processors Conformant DAPT Processors are [ TTML2 ] content processors that conform to the normative provisions of this specification. Those provisions are expressed using the profile vocabulary of [ TTML2 ] in the processor profile defined in F. Profiles . Note The provisions in this specification are expressed in terms of [ TTML2 ] content processor types, using terms like content processor , presentation processor , validation processor , or transformation processor . They may be understood with the mapping below: A DAPT tool that would display the content of a DAPT document, in any form: for example, just rendering the text, event by event; or rendering the text of all the events all at once along a timeline; or one doing the audio mixing, would be considered a presentation processor . A presentation processor can also support additional rendering features that are not required by DAPT , for example those supporting visual styling attributes from [ TTML2 ] or [ TTML-IMSC1.2 ]. A DAPT authoring tool, producing DAPT documents from scratch or from an other document, would be considered a transformation processor . It may also be considered as a presentation processor if it does any form of rendering of the text or the audio. A DAPT tool that would indicate if a DAPT document is compliant to this specification would correspond to a validation processor . A. Index A.1 Terms defined by this specification As-recorded Script §4.1.3 Audio §4.9 audio description §2.1.2 Audio Recording §4.9.1 Begin §4.1.6.1 change request §H.1.2.1 Character §4.2 Character Identifier §4.2 content descriptor sub-type §4.1.6.2 content-descriptor §4.1.6.2 DAPT 1.0 Content Profile §5.6.1 DAPT 1.0 Processor Profile §5.6.1 DAPT Document §4.1 DAPT Extension §5.3 DAPT Origin Timecode §D.1 DAPT Script §4.1 daptm §5.3 daptm:daptOriginTimecode §D.1 daptm:descType §4.8 daptm:langSrc §4.5 daptm:onScreen §4.6 daptm:represents §4.7 daptm:scriptRepresents §4.1.1 daptm:scriptType §4.1.3 Default Language §4.1.2 Deprecated §H.1.3.1.1.3 description §2.1.2 Description Types §4.8 descriptor-token §4.1.6.2 dubbing §2.1.1 dubbing script §2.1.1 Duration §4.1.6.1 ebuttm §5.3 End §4.1.6.1 fields §H.1.3.1 Fill §4.10 Final §H.1.3.1.1.2 Foreign vocabulary §5.2.2 Gain §4.10 In Time §4.9.1 key §H.1.3.1 Main programme audio §2.1.2 Mixing Instruction §4.10 Name §4.2 non-matching §G.15 On Screen §4.6 Original §4.4 Original Language Transcript §4.1.3 Out Time §4.9.1 Pan §4.10 Pitch §4.9.2 Pre-recording Script §4.1.3 Provisional §H.1.3.1.1.1 Rate §4.9.2 registry table definition §H.1.3 Represents §4.7 script §2.1 Script Event §4.3 Script Event Description §4.8 Script Event Identifier §4.3 Script Represents §4.1.1 Script Type §4.1.3 shared properties §4.1.6 Sources §4.9.1 Start of Programme Timecode §D.2 status §H.1.3.1.1 Synthesized Audio §4.9.2 Talent Name §4.2 Target Recording Language §4.1.2 Text §4.4 Text Language Source §4.5 Timed Text Working Group §H.1.1 timing properties §4.1.6.1 transcript §2.1 Translated Transcript §4.1.3 Translation §4.4 tt §5.3 tta §5.3 ttm §5.3 ttp §5.3 Type §4.9.1 Unique Identifier §4.1.6.3 Unrecognised vocabulary §5.2.1 A.2 Terms defined by reference [ DAPT-REQS ] defines the following: [DAPT-REQS] Process Step 1 [ I18N-INLINE-BIDI ] defines the following: Inline markup and bidirectional text in HTML [ MEDIA-ACCESSIBILITY-REQS ] defines the following: described video [ TTML2 ] defines the following: [construct inferred processor profile] #animate-fill #animate-minimal #animation-out-of-line #audio #audio-description #audio-speech #bidi #bidi-version-2 #chunk #clockMode #clockMode-gps #clockMode-local #clockMode-utc #content #contentProfiles #contentProfiles-combined #core #data #direction #dropMode #dropMode-dropNTSC #dropMode-dropPAL #dropMode-nonDrop #embedded-audio #embedded-data #frameRate #frameRateMultiplier #gain #markerMode #markerMode-continuous #markerMode-discontinuous #metadata #metadata-item #metadata-version-2 #nested-div #pan #permitFeatureNarrowing #permitFeatureWidening #pitch #presentation-audio #processorProfiles #processorProfiles-combined #profile #profile-full-version-2 #profile-version-2 #resources #set #set-fill #set-multiple-styles #source #speak #speech #structure #styling #styling-chained #styling-inheritance-content #styling-inline #styling-referential #subFrameRate #tickRate #time-clock #time-clock-with-frames #time-offset #time-offset-with-frames #time-offset-with-ticks #time-wall-clock #timeBase-clock #timeBase-media #timeBase-smpte #timeContainer #timing #transformation #unicodeBidi #unicodeBidi-isolate #unicodeBidi-version-2 #xlink <animate> <audio> <chunk> <data> <lwsp> <source> <time-expression> <ttp:extension> <ttp:feature> <ttp:profile> animation-value-list content processors content profile Document Instance extensions features presentation processor processor profile Profile Profile Profiling related media object timed text content document instance transformation processor tta:gain tta:pan tta:pitch tta:speak ttp:contentProfileCombination ttp:contentProfiles ttp:inferProcessorProfileSource ttp:permitFeatureNarrowing ttp:permitFeatureWidening ttp:processorProfileCombination ttp:processorProfiles ttp:profile validation processor [ W3C-PROCESS ] defines the following: at risk closed custodian registry definition registry entries registry section registry tables Updating Registry Tables w3c registries W3C Team wide review [ XML ] defines the following: character references Document Type Declaration Entity Declarations entity references Name NameStartChar predefined entities [ XMLSCHEMA-2 ] defines the following: xsd:NMtoken [ XPATH ] defines the following: LocationPath B. Privacy Considerations This section is non-normative. With the exception of the following, the privacy considerations of [ ttml2 ] apply: Appendix P.3 (Resource Fetching), where only the considerations relating to the <audio> element apply. Appendix P.7 (Access to Processing State) does not apply, since no support for the condition attribute is required. Appendix P.9 (Privacy of Preference) is extended to include the potential indication that the user has a need for audio description. B.1 Personal Information DAPT documents typically contain the names of characters or people who feature within the associated media, either fictional or real. In general this information would be present within the media itself or be public via other routes. If there is sensitivity associated with their being known to people with access to the DAPT documents in which their identity is contained, then such access should be managed with appropriate confidentiality. For example those documents could be available within a closed authoring environment and edited to remove the sensitive information prior to distribution to a wider audience. If this scenario arises, information security good practices within the closed environment should be applied, such as encryption of the document "at rest" and when being moved, access controlled by authentication platforms, etc. B.2 Audio format preference DAPT documents can reference a set of alternate external audio resources for the same fragment of audio, where the processor is expected to select one of the alternatives based on features such as format support. If this pattern is used, it is possible that the processor's choice of audio resource, being exposed to the origin, reveals information about that processor, such as its preferred audio format. Note Document authors and content providers can avoid referencing external audio resources by embedding the audio resources within the document. This usage pattern does not expose the processor's choice of audio resource to the origin. C. Security Considerations This section is non-normative. The security considerations of [ ttml2 ] apply, since DAPT is a profile of [ ttml2 ]; every conformant DAPT document is a TTML document instance . Notwithstanding the XML-related considerations of [ ttml2 ], DAPT documents are required by the mandatory #serialization extension feature to avoid declaring or referencing a Document Type Declaration and to avoid using the [ xml ] entity expansion mechanism. Therefore implementations can protect against potential denial of service attacks or external content injection associated with those features of XML by not supporting them when parsing DAPT documents. DAPT documents permit referencing of external audio resources, also described as "subresources". One potential threat associated with such references is that the origin might return a different audio resource to the one intended at authoring time. No scheme is currently provided for verifying the integrity of such subresources. Content providers that cannot ensure that the appropriate audio resources are served, for example if some part of the chain is outside their control, can consider adding subresource integrity metadata, for example an attribute including a hash of the intended subresource, and implementing a client-side check to use this to verify that the received subresource is the intended one. D. Timecode-related metadata DAPT Documents express time as media time , which assumes that there is a reference start time (zero) on a media timeline, and a fixed playrate. An alternative scheme that is used in some other script formats is to synchronize media components using timecode, that match time stamps that are applied, for example to each frame of video. Workflows that create DAPT documents from such timecode-based non- DAPT script formats need to map those timecode values onto the DAPT document 's timeline. If this mapping is not correct, presentation of the DAPT Document will not be synchronized with the related media object . A reference timecode that matches a known point on the DAPT document timeline can be used to achieve correct synchronization, for example the timecode corresponding to the start of the programme, which should match DAPT time zero. In this scenario, if such a reference point is not known, but timecodes corresponding to Script Events are known, it is still possible to construct a DAPT Document , albeit one whose synchronization with the related media has not yet been resolved. The optional DAPT Origin Timecode and Start of Programme Timecode properties can be used to identify when there is a possible synchronization error, and to resynchronize the document when all the required information is known. These properties are provided as metadata only and are not intended to be used to perform direct synchronization offsets during presentation. In particular, when the related media object uses timecode, the presence of the timecode properties does not mean that the player needs to relate these timecode values with any timecode value embedded in the related media resource. If either a DAPT Origin Timecode object or a Start of Programme Timecode object is 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. D.1 DAPT Origin Timecode The optional DAPT Origin Timecode allows a timecode value to be declared that corresponds to the zero point of the DAPT document timeline, that is, the time of a hypothetical Script Event whose Begin is zero seconds. The properties can be used to provide timecodes from the related media object or from any other script format used to produce the DAPT document, and are informational. However, when they are both provided and differ, it is an indication that the DAPT document is not synchronized with the related media object and that processing of the script event begins is needed. To achieve synchronization, the following needs to be done: The difference DAPT Origin Timecode minus the Start of Programme Timecode is computed as "delta". It may be positive or negative. Each Script Event 's Begin and End value X shall be changed to X + delta. The DAPT Origin Timecode shall be removed or changed to the Start of Programme timecode value so that if this algorithm is run again it will result in delta that is zero. A DAPT Script MAY contain zero or one DAPT Origin Timecode objects. The DAPT Origin Timecode object is represented in a DAPT Document by a < daptm:daptOriginTimecode > element present at the path /tt/head/metadata/daptm:daptOriginTimecode , with the following constraints: The character content of the element must conform to a clock-time with a frames component, as defined in <time-expression> . Note See also 5.7.3 ttp:frameRate . No mechanism is defined here for declaring a different frame rate for the DAPT Origin Timecode than is used for other frame-based time expressions. If the related media object contains a timecode for the video frame synchronized to the origin of the DAPT document timeline, the DAPT origin timecode is equal that timecode. Example 39 ... < head > < metadata > < daptm:daptOriginTimecode > 10:01:20:12 </ daptm:daptOriginTimecode > </ metadata > </ head > < body > < div xml:id = "se1" begin = "0s" end = "1.8s" >  </ div > </ body > ... Example 40 When converting legacy formats that store the equivalent of each Script Event, for example a description , with SMPTE timecodes, but where the Start of Programme Timecode is not stored, and is not immediately available, the DAPT Origin Timecode can be used to defer synchronization with the media until that media begin timecode is known. One approach to deferring synchronization using DAPT Origin Timecode is as follows, assuming that a legacy source file is being converted to a DAPT Document and relates to media with continuous timecode: Find the earliest begin timecode for an item in the source file that will be mapped to a Script Event ; Create a DAPT Document with a DAPT Origin Timecode set to that earliest begin timecode; For each relevant item in the source file, create a Script Event with appropriate Begin and End times obtained by converting the source file's begin and end timecodes to media time, relative to that DAPT Origin Timecode , basing elapsed time on the applicable frame rate; If using frame-based media time expressions, set the ttp:frameRate attribute of the <tt> element to the applicable frame rate; When the related media's timecode is later dicovered, the times of the Script Events can be adjusted so that media time zero is coincident with the Start of Programme Timecode , and the DAPT Origin Timecode can be removed or set to the now-known value. Note The above algorithm can be used to align the begin times of the DAPT Script and the related media object . It does not address progressive synchronization errors caused by incorrect frame rates or differing playback rates. D.2 Start of Programme Timecode The optional Start of Programme Timecode allows a timecode value to be declared that corresponds to the beginning of the related media object's programme content. In combination with DAPT Origin Timecode , the value of Start of Programme Timecode can be used to infer whether or not the media times in the DAPT Script are likely to be correctly synchronized with the Related Media Object . If both DAPT Origin Timecode and Start of Programme Timecode are present, but their values are different, it is likely that the media times are not synchronized with the Related Media Object , since this implies that the equivalent time code to zero seconds in media time is not the start of the programme, which is the requirement for correctly synchronized media time. A DAPT Script MAY contain zero or one Start of Programme Timecode objects. The Start of Programme Timecode object is represented in a DAPT Document by a <ebuttm:documentStartOfProgramme> element present at the path /tt/head/metadata/ebuttm:documentStartOfProgramme , with the syntactic constraints as defined in [ EBU-TT-3390 ]. Example 41 ... < head > < metadata > < daptm:daptOriginTimecode > 10:01:20:12 </ daptm:daptOriginTimecode > < ebuttm:documentStartOfProgramme > 10:00:00:00 < ebuttm:documentStartOfProgramme >  </ metadata > </ head > < body > < div xml:id = "se1" begin = "0s" end = "1.8s" >  </ div > </ body > ... If the times of the Script Events are adjusted to bring the media time into synchronization with the Related Media Object , as noted in DAPT Origin Timecode , the Start of Programme Timecode SHOULD NOT be changed, since it is an invariant feature of the Related Media Object , and does not describe the times in the DAPT Document . E. Audio Mixing This section is non-normative. This section contains additional information about audio mixing, intended for implementers. E.1 Web Audio 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. (active) ScriptEvent Pan Gain (active) AudioRecording Pan Gain (active) Text Pan Gain programme audio When audio mixing is active When no audio mixing is active Figure 2 Example simple audio routing between objects This example is shown as [ webaudio ] nodes in Figure 3 . GainNode (ScriptEvent) PanNode (ScriptEvent) GainNode (Text) PanNode (Text) GainNode (AudioRecording) PanNode (AudioRecording) Implicit mixer Master bus Programme Audio AudioRecording Source Audio Output Audio Figure 3 Web audio nodes representing the audio processing needed. The above examples are simplified in at least two ways: if a Text contains <span> elements that themselves have Mixing Instructions applied, then additional nodes would be needed; the application of animated Mixing Instructions is not shown explicitly. [ webaudio ] supports the timed variation of input parameters to its nodes: it is possible to translate the TTML <animate> element semantics directly into [ webaudio ] API calls to achieve the equivalent effect. E.2 Pop prevention If an Audio Recording begins or ends with audible sound, i.e. the first sample at the In Time or the last sample at the Out Time is non-zero, then it is possible that the audio transducer is induced to make an undesirable "pop" noise at the beginning or end of playback. Multiple potential strategies exist to avoid this pop effect, for example: The Audio recordings can be conditioned to be silent at the In Times and Out Times , with "silence guard" periods, of some reasonable duration, for example 200ms; The document author can apply an animated Mixing Instruction to instruct the mixing implementation or player to vary the Gain at the beginning or end of the Audio Recording ; The presentation processor i.e. the mixing implementation or player, can apply a steep gain curve at the beginning and end of playback, possibly based on operational parameters, or detection of non-zero edge samples, for example a linear ramp over 10ms has been used in one implementation. In case the last of these approaches is used, and if there is no other external control over the presentation processor 's behaviour in this respect, it is recommended that the Audio Recordings also do not contain samples at the beginning or end that, if rendered inaudible, would change the meaning. For example omitting a percussive speech sound such as the "c" at the beginning of the word "cat" would result in the word sounding like "at". F. Profiles This section defines a [ TTML2 ] content profile and a processor profile by expressing dispositions against a set of features and extensions . The DAPT extensions are defined in G. 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: MUST satisfy all normative provisions specified by the profile; MAY include any vocabulary, syntax or attribute value associated with a feature or extension whose disposition is permitted or optional in the profile; MUST include any vocabulary, syntax or attribute value associated with a feature or extension whose disposition is required in the profile. MUST NOT include any vocabulary, syntax or attribute value associated with a feature or extension whose disposition is prohibited in the profile. Note 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: MUST satisfy the Generic Processor Conformance requirements at Section 3.2.1 of [ TTML2 ] MUST satisfy all normative provisions specified by the profile; and MUST implement presentation semantic support for every feature or extension designated as permitted or required by the profile, subject to any additional constraints on each feature as specified by the profile. MAY implement presentation semantic support for every feature or extension designated as optional or prohibited by the profile, subject to any additional constraints on each feature as specified by the profile. A Transformation processor that conforms to the processor profile defined in this specification: MUST satisfy the Generic Processor Conformance requirements at Section 3.2.1 of [ TTML2 ]; MUST satisfy all normative provisions specified by the profile; and MUST implement transformation semantic support for every feature or extension designated as permitted or required by the profile, subject to any additional constraints on each feature as specified by the profile. MAY implement transformation semantic support for every feature or extension designated as optional or prohibited by the profile, subject to any additional constraints on each feature as specified by the profile. The dispositions required, permitted, optional and prohibited as used in this specification map to the [ TTML2 ] <ttp:feature> and <ttp:extension> elements' value attribute values as follows: DAPT disposition <ttp:feature> or <ttp:extension> element value attribute value in content profile processor profile required required required permitted optional required optional optional optional prohibited prohibited optional 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 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 . Note This document does not specify presentation processor or transformation processor behavior when processing or transforming a non-conformant timed text content 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. F.1 Disposition of Features and Extensions The features and extensions listed in this section express the minimal requirements for DAPT Documents , Presentation Processors , and Transformation Processors . DAPT Documents MAY additionally conform to other profiles, and include syntax not prohibited by the DAPT content profile . Presentation Processors and Transformation Processors MAY support additional syntax and semantics relating to other profiles. Note 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. Editor's note 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-fill permitted #animate-minimal 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 permitted See 5.6.2 ttp:contentProfiles and G.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 . #nested-div permitted This is the profile expression of the permission to nest <div> elements described in 4.3 Script Event . #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 ttp:timeBase . NOTE: [ TTML1 ] specifies that the default timebase is "media" if the ttp:timeBase attribute is not specified on the <tt> element. #timeBase-smpte prohibited #timeContainer prohibited See 5.7.2 timeContainer . #timing permitted See 5.7.5 Time expressions . #transformation permitted See constraints at #profile . #unicodeBidi permitted #unicodeBidi-isolate permitted #unicodeBidi-version-2 permitted #xlink permitted 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 . #daptOriginTimecode permitted This is the profile expression of D.1 DAPT Origin Timecode . #descType permitted This is the profile expression of daptm:descType . #onScreen permitted This is the profile expression of 4.6 On Screen . #profile-root prohibited This is the profile expression of the prohibition of the ttp:profile attribute on the <tt> element as specified in 5.6.3 ttp:profile . #represents required This is the profile expression of Represents as applied to Script Event . #scriptEventMapping optional This is the profile expression of 6.3 Handling <div> and <p> elements . #scriptRepresents-root required This is the profile expression of Script Represents . #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 . #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 . F.2 DAPT Content Profile The DAPT Content Profile expresses the conformance requirements of DAPT Scripts using the profile mechanism of [ TTML2 ]. It can be used by a validating processor that supports the DAPT Processor Profile to validate a DAPT Document . There is no requirement to include the DAPT Content Profile within a DAPT Document . <?xml version= "1.0" encoding= "utf-8" ?>  < 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/" >  < feature value = "required" > #structure </ feature > < feature value = "required" > #timeBase-media </ feature >  < 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" > #nested-div </ 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" > #transformation </ 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 >  < 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/" >  < extension value = "required" > #contentProfiles-root </ extension > < extension value = "required" > #represents </ extension > < extension value = "required" > #scriptRepresents-root </ extension > < extension value = "required" > #scriptType-root </ extension > < extension value = "required" > #serialization </ extension > < extension value = "required" > #xmlLang-root </ extension >  < extension value = "optional" > #agent </ extension > < extension value = "optional" > #daptOriginTimecode </ extension > < extension value = "optional" > #descType </ extension > < extension value = "optional" > #onScreen </ extension > < extension value = "optional" > #scriptEventMapping </ extension > < extension value = "optional" > #textLanguageSource </ extension >  < extension value = "prohibited" > #profile-root </ extension > < extension value = "prohibited" > #source-data </ extension > < extension value = "prohibited" > #xmlLang-audio-nonMatching </ extension > </ extensions > </ profile > F.3 DAPT Processor Profile The DAPT Processor Profile expresses the processing requirements of DAPT Scripts using the profile mechanism of [ TTML2 ]. A processor that supports the required features and extensions of the DAPT Processor Profile can, minimally, process all permitted features within a DAPT Document . There is no requirement to include the DAPT Processor Profile within a DAPT Document . <?xml version= "1.0" encoding= "utf-8" ?>  < 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/" >  < 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" > #nested-div </ 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 >  < 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/" >  < extension value = "required" > #agent </ extension > < extension value = "required" > #contentProfiles-root </ extension > < extension value = "required" > #daptOriginTimecode </ extension > < extension value = "required" > #descType </ extension > < extension value = "required" > #onScreen </ extension > < extension value = "required" > #represents </ extension > < extension value = "required" > #scriptRepresents-root </ extension > < extension value = "required" > #scriptType-root </ extension > < extension value = "required" > #serialization </ extension > < extension value = "required" > #textLanguageSource </ extension > < extension value = "required" > #xmlLang-root </ extension >  < 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 > G. Extensions G.1 General The following sections define extension designations, expressed as relative URIs (fragment identifiers) relative to the DAPT Extension Namespace base URI. These extension designations are used in F. Profiles to describe the normative provisions of DAPT that are not expressed by [ TTML2 ] profile features. G.2 #agent A transformation processor supports the #agent extension if it recognizes and is capable of transforming values of the following elements and attributes on the <ttm:agent> element: xml:id attribute <ttm:name> element and if it recognizes and is capable of transforming each of the following value combinations: <ttm:agent> element with type="person" and child <ttm:name> element with type="full" ; <ttm:agent> element with type="character" and child <ttm:name> element with type="alias" ; No presentation processor behaviour is defined for the #agent extension. G.3 #contentProfiles-root A transformation processor supports the #contentProfiles-root extension if it recognizes and is capable of transforming values of the ttp:contentProfiles attribute on the <tt> element. A presentation processor supports the #contentProfiles-root extension if it implements presentation semantic support of the ttp:contentProfiles attribute on the <tt> element. The #contentProfiles-root extension is a syntactic and semantic subset of the #contentProfiles feature. Note This extension is defined as a subset of #contentProfiles so that, by requiring it, in combination with the prohibition of #profile-root , processor support for the ttp:profile attribute and processor profile inference semantics can be avoided. Specifically, step 1 of [construct inferred processor profile] returns a non-null effective content profile, which is then used as the inferred processor profile. G.4 #daptOriginTimecode A transformation processor supports the #daptOriginTimecode extension if it recognizes and is capable of transforming values of the < daptm:daptOriginTimecode > element. No presentation processor behaviour is defined for the #daptOriginTimecode extension. G.5 #descType A transformation processor supports the #descType extension if it recognizes and is capable of transforming values of the daptm:descType attribute on the <ttm:desc> element. No presentation processor behaviour is defined for the #descType extension. G.6 #onScreen A transformation processor supports the #onScreen extension if it recognizes and is capable of transforming values of the daptm:onScreen attribute on the <div> element. No presentation processor behaviour is defined for the #onScreen extension. G.7 #profile-root A transformation processor supports the #profile-root extension if it recognizes and is capable of transforming values of the ttp:profile attribute on the <tt> element. A presentation processor supports the #profile-root extension if it implements presentation semantic support of the ttp:profile attribute on the <tt> element. The #profile-root extension is a syntactic and semantic subset of the #profile feature. Note This extension is defined as a subset of #profile so that, by its prohibition, the requirement for processor support for the ttp:profile attribute can be avoided, and that attribute can be prohibited within documents. G.8 #represents A transformation processor supports the #represents extension if it recognizes and is capable of transforming values of the daptm:represents attribute. Example 42 An example of a transformation processor that supports this extension is a validating processor that reports an error if the extension is permitted by a content profile but the timed text content document instance claiming conformance to that profile has a <div> element with a daptm:represents attribute whose value is not conformant with the requirements defined herein. No presentation processor behaviour is defined for the #represents extension. G.9 #scriptEventMapping A transformation processor supports the #scriptEventMapping extension if, when mapping a DAPT document into an internal representation of the DAPT data model, it implements the processing requirements specified at 6.3 Handling <div> and <p> elements . No presentation processor behaviour is defined for the #scriptEventMapping extension. Note 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. G.10 #scriptRepresents-root A transformation processor supports the #scriptRepresents-root extension if it recognizes and is capable of transforming values of the daptm:scriptRepresents attribute on the <tt> element. No presentation processor behaviour is defined for the #scriptRepresents-root extension. Example 43 An example of a transformation processor that supports this extension is a validating processor that reports an error if the extension is required by a content profile but the timed text content document instance claiming conformance to that profile either does not have a daptm:scriptRepresents attribute on the <tt> element or has one whose value is not conformant with the requirements defined herein. No presentation processor behaviour is defined for the #scriptRepresents-root extension. G.11 #scriptType-root A transformation processor supports the #scriptType-root extension if it recognizes and is capable of transforming values of the daptm:scriptType attribute on the <tt> element. Example 44 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 daptm:scriptType are not met, and that reports an error if the extension is required by a content profile but the timed text content document instance claiming conformance to that profile either does not have a daptm:scriptType attribute on the <tt> element or has one whose value is not defined herein. No presentation processor behaviour is defined for the #scriptType-root extension. G.12 #serialization A serialized document that is valid with respect to the #serialization extension is an XML 1.0 [ xml ] document encoded using UTF-8 character encoding as specified in [ UNICODE ], that contains no byte order mark (BOM), no Document Type Declaration , 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. G.13 #source-data A transformation processor supports the #source-data extension if it recognizes and is capable of transforming values of the <source> element child of a <data> element. A presentation processor supports the #source-data extension if it implements presentation semantic support of the <source> element child of a <data> element. G.14 #textLanguageSource A transformation processor supports the #textLanguageSource extension if it recognizes and is capable of transforming values of the daptm:langSrc attribute. No presentation processor behaviour is defined for the #textLanguageSource extension. G.15 #xmlLang-audio-nonMatching A transformation processor supports the #xmlLang-audio-nonMatching extension if it recognizes and is capable of transforming values of the xml:lang attribute on the <audio> element that differ from the computed value of the same attribute of its parent element or any of its descendant or referenced <source> or <data> elements, known as non-matching values. A presentation processor supports the #xmlLang-audio-nonMatching extension if it implements presentation semantic support of such non-matching xml:lang attribute values. G.16 #xmlLang-root A transformation processor supports the #xmlLang-root extension if it recognizes and is capable of transforming values of the xml:lang attribute on the <tt> element and the additional semantics specified in 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 . H. Registry Section H.1 Registry Definition This section specifies the registry definition , consisting of the custodianship, change process and the core requirements of the registry tables defined in this document. H.1.1 Custodianship 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 . H.1.2 Change Process H.1.2.1 Requesting a change Changes to this W3C Registry MUST be requested (the change request ) using any one of the following options: Open an issue on this document's version control system ; Send an email to the TTWG 's public email reflector [email protected] The change request MUST include enough information for the custodian to be able to identify all of: The registry table ; All registry entries being proposed for addition, if any; All provisional registry entries for which changes are being proposed, if any; All registry entries being proposed for a status change, if any; Details of the requested changes for each registry entry ; The motivation for making the requested changes; Any other supporting information, for example real world usage statistics; The proposer of the change MAY open a pull request (or equivalent) on the version control system , with that pull request containing the proposed changes. If a pull request is opened then a corresponding issue MUST also be opened and the pull request MUST be linked to that issue. Note A pull request representing the proposals made in the change request is required before TTWG review can proceed. H.1.2.2 Change request assessment process The process for assessing a change request depends on the custodian . H.1.2.2.1 Custodian is TTWG If the custodian is the TTWG : If the change proposer did not open a pull request on the version control system , then assessment is paused until a TTWG member has opened such a pull request, which MUST represent the requested changes and MUST be linked to a related issue. The TTWG follows its Decision Policy to review the proposal in the pull request. At the end of the Decision Review Period if a TTWG Chair declares that there is consensus to approve, the change request is approved. In the absence of consensus to approve the expectation is that a discussion will happen, to include the change requester. The result of this discussion can be any one of: the change request is abandoned; the change request is modified for another review; if the discussion resolves the objections, and a TTWG Chair declares consensus to approve, the change request can be approved. An approved change request is enacted by merging its related pull request into the version control system and publishing the updated version of this document. H.1.2.2.2 Custodian is the W3C Team If the custodian is the W3C Team , the Team MUST seek wide review of the change request and offer a review period of at least 4 weeks, before assessing from the responses received if there is consensus amongst the respondents. The Team MAY require a pull request on the version control system to be opened as the basis of the review. If there is such consensus, the Team MUST make the proposed changes. H.1.3 Registry Table Constraints This section defines constraints on the registry tables defined in this document. Each registry table consists of a set of registry entries . Each registry table has an associated registry table definition in H.2 Registry Table Definitions , which lists the fields present in each registry entry . H.1.3.1 Registry Entries Each registry entry has a status , a unique key , and if appropriate, other fields , for example any notes, a description, or a reference to some other defining entity. The registry table definition MUST define the fields and the key to be used in each registry entry . Note It is possible to use any field or combination of fields as the key . For example a field called "4 Character Code" might be used as the key . Another example is two fields called "Short name" and "Revision number" which, in combination, might be used as the key . H.1.3.1.1 Status The registry entry status field reflects the maturity of that entry. Permitted values are: Provisional Final Deprecated No other values are permitted. H.1.3.1.1.1 Provisional Registry entries with a status of Provisional MAY be changed or deleted. Their status may be changed to Final or Deprecated . Registry entry keys in Provisional entries that were later deleted MAY be reused. Newly created registry entries SHOULD have status Provisional . H.1.3.1.1.2 Final Registry entries with a status of Final MUST NOT be deleted or changed. Their status MAY be changed to Deprecated . Registry entry keys in Final entries MUST NOT be reused. Newly created registry entries MAY have status Final . H.1.3.1.1.3 Deprecated Registry entries with a status of Deprecated MUST NOT be deleted or changed. Their status MAY be changed to Final unless that would result in a duplicate key within the set of entries whose status is either Provisional or Final . Registry entry keys in Deprecated entries that were previously Provisional and never Final MAY be reused. Registry entry keys in Deprecated entries that were previously Final MUST NOT be reused. Newly created registry entries MUST NOT have status Deprecated . H.2 Registry Table Definitions This section defines registry tables and locates their registry entries . H.2.1 daptm:descType registry table definition 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.8 Script Event Description . The key values for this registry table MUST NOT begin with x- which is reserved for user extensions. H.2.2 <content-descriptor> registry table definition The registry table for <content-descriptor> defines a set of values that can be used in the daptm:represents attribute. The key is the " <content-descriptor> " field. The "Description" field describes the type of media content represented by each value. The "Example usage" field describes the type of script in which the content type described are commonly found. The registry entries for this registry table are located in 4.1.6.2 <content-descriptor> values . The key values for this registry table MUST NOT begin with x- which is reserved for user extensions. I. Acknowledgments The Editors acknowledge the current and former members of the Timed Text Working Group, the members of other W3C Working Groups, the members of the Audio Description Community Group, and industry experts in other forums who have contributed directly or indirectly to the process or content of this document. The Editors wish to especially acknowledge the following contributions by members: Glenn Adams, Skynav; Pierre-Anthony Lemieux, MovieLabs; Hewson Maxwell, Ericsson; Chris Needham, British Broadcasting Corporation; Atsushi Shimono, W3C ; Matt Simpson, Invited Expert; Andreas Tai, Invited Expert. J. References J.1 Normative references [BCP47] Tags for Identifying Languages . A. Phillips, Ed.; M. Davis, Ed. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646 [EBU-R37] EBU Recommendation R37-2007. The relative timing of the sound and vision components of a television signal . EBU/UER. February 2007. URL: https://tech.ebu.ch/publications/r037 [EBU-TT-3390] EBU-TT Part M, Metadata Definitions . EBU/UER. May 2017. URL: https://tech.ebu.ch/publications/tech3390 [MIME-TYPES] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types . N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://www.rfc-editor.org/rfc/rfc2046 [namespaceState] The Disposition of Names in an XML Namespace . Norman Walsh. W3C. 29 March 2006. W3C Working Draft. URL: https://www.w3.org/TR/namespaceState/ [RFC2119] Key words for use in RFCs to Indicate Requirement Levels . S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119 [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words . B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174 [TTML-IMSC1.2] TTML Profiles for Internet Media Subtitles and Captions 1.2 . Pierre-Anthony Lemieux. W3C. 4 August 2020. W3C Recommendation. URL: https://www.w3.org/TR/ttml-imsc1.2/ [TTML1] Timed Text Markup Language 1 (TTML1) (Third Edition) . Glenn Adams; Pierre-Anthony Lemieux. W3C. 8 November 2018. W3C Recommendation. URL: https://www.w3.org/TR/ttml1/ [TTML2] Timed Text Markup Language 2 (TTML2) (2nd Edition) . W3C. 2021-03-09. URL: https://www.w3.org/TR/2021/CR-ttml2-20210309 [UNICODE] The Unicode Standard . Unicode Consortium. URL: https://www.unicode.org/versions/latest/ [w3c-process] W3C Process Document . Elika J. Etemad (fantasai); Florian Rivoal. W3C. 18 August 2025. URL: https://www.w3.org/policies/process/ [XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/ [xml-names] Namespaces in XML 1.0 (Third Edition) . Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL: https://www.w3.org/TR/xml-names/ [xmlschema-2] XML Schema Part 2: Datatypes Second Edition . Paul V. Biron; Ashok Malhotra. W3C. 28 October 2004. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema-2/ [XPath] XML Path Language (XPath) Version 1.0 . James Clark; Steven DeRose. W3C. 16 November 1999. W3C Recommendation. URL: https://www.w3.org/TR/xpath-10/ J.2 Informative references [BBC-WHP051] BBC R&D White Paper WHP 051. Audio Description: what it is and how it works . N.E. Tanton, T. Ware and M. Armstrong. October 2002 (revised July 2004). URL: https://www.bbc.co.uk/rd/publications/whitepaper051 [DAPT-REQS] DAPT Requirements . Cyril Concolato; Nigel Megitt. W3C. 12 May 2025. W3C Working Group Note. URL: https://www.w3.org/TR/dapt-reqs/ [I18N-INLINE-BIDI] Inline markup and bidirectional text in HTML . W3C. 2021-06-25. URL: https://www.w3.org/International/articles/inline-bidi-markup [media-accessibility-reqs] Media Accessibility User Requirements . Shane McCarron; Michael Cooper; Mark Sadecki. W3C. 3 December 2015. W3C Working Group Note. URL: https://www.w3.org/TR/media-accessibility-reqs/ [SSML] Speech Synthesis Markup Language (SSML) Version 1.1 . Daniel Burnett; Zhi Wei Shuang. W3C. 7 September 2010. W3C Recommendation. URL: https://www.w3.org/TR/speech-synthesis11/ [uml] OMG Unified Modeling Language . Open Management Group. OMG. 1 March 2015. Normative. URL: http://www.omg.org/spec/UML/ [WCAG22] Web Content Accessibility Guidelines (WCAG) 2.2 . Michael Cooper; Andrew Kirkpatrick; Alastair Campbell; Rachael Bradley Montgomery; Charles Adams. W3C. 12 December 2024. W3C Recommendation. URL: https://www.w3.org/TR/WCAG22/ [webaudio] Web Audio API . Paul Adenot; Hongchan Choi. W3C. 17 June 2021. W3C Recommendation. URL: https://www.w3.org/TR/webaudio-1.0/ [xml-id] xml:id Version 1.0 . Jonathan Marsh; Daniel Veillard; Norman Walsh. W3C. 9 September 2005. W3C Recommendation. URL: https://www.w3.org/TR/xml-id/ ↑ Permalink Referenced in: § 2.1 Transcripts and Scripts (2) (3) (4) (5) § 2.1.1 Dubbing scripts (2) § 2.2.1 Basic document structure (2) (3) § 2.2.3 Dubbing Examples § 4.1 DAPT Script § 4.1.3 Script Type (2) § 4.3 Script Event Permalink Referenced in: § 2.1 Transcripts and Scripts (2) (3) (4) (5) § 2.1.1 Dubbing scripts (2) (3) § 2.1.2 Audio Description scripts (2) (3) § 2.2.1 Basic document structure (2) § 2.2.2 Audio Description Examples (2) § 4.1 DAPT Script § 4.1.2 Default Language § 4.1.3 Script Type (2) (3) § 4.4 Text § F.1 Disposition of Features and Extensions Permalink Referenced in: § 1. Scope § 4.2 Character Permalink Referenced in: § 2.1.1 Dubbing scripts (2) § 4.1 DAPT Script § 4.3 Script Event Permalink Referenced in: § 1. Scope § 2.1 Transcripts and Scripts (2) § 2.1.2 Audio Description scripts (2) § 2.2.1 Basic document structure § 4.1.3 Script Type (2) § 4.3 Script Event § 5.2.3 Proprietary Metadata and Foreign Vocabulary Permalink Referenced in: § 2.1.2 Audio Description scripts § 5.4 Related Media Object Permalink Referenced in: § 2.1.2 Audio Description scripts § D.1 DAPT Origin Timecode Permalink Referenced in: § 2.1 Transcripts and Scripts (2) (3) (4) (5) (6) (7) (8) (9) § 2.1.3 Other uses § 2.2.1 Basic document structure § 4.1 DAPT Script § 4.1.1 Script Represents § 4.1.2 Default Language (2) § 4.1.3 Script Type (2) § 4.1.4 Script Events § 4.1.5 Characters § 4.1.6.1 Timing Properties (2) § 4.1.6.3 Unique identifiers § 4.4 Text § 4.7 Represents § 4.9.1 Audio Recording (2) § 6. Mapping from TTML to the DAPT Data Model § D.1 DAPT Origin Timecode (2) § D.2 Start of Programme Timecode (2) § F.1 Disposition of Features and Extensions § F.2 DAPT Content Profile § F.3 DAPT Processor Profile Permalink Referenced in: § 2.1 Transcripts and Scripts § 2.1.1 Dubbing scripts § 4.1 DAPT Script § 4.1.2 Default Language § 4.1.4 Script Events § 4.1.5 Characters § 4.1.6.3 Unique identifiers § 4.2 Character (2) § 4.3 Script Event § 4.4 Text (2) § 4.5 Text Language Source § 4.6 On Screen § 4.7 Represents (2) § 4.8 Script Event Description (2) § 4.9.1 Audio Recording § 4.9.2 Synthesized Audio (2) § 5.1 Document Encoding (2) § 5.2 Processing of unrecognised or foreign elements and attributes (2) (3) § 5.2.2 Special considerations for foreign vocabulary (2) § 5.3 Namespaces § 5.4 Related Media Object § 5.5 Synchronization (2) (3) (4) § 5.6 Profile Signaling (2) § 5.6.2 ttp:contentProfiles (2) § 5.6.3 ttp:profile § 5.6.4 ttp:processorProfiles (2) § 5.6.5 Other TTML2 Profile Vocabulary § 6. Mapping from TTML to the DAPT Data Model (2) (3) (4) (5) § 6.1 Early identification of non-conformant documents (2) § 6.2 Not supporting features excluded by the content profile § 6.5.1 Retaining unrecognised vocabulary § 6.5.2 Validation warnings and errors § 7. Conformance § 7.1 Conformance of DAPT Documents (2) (3) (4) § C. Security Considerations § D. Timecode-related metadata (2) (3) (4) (5) (6) § D.1 DAPT Origin Timecode (2) (3) § D.2 Start of Programme Timecode (2) § F.1 Disposition of Features and Extensions (2) § F.2 DAPT Content Profile (2) § F.3 DAPT Processor Profile (2) § G.9 #scriptEventMapping (2) § G.11 #scriptType-root Permalink Referenced in: § 2.2.2 Audio Description Examples (2) § 4.1 DAPT Script § 4.1.1 Script Represents § 4.1.6.2 <content-descriptor> values (2) § 4.7 Represents § F.1 Disposition of Features and Extensions Permalink Referenced in: § 6.4 Using computed attribute values § G.10 #scriptRepresents-root (2) Permalink Referenced in: § 2.2.3 Dubbing Examples § 4.1 DAPT Script § 4.1.2 Default Language (2) (3) (4) § 4.4 Text (2) (3) § 6.4 Using computed attribute values Permalink Referenced in: § 4.1.3 Script Type (2) (3) (4) Permalink Referenced in: § 4.1 DAPT Script § 4.1.3 Script Type § 4.4 Text Permalink Referenced in: § G.11 #scriptType-root (2) (3) Permalink Referenced in: § 2.1.3 Other uses (2) § 4.1.2 Default Language § 4.1.3 Script Type (2) (3) (4) (5) (6) (7) Permalink Referenced in: § 2.1.3 Other uses § 4.1.3 Script Type (2) (3) (4) (5) Permalink Referenced in: § 2.2.2 Audio Description Examples § 4.1.3 Script Type (2) (3) § 4.3 Script Event Permalink Referenced in: § 4.1.3 Script Type (2) § 4.3 Script Event Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax Permalink Referenced in: § 4.1.6.1 Timing Properties § 4.3 Script Event § 4.10 Mixing Instruction § 6.4 Using computed attribute values Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax (2) (3) § 4.1.6.1 Timing Properties (2) § 4.3 Script Event (2) § 4.9.1 Audio Recording (2) § 4.10 Mixing Instruction (2) § 6.4 Using computed attribute values (2) (3) § D.1 DAPT Origin Timecode (2) (3) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax (2) (3) § 4.1.6.1 Timing Properties (2) (3) § 4.3 Script Event (2) § 4.9.1 Audio Recording (2) § 4.10 Mixing Instruction (2) § 6.4 Using computed attribute values (2) § D.1 DAPT Origin Timecode (2) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax (2) (3) § 4.1.6.1 Timing Properties (2) (3) § 4.3 Script Event (2) § 4.9.1 Audio Recording (2) § 4.10 Mixing Instruction (2) § 6.4 Using computed attribute values Permalink Referenced in: § 4.1.1 Script Represents § 4.1.6.2 <content-descriptor> values (2) (3) (4) (5) (6) (7) § 4.7 Represents (2) Permalink Referenced in: § 4.1.6.2 <content-descriptor> values (2) (3) Permalink Referenced in: § 2.2.2 Audio Description Examples § 4.1.6.2 <content-descriptor> values (2) (3) (4) (5) (6) § 4.7 Represents Permalink Referenced in: § 4.1.6.3 Unique identifiers (2) § 4.2 Character § 4.3 Script Event § 6.4 Using computed attribute values Permalink Referenced in: § 4.1 DAPT Script § 4.1.5 Characters (2) (3) (4) § 4.2 Character (2) (3) (4) (5) (6) (7) (8) (9) § 4.3 Script Event (2) (3) (4) (5) (6) (7) (8) § 4.6 On Screen Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.1.6.3 Unique identifiers § 4.2 Character § 4.3 Script Event (2) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.2 Character Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.2 Character (2) (3) (4) (5) (6) (7) (8) (9) Permalink Referenced in: § 2.2.2 Audio Description Examples § 4.1 DAPT Script § 4.1.1 Script Represents § 4.1.2 Default Language (2) (3) (4) § 4.1.3 Script Type (2) (3) (4) (5) (6) (7) (8) (9) § 4.1.4 Script Events (2) § 4.1.5 Characters § 4.2 Character § 4.3 Script Event (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) § 4.4 Text (2) (3) (4) (5) (6) (7) (8) § 4.6 On Screen (2) (3) (4) (5) (6) (7) § 4.7 Represents § 4.8 Script Event Description (2) (3) (4) § 5.2.3 Proprietary Metadata and Foreign Vocabulary § 6. Mapping from TTML to the DAPT Data Model § 6.3 Handling <div> and <p> elements (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) § 6.4 Using computed attribute values (2) (3) § D. Timecode-related metadata § D.1 DAPT Origin Timecode (2) (3) (4) (5) § D.2 Start of Programme Timecode § E.1 Web Audio § F.1 Disposition of Features and Extensions Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.1.6.3 Unique identifiers § 4.3 Script Event § 6.3 Handling <div> and <p> elements Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.1.2 Default Language (2) (3) (4) § 4.1.3 Script Type (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) § 4.3 Script Event (2) (3) (4) (5) § 4.4 Text (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) § 4.5 Text Language Source (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) § 4.7 Represents § 4.9 Audio (2) § 4.9.1 Audio Recording § 4.9.2 Synthesized Audio (2) § 6.3 Handling <div> and <p> elements (2) (3) (4) (5) (6) (7) § E.1 Web Audio (2) (3) Permalink Referenced in: § 4.1.2 Default Language § 4.1.3 Script Type (2) (3) (4) (5) (6) (7) § 4.3 Script Event § 4.4 Text (2) (3) (4) (5) (6) (7) (8) § 4.5 Text Language Source (2) (3) (4) (5) Permalink Referenced in: § 4.1.2 Default Language (2) § 4.1.3 Script Type (2) (3) (4) (5) (6) (7) (8) § 4.3 Script Event § 4.4 Text (2) (3) (4) (5) § 4.5 Text Language Source (2) Permalink Referenced in: § 2.2.2 Audio Description Examples (2) § 2.2.3 Dubbing Examples § 4.1 DAPT Script § 4.1.3 Script Type (2) (3) (4) § 4.4 Text (2) (3) (4) § 4.5 Text Language Source (2) (3) (4) § 6.4 Using computed attribute values Permalink Referenced in: § 2.2.1 Basic document structure § 2.2.2 Audio Description Examples § 2.2.3 Dubbing Examples (2) § 4.1.2 Default Language § 4.4 Text (2) (3) (4) (5) (6) (7) (8) (9) § 4.5 Text Language Source (2) (3) (4) § G.14 #textLanguageSource Permalink Referenced in: § 4.3 Script Event (2) § 4.6 On Screen (2) Permalink Referenced in: § 6.4 Using computed attribute values § G.6 #onScreen Permalink Referenced in: § 2.1 Transcripts and Scripts § 2.2.2 Audio Description Examples § 4.1.1 Script Represents § 4.1.6.2 <content-descriptor> values (2) § 4.3 Script Event (2) (3) (4) (5) § 4.4 Text (2) (3) (4) (5) (6) § 4.7 Represents (2) (3) (4) (5) (6) (7) § 6.4 Using computed attribute values § F.1 Disposition of Features and Extensions Permalink Referenced in: § 4.3 Script Event (2) (3) § 4.4 Text § 4.6 On Screen § 4.7 Represents § G.8 #represents (2) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.3 Script Event § 4.8 Script Event Description (2) (3) (4) (5) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.8 Script Event Description (2) Permalink Referenced in: § 4.8 Script Event Description § 6.4 Using computed attribute values § F.1 Disposition of Features and Extensions § G.5 #descType Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.1.3 Script Type § 4.9 Audio (2) (3) (4) § 4.9.1 Audio Recording § 4.9.2 Synthesized Audio § 4.10 Mixing Instruction Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.1.3 Script Type § 4.4 Text § 4.9 Audio (2) § 4.9.1 Audio Recording (2) (3) (4) (5) (6) (7) (8) § E.1 Web Audio § E.2 Pop prevention (2) (3) (4) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.9.1 Audio Recording (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.9.1 Audio Recording (2) (3) (4) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.9.1 Audio Recording (2) § E.2 Pop prevention (2) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.9.1 Audio Recording (2) § E.2 Pop prevention (2) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.1.3 Script Type § 4.9 Audio (2) § 4.9.2 Synthesized Audio (2) (3) (4) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.9.2 Synthesized Audio Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.9.2 Synthesized Audio Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.3 Script Event § 4.4 Text (2) § 4.9.1 Audio Recording (2) § 4.10 Mixing Instruction (2) (3) (4) (5) § E.1 Web Audio (2) (3) (4) (5) § E.2 Pop prevention Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.10 Mixing Instruction (2) (3) (4) § E.2 Pop prevention Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.10 Mixing Instruction (2) (3) (4) Permalink Referenced in: § 4. DAPT Data Model and corresponding TTML syntax § 4.10 Mixing Instruction Permalink Referenced in: § 5.2.1 Unrecognised vocabulary (2) (3) § 5.2.2 Special considerations for foreign vocabulary § 6.3 Handling <div> and <p> elements § 6.5.1 Retaining unrecognised vocabulary (2) Permalink Referenced in: § 5.2.2 Special considerations for foreign vocabulary (2) § 5.2.3 Proprietary Metadata and Foreign Vocabulary § 5.2.3.1 Defining and using foreign vocabulary that is not metadata (2) § 7.1 Conformance of DAPT Documents Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 6.3 Handling <div> and <p> elements Permalink exported Referenced in: § 6.3 Handling <div> and <p> elements Permalink Referenced in: § F.1 Disposition of Features and Extensions § G.1 General Permalink Referenced in: Not referenced in this document. Permalink exported Referenced in: Not referenced in this document. Permalink exported Referenced in: Not referenced in this document. Permalink Referenced in: § 4.3 Script Event Permalink Referenced in: § 5.9 Bidirectional text Permalink Referenced in: § 2.1.2 Audio Description scripts Permalink Referenced in: § G.3 #contentProfiles-root Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions § G.3 #contentProfiles-root (2) Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions § G.7 #profile-root (2) Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § 5.7.1 ttp:timeBase § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § F.1 Disposition of Features and Extensions Permalink Referenced in: § 4.10 Mixing Instruction (2) Permalink Referenced in: § 4.9.1 Audio Recording (2) Permalink Referenced in: § 4.9.1 Audio Recording Permalink Referenced in: § 4.9.1 Audio Recording (2) § G.13 #source-data (2) Permalink Referenced in: § 4.1.1 Script Represents Permalink Referenced in: § 4.9.1 Audio Recording (2) (3) § G.13 #source-data (2) Permalink Referenced in: § D.1 DAPT Origin Timecode Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary § F. Profiles (2) (3) Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary § F. Profiles (2) (3) Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary § F. Profiles Permalink Referenced in: § 4.10 Mixing Instruction (2) Permalink Referenced in: § 5.5 Synchronization § 5.7.5 Time expressions § 7.2 Conformance of DAPT Processors (2) (3) Permalink Referenced in: § 2.2.1 Basic document structure § 5.2 Processing of unrecognised or foreign elements and attributes § 5.2.2 Special considerations for foreign vocabulary § 5.6.1 Profile Designators § 5.6.2 ttp:contentProfiles (2) § 6.1 Early identification of non-conformant documents § 7.1 Conformance of DAPT Documents § F. Profiles (2) (3) § F.1 Disposition of Features and Extensions § G.8 #represents § G.10 #scriptRepresents-root § G.11 #scriptType-root Permalink Referenced in: § 5.6 Profile Signaling § 5.6.3 ttp:profile § 5.6.4 ttp:processorProfiles (2) § 5.6.5 Other TTML2 Profile Vocabulary (2) § 6. Mapping from TTML to the DAPT Data Model § 6.4 Using computed attribute values § 6.5.2 Validation warnings and errors § C. Security Considerations § F. Profiles Permalink Referenced in: § F. Profiles (2) (3) (4) (5) (6) (7) (8) § F.1 Disposition of Features and Extensions § G.1 General Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary § 5.8 Layout and styles § F. Profiles (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) § F.1 Disposition of Features and Extensions (2) Permalink Referenced in: § 4.9 Audio § 4.9.1 Audio Recording (2) § 5.2.1 Unrecognised vocabulary § 6. Mapping from TTML to the DAPT Data Model § 7.2 Conformance of DAPT Processors (2) (3) (4) § E.2 Pop prevention (2) § F. Profiles (2) (3) (4) § F.1 Disposition of Features and Extensions (2) § G.2 #agent § G.3 #contentProfiles-root § G.4 #daptOriginTimecode § G.5 #descType § G.6 #onScreen § G.7 #profile-root § G.8 #represents § G.9 #scriptEventMapping (2) § G.10 #scriptRepresents-root (2) § G.11 #scriptType-root § G.12 #serialization § G.13 #source-data § G.14 #textLanguageSource § G.15 #xmlLang-audio-nonMatching § G.16 #xmlLang-root Permalink Referenced in: § 5.6.1 Profile Designators § 5.6.4 ttp:processorProfiles § 7.2 Conformance of DAPT Processors § F. Profiles (2) (3) (4) Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary § 7.1 Conformance of DAPT Documents § 7.2 Conformance of DAPT Processors Permalink Referenced in: § F. Profiles Permalink Referenced in: § 7. Conformance § F. Profiles Permalink Referenced in: § 4.1.1 Script Represents § 4.1.6.1 Timing Properties § 4.4 Text § 4.7 Represents § 4.9 Audio § 4.9.1 Audio Recording § 5.4 Related Media Object (2) § 5.7.1 ttp:timeBase § D. Timecode-related metadata § D.1 DAPT Origin Timecode § D.2 Start of Programme Timecode (2) (3) (4) Permalink Referenced in: § 4.1 DAPT Script (2) § 7.1 Conformance of DAPT Documents § F. Profiles (2) (3) (4) § G.8 #represents § G.10 #scriptRepresents-root § G.11 #scriptType-root Permalink Referenced in: § 5.2.1 Unrecognised vocabulary (2) (3) § 5.2.3 Proprietary Metadata and Foreign Vocabulary § 5.2.3.1 Defining and using foreign vocabulary that is not metadata § 5.6.2 ttp:contentProfiles § 7.2 Conformance of DAPT Processors (2) § F. Profiles (2) (3) (4) § F.1 Disposition of Features and Extensions (2) § G.2 #agent § G.3 #contentProfiles-root § G.4 #daptOriginTimecode § G.5 #descType § G.6 #onScreen § G.7 #profile-root § G.8 #represents (2) § G.9 #scriptEventMapping (2) § G.10 #scriptRepresents-root (2) § G.11 #scriptType-root (2) § G.12 #serialization (2) § G.13 #source-data § G.14 #textLanguageSource § G.15 #xmlLang-audio-nonMatching § G.16 #xmlLang-root Permalink Referenced in: § 4.10 Mixing Instruction (2) Permalink Referenced in: § 4.10 Mixing Instruction (2) Permalink Referenced in: § 4.9.2 Synthesized Audio Permalink Referenced in: § 4.9.2 Synthesized Audio Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary Permalink Referenced in: § 2.2.1 Basic document structure § 5.2.2 Special considerations for foreign vocabulary § 5.6.2 ttp:contentProfiles (2) (3) § G.3 #contentProfiles-root (2) Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary Permalink Referenced in: § 5.6.5 Other TTML2 Profile Vocabulary Permalink Referenced in: § 5.6.3 ttp:profile § 5.6.4 ttp:processorProfiles (2) (3) (4) (5) Permalink Referenced in: § 5.6.3 ttp:profile § G.3 #contentProfiles-root § G.7 #profile-root (2) (3) Permalink Referenced in: § 6.5.2 Validation warnings and errors (2) § 7.2 Conformance of DAPT Processors (2) Permalink Referenced in: § Status of This Document (2) Permalink Referenced in: § H.1.1 Custodianship Permalink Referenced in: § H.1.1 Custodianship (2) (3) § H.1.2.1 Requesting a change § H.1.2.2 Change request assessment process § H.1.2.2.1 Custodian is TTWG § H.1.2.2.2 Custodian is the W3C Team Permalink Referenced in: § H.1 Registry Definition Permalink Referenced in: § H.1.2.1 Requesting a change (2) (3) (4) § H.1.3 Registry Table Constraints (2) § H.1.3.1 Registry Entries (2) § H.1.3.1.1 Status § H.1.3.1.1.1 Provisional (2) (3) § H.1.3.1.1.2 Final (2) (3) § H.1.3.1.1.3 Deprecated (2) (3) (4) § H.2 Registry Table Definitions § H.2.1 daptm:descType registry table definition § H.2.2 <content-descriptor> registry table definition Permalink Referenced in: § Status of This Document § 3. Documentation Conventions Permalink Referenced in: § Status of This Document (2) § 4.1.6.2 <content-descriptor> values (2) § 4.8 Script Event Description (2) § H.1 Registry Definition § H.1.2.1 Requesting a change § H.1.3 Registry Table Constraints (2) (3) § H.2 Registry Table Definitions § H.2.1 daptm:descType registry table definition (2) (3) § H.2.2 <content-descriptor> registry table definition (2) (3) Permalink Referenced in: § Status of This Document Permalink Referenced in: § Status of This Document § H.1.1 Custodianship § H.1.2.1 Requesting a change Permalink Referenced in: § H.1.1 Custodianship § H.1.2.2.2 Custodian is the W3C Team Permalink Referenced in: § H.1.2.2.2 Custodian is the W3C Team Permalink Referenced in: § 5.1 Document Encoding Permalink Referenced in: § G.12 #serialization Permalink Referenced in: § G.12 #serialization Permalink Referenced in: § 5.1 Document Encoding § G.12 #serialization Permalink Referenced in: § 4.1.6.3 Unique identifiers Permalink Referenced in: § 4.1.6.2 <content-descriptor> values Permalink Referenced in: § 5.1 Document Encoding § G.12 #serialization Permalink Referenced in: § 4.1.6.2 <content-descriptor> values Permalink Referenced in: § 3. Documentation Conventions Permalink Referenced in: § D. Timecode-related metadata (2) § D.1 DAPT Origin Timecode (2) (3) (4) (5) (6) (7) (8) (9) (10) § D.2 Start of Programme Timecode (2) (3) Permalink Referenced in: § G.4 #daptOriginTimecode Permalink Referenced in: § D. Timecode-related metadata (2) § D.1 DAPT Origin Timecode (2) (3) (4) § D.2 Start of Programme Timecode (2) (3) (4) (5) Permalink Referenced in: § G.15 #xmlLang-audio-nonMatching Permalink Referenced in: § H.1.1 Custodianship § H.1.2.1 Requesting a change (2) § H.1.2.2.1 Custodian is TTWG Permalink Referenced in: § H.1.2.1 Requesting a change (2) § H.1.2.2 Change request assessment process § H.1.2.2.1 Custodian is TTWG (2) (3) (4) (5) § H.1.2.2.2 Custodian is the W3C Team Permalink Referenced in: § H.1.3.1 Registry Entries Permalink Referenced in: § H.1.3.1 Registry Entries (2) (3) (4) § H.1.3.1.1.1 Provisional § H.1.3.1.1.2 Final § H.1.3.1.1.3 Deprecated (2) (3) § H.2.1 daptm:descType registry table definition (2) § H.2.2 <content-descriptor> registry table definition (2) Permalink Referenced in: § H.1.3 Registry Table Constraints § H.1.3.1 Registry Entries (2) (3) (4) Permalink Referenced in: § H.1.2.1 Requesting a change § H.1.3.1 Registry Entries § H.1.3.1.1.1 Provisional (2) (3) § H.1.3.1.1.2 Final (2) (3) § H.1.3.1.1.3 Deprecated (2) (3) (4) Permalink Referenced in: § H.1.2.1 Requesting a change § H.1.3.1.1.1 Provisional (2) § H.1.3.1.1.3 Deprecated Permalink Referenced in: § H.1.3.1.1.1 Provisional § H.1.3.1.1.2 Final (2) § H.1.3.1.1.3 Deprecated (2) (3) (4) Permalink Referenced in: § H.1.3.1.1.1 Provisional § H.1.3.1.1.2 Final § H.1.3.1.1.3 Deprecated (2) (3)

2025

Related documents