profile summary

In an attempt to lay some groundwork for how we want to improve the profile
mechanism, I undertook an attempt to summarize the various provisions of
TTML1SE. This is not intended to replace the normative provisions, but
rather summarize them (hopefully clearer) as well as capture some indirect
implications.

 

After everyone digests this a bit, then we may be able to have a framework
in which to discuss the various open issues on profiles.

1.       Profiles are used today to signal, in an instance document, what
TTML features and extensions are required by a processor to process the
document. Today, profiles are not used to signal instance document
conformance (but see below).

2.       All instance documents should contain a profile parameter attribute
or a profile element.

3.       Processors not supporting all of the required features and
extensions signaled in the instance document by a profile parameter
attribute or a profile element must reject the document unless 1) there is
an explicit override from the user or system configuration; or 2) the
profile is not available to the processor.

4.       By including a feature or extension designator in a profile, the
full syntax and the minimum required semantics (as defined by the referenced
feature or extension) must be supported by the processor. It is not valid
for a processor to continue processing a document that requires support for
a feature or extension if it only supports some subset of that feature
defined elsewhere.

5.       If desired features or extensions do not meet or exceed existing
defined features or extensions, then the profile designer must either
propose a new feature designator be added to TTML, or define a new extension
designator that describes the constrained feature. In other words, if
support for a strict subset of a feature or extension is intended, then a
new subset feature or extension needs to be defined

6.       Profile designers are required to define a profile document and
should publish a URI that would reasonably resolve to such a document.
Failing to publish the URI has potentially negative interoperability
consequences. It is recommended that the URI be a URL using the HTTP scheme
for better interoperability.

7.       If processors do not recognize a profile from the profile
designator URI and it wishes to present the document, then unless there is
an override, it is required to attempt to resolve and analyze the profile
document.

8.   Profile mechanisms are expected to be extended in TTML2 to:

a.  Add support to use the profile mechanism to declare document
conformance;

b.  Add the designator property of "prohibited" (mostly in support of (a));
and

c. Other enhancements as appropriate

 

 

 

Michael A DOLAN

TBT, Inc.    PO Box 190

Del Mar, CA 92014

(m) +1-858-882-7497

mdolan@newtbt.com