ISSUE-450: IMSC1 Does Not Require Any Feature/Extension be supported by a Processor

IMSC1 Does Not Require Any Feature/Extension be supported by a Processor

Raised by:
Glenn Adams
Opened on:
As written, ISMC1 does not require a presentation or transformation processor to support any feature whatsoever. Specifically, the language in section 4

"be capable of presenting [transforming] any Document Instance that conforms to the profile, i.e. if it implements all features and provisions of the profile"

does not actually require support for any feature since "capable of presenting [transforming]" may mean present a blank screen or transform into a null string.

The real problem is that this profile specification does not define processor profiles but attempts to use the process profile definition mechanism of TTML1 to describe content profiles independently from processor profiles. Specifically, no where in IMSC1 appears a specification of the form <feature value="required">...</feature> or <extension value="required">...</extension>.
Related Actions Items:
No related actions
Related emails:
  1. {minutes} TTWG Meeting 2015-10-30 (from on 2015-10-30)
  2. {minutes} TTWG Meeting 2015-10-29 (from on 2015-10-29)
  3. {agenda} TTWG Meeting 2015-10-22 (from on 2015-10-21)
  4. Re: Processor Profile, Content Profile and codecs (from on 2015-10-19)
  5. {agenda} TTWG Meeting 2015-10-15 (from on 2015-10-14)
  6. ISSUE-452 (Profile element may be misused): The ttp:profile element is permitted to conflict with the IMSC 1 profile [TTML IMSC 1.0] (from on 2015-10-09)
  7. ISSUE-450: IMSC1 Does Not Require Any Feature/Extension be supported by a Processor [TTML IMSC 1.0] (from on 2015-10-09)

Related notes:

To elaborate, the expression

*FEATURE* "MAY be used" [in a conforming document instance]

does not mean a processor is REQUIRED to support *FEATURE*.

Glenn Adams, 9 Oct 2015, 05:20:47

Actually, I see with a recent edit that exactly one feature is required to be supported: #lineBreak-uax14 (section 7.4).

The way to fix this would be to define a text and image profile document inline in the spec that are similar to those found in TTML1 Appendix F, and reference those profiles from the conformance section.

I expect the original intent of IMSC1 is that any feature marked as "MAY be used" implies that feature is REQUIRED to be supported by a processor. In some cases, this means that some features that are marked SHALL NOT be used are actually required to be supported. For example, #fontSize-anamorphic is designated SHALL NOT use; however, #fontSize is designated MAY use. Since #fontSize requires support for both #fontSize-anamorphic and #fontSize-isomorphic, then support for both are required even though only isomorphic can be used in a document.

Glenn Adams, 9 Oct 2015, 05:52:25

Proposed wording to allow the processor features to define document syntax:

Documents may use any vocabulary, syntax or attribute values whose interpretation will be successfully processed by a processor that supports the following features:

[allowed feature set]

Documents shall not use any syntax for which successful processing cannot be guaranteed except by (non-conformant) processors that support the following features:

Documents shall not use any vocabulary, syntax or attribute values which would require the processor to implement any of the following features to successfully process the document:

[prohibited feature set]

Nigel Megitt, 28 Oct 2015, 06:46:41

Additionally we should consider amending the conformance section for processors to reference the same feature whitelist.

Nigel Megitt, 28 Oct 2015, 06:52:13

I also propose adding two columns to the whitelist: document constraints and processor constraints.

Nigel Megitt, 28 Oct 2015, 08:08:47

Addressed at

Pierre-Anthony Lemieux, 29 Oct 2015, 08:39:55

Further change to Section 4 at

Pierre-Anthony Lemieux, 30 Oct 2015, 03:04:00

[nigel]: [Meeting 2015-10-30] Change implemented above as agreed.

30 Oct 2015, 03:04:33

Display change log ATOM feed

David Singer <>, Nigel Megitt <>, Chairs, Thierry Michel <>, Philippe Le H├ęgaret <>, Atsushi Shimono <>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 450.html,v 1.1 2019/11/12 10:08:00 carcone Exp $