This document defines
the application/ttml+xml media
type and provides a registry of compact (short) identifiers that may be
used to identify TTML processor profiles. A processor profile specifies
a set of capabilities that a processor must support in order to process
a document, where this profile may be defined in a specification
document, in
a TTML
Profile Definition Document, inline within a TTML Document Instance,
or by using a combination of these methods. This document only
considers the first two of these methods since the third method (the use
of inline profile definitions) is not considered to be an identifiable,
shared profile definition, but rather, a private profile definition
scoped to the document instance in which it is defined.
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/.
Comments regarding this document are welcome.
Please send them to
[email protected]
(archives)
with [TTML-Profile-Registry] at the start of your
email's subject
.
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.
This document serves two purposes: (1) to define the Media Type
application/ttml+xml, and (2) to define a registry
of compact (short) identifiers of TTML processor profiles.
As a registry, this document is intended to provide a central location for enumerating
identified TTML processor 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
In the context of this registry, the term profile
means processor profile. It explicitly does not
mean content profile. That is, nothing about the use
of the profile
or codecs parameters 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 support
the codecs parameter.
The codecs parameter value syntax is defined as
codecs-parameter-value as follows,
expressed using the syntax expression conventions defined by §2.3 of [TTML2-1e].
identifier
: element // element defined by [RFC6381]
// where "+", "|" and "." are prohibited characters
// ("." is reserved as a hierarchy delimiter in [RFC6381])
and-group
: identifier ["+" identifier]* // no linear white-space is implied or permitted
// between each token
codecs-parameter-value
: and-group ["|" and-group]* // no linear white-space is implied or permitted
// between each token
The codecs parameter may
employ either (or both) of two combination operators, + (AND) and | (OR), which may be
used to specify, respectively, that all processor profiles apply
(simultaneously) or that any processor profile of a list of profiles may
apply individually. If both operators are used, then
the + operator has precedence.
Note
The + and | operators
are intended to have semantics equivalent to
the all(...) and the any(...)
function syntax supported by
the ttp:processorProfiles attribute as defined by
[TTML2-1e], §6.2.8. Take note, however, that the
combined use of both all(...) and any(...) in
a ttp:processorProfiles attribute value
expression is not directly supported by [TTML2-1e], and,
therefore, an application that encounters a combination of
both operators in a codecs value expression will
need to process such combination semantics as a higher level
protocol outside the scope of [TTML2-1e] semantics.
Note
The example A+B|C+D|E specifies that a TTML processor that implements
any one of the 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.
Note
For example,
the codecs string for specifying either a TTML processor that supports
[IMSC1.0.1] Text Profile or one that supports [EBU-TT-D-1]
would be "im1t|etd1".
The codecs string for specifying a TTML processor that supports
the union of sets of required features of both
[IMSC1.0.1] Text Profile and [EBU-TT-D-1]
would be "im1t+etd1".
Note
Another codecs parameter is defined by
[RFC6381] for application/mp4 (ISO BMFF) and
extended for TTML by [iso14496-30].
2. Media Type Registration
This section defines the media type "application/ttml+xml",
and, in conformance with
BCP 13
and W3CRegMedia,
serves as the registration thereof with the Internet Assigned
Numbers Authority (IANA).
This updated definition supersedes the initial registration
information specified in [TTML1-1e], Appendix C, as updated
by [TTML1-2e], Appendix C.
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.
Encoding considerations:
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:
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 [+|.].
Note
As a consequence of the above syntactic constraints,
the value space of the codecs parameter described
in § 2. Media Type Registration above is a syntactic subset of the
definition of the codecs parameter
defined by [RFC6381].
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. Although profiles can be
deleted, there is no intent to re-use deleted profile
values. That is, the intent is that profile entries are
"stable".
4. Registry
This section is the registry of short form profile
identifiers. The first sub-section details how such
identifiers should be dereferenced to profile designators, the
specifications that define those profiles, and the contact
organisation for each profile. The second sub-section
describes the mechanism used by each profile to permit
identification of the profile of a TTML Document Instance by
inspection of that document.
4.1 Profile designator and specifications
The following table defines the Profile Designator for each
short form Profile Identifier in this Registry, alongside
the public specification document in which the profile is
defined, and the relevant contact organisation. Entries are
ordered alphabetically according to the short profile
identifier.