This document defines the application/xml+ttml media type and provides a registry of identified TTML processor profiles. A processor profile is an identified reference to a set of capabilities that a processor supports, which may be defined in a specification document, a TTML Profile Definition Document or both.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This is a registry and may be updated without any notices.
This document was published by the Timed Text Working Group as a Working Group Note. If you wish to make comments regarding this document, please send them to
public-tt@w3.org (subscribe,
archives) with [TTML-Profile-Registry] at the start of your email's subject. All comments are welcome.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
TTML defines a MIME type/subtype, application/ttml+xml, that may be used to identify the content type of TTML resources. In addition, TTML as well as other W3C and non-W3C specifications define a number of processor profiles which define requirements on compliant processors that may decode and process a TTML document. This registry can be used by other entities to exchange processor profiles in a compact way. In certain TTML use cases, it is desirable for a processor to proceed with TTML resource fetch, decode, and processing only if it can be determined that the referenced resource is tentatively processable. In order to satisfy such use cases, it is possible for the referencing context to enumerate one or more named profiles, which, if supported by the processor, would allow a first-order determination to be made about whether a resource may be processed. We say first
order here since during actual decoding of a TTML resource, the processor profile declarations contained within the resource may result in the resource being rejected.
This registry is intended to provide a central location for enumerating identified TTML profiles, or, more strictly speaking, TTML decoder/processors, where each entry in the registry identifies a particular profile which is understood to implement a processor capable of satisfying the constraints of a defined TTML processor profile that takes the form of a TTML Profile Definition Document. By utilizing a common registry, it is possible to avoid name collisions among different profile defining fora.
Note Well that, in the context of this registry, when we use the term profile, we mean processor profile. We explicitly do not mean content profile. That is, nothing about the use of the profile parameter described here is intended to be used to identify or make claims about whether a TTML resource conforms with a TTML Content Profile or any type of TTML Profile that may be interpreted in whole or in part as making statements about the conformance of a TTML resource or the features of TTML (or other external specifications) actually used in the resource.
Applications using the entries in this registry are encouraged to adopt the following combination syntax:
Employ two combination operators, '+' (AND) and '|' (OR), which may be used to specify, respectively, that multiple processor profiles apply (simultaneously) or that any processor profile of a list of profiles may apply individually. If both operators are used in a codecs value, then the '+' operator has precedence.
The example: "A+B|C+D|E" states that a TTML processor that implements any one of A+B or C+D or E processor profiles satisfies the requirements to fetch and begin decode/processing of a TTML document, where X+Y means that both X and Y processor profiles must be supported, and X|Y means that either X or Y processor profile must be supported
This section updates the media type, "application/ttml+xml" to add a new parameter, codecs. All other provisions of the media type specification remain the same. This supersedes the initial registration information in TTML 1.0 Second Edition.
This section is in conformance with BCP 13 and W3CRegMedia. The information in this appendix is being submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with the Internet Assigned Numbers Authority (IANA).
Type name:
application
Subtype name:
ttml+xml
Required parameters:
None.
Optional parameters:
charset
If specified, the charset parameter must match the XML encoding declaration, or if absent, the actual encoding. See also Encoding Considerations below.
profile
The document profile of a TTMLDocument Instance may be specified using an optional profile parameter, which, if specified, the value of which must adhere to the syntax and semantics of
ttp:profile parameter defined by TTML 1.0 Second Edition, Section 6.2.8 ttp:profile of the published specification.
codecs
The optional codecs parameter provides a short form version of the profile parameter with multiple-profile combinatorial capability. If a short (4-character) form of a profile is registered in the TTML Profile Registry, it is recommended that this codecs parameter be used and not the profile parameter. The nominal value of this parameter is a single 4 character code from the registry.
Additionally, applications using the entries in the registry are encouraged to adopt the following combination syntax:
Employ two combination operators, '+' (AND) and '|' (OR), which may be used to specify, respectively, that multiple processor profiles apply (simultaneously) or that any processor profile of a list of profiles may apply individually. If both operators are used in a codecs value, then the '+' operator has precedence.
The example: "A+B|C+D|E" states that a TTML processor that implements any one of A+B or C+D or E processor profiles satisfies, at first order, the requirements to fetch and begin decode/processing of a TTML document, where X+Y means that both X and Y processor profiles must be supported, and X|Y means that either X or Y processor profile must be supported.
Same for application/xml, except constrained to either UTF-8 or UTF-16. See
IETF RFC 7303, XML Media Types, Section 3.2. For the purpose of filling out the IANA Application for Media Type (http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies.
Security considerations:
As with other XML types and as noted in IETF RFC 7303, XML Media Types, Section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail.
In addition, because of the extensibility features for TTML and of XML in general, it is possible that "application/ttml+xml" may describe content that has security implications beyond those described here. However, TTML does not provide for any sort of active or executable content, and if the processor follows only the normative semantics of the published specification, this content will be outside TTML namespaces and may be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document.
Although not prohibited, there are no expectations that XML signatures or encryption would normally be employed.
Interoperability considerations:
The published specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements and attributes, both in TTML namespaces and in other namespaces.
Because TTML is extensible, conformant "application/ttml+xml" processors may expect (and enforce) that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document.
TTML is used in the television industry for the purpose of authoring, transcoding and exchanging timed text information and for delivering captions, subtitles, and other metadata for television material repurposed for the Web or, more generally, the Internet.
There is partial and full support of TTML in components used by several Web browsers plugins, and in a number of caption authoring tools.
Additional information:
Magic number(s):
File extension(s):
.ttml
Macintosh file type code(s):
"TTML"
Fragment identifiers:
For documents labeled as application/ttml+xml, the fragment identifier notation is intended to be used with xml:id attributes, as described in section 7.2.1 of the Timed Text
Markup Language 1 (TTML1) specification.
Person & email address to contact for further
information:
Timed Text Working Group (public-tt@w3.org)
Intended usage:
COMMON
Restrictions on usage:
None
Author:
The published specification is a work product of the World Wide Web Consortium's Timed Text (TT) Working Group.
Change controller:
The W3C has change control over this specification.
3. Registration Entry Requirements and Update Process
Each entry must include a unique identification, where the scope of uniqueness is the set of identifiers defined in this registry. An identifier must conform with the element non-terminal of
RFC6381 and, furthermore, may not contain any of the characters in the regular expression character class [+|].
Each entry must include an absolute URI that serves as the TTML Profile Designator that identifies the processor profile.
Each entry should include a link that references a TTML Profile Definition Document that formally specifies the processor profile using TTML profile definition vocabulary.
Each entry should include a link that references a public available specification (PAS) that defines the identified processor profile.
Each entry must include contact information of the requestor.
An update to this registry is an addition, change or deletion of an entry. Any person can request an update to this registry by email notice to the chairman of the Timed Text Working Group who will place it on an upcoming meeting agenda and notify the requestor. Consideration and disposition of the request is by consensus of the W3C Timed Text Working Group. The Chair will then notify the requestor of the outcome and update the registry accordingly.