Optionality of ttp:profile is overly lax in the case of image profile use.

[skynavga]

In the Sapporo F2F the WG decided to make ttp:profile optional. This was based on (1) the desire to support EBU-TT-D and (2) the statement made (and repeated of late) that EBU-TT-D prohibits the presence of ttp:profile. Although there is now some question as to whether EBU-TT-D really does specify such a prohibition (or merely intended to do so), the decision made on optionality of ttp:profile did not adequately consider the case of a document alleged to conform to the IMSC1 image profile. In particular, since an IMSC1 image profile document cannot be a conforming EBU-TT-D document, there is a never a conflict (with EBU-TT content profiles) if the ttp:profile attribute is specified for all such documents. As such, I recommend that ttp:profile be required in the case of IMSC1 image profile documents.

[palemieux]

In the Sapporo F2F the WG decided to make ttp:profile optional.

ttp:profile had been optional prior to the Sapporo F2F (see Section 7.1 of the current CR at http://www.w3.org/TR/ttml-imsc1/). The discussion at the Sapporo F2F was in fact to recommend the presence of either ttp:profile or ebuttm:conformsToStandard.

This was based on (1) the desire to support EBU-TT-D and (2) the statement made (and repeated of late) that EBU-TT-D prohibits the presence of ttp:profile.

The fundamental reason goes beyond EBU-TT-D and is rooted in a limitation of TTML1: @ttp:profile, as specified in TTML1, supports only a single value, thereby preventing a document from claiming conformance to multiple profiles. For instance, a document could not claim conformance to both SMPTE-TT (http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-full) and IMSC-I (http://www.w3.org/ns/ttml/profile/imsc1/image), something that may be desirable in some applications.

TTML2 resolves this issue by allowing a document to claim conformance to multiple profiles simultaneously. In the meantime, ebuttm:conformsToStandard or external context can be used.

I propose resolving this issue in IMSC2.

[skynavga]

On Wed, Dec 30, 2015 at 3:43 PM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

In the Sapporo F2F the WG decided to make ttp:profile optional.

ttp:profile had been optional prior to the Sapporo F2F (see Section 7.1
of the current CR at http://www.w3.org/TR/ttml-imsc1/). The discussion at
the Sapporo F2F was in fact to recommend the presence of either ttp:profile
or ebuttm:conformsToStandard.

This was based on (1) the desire to support EBU-TT-D and (2) the statement
made (and repeated of late) that EBU-TT-D prohibits the presence of
ttp:profile.

The fundamental reason goes beyond EBU-TT-D and is rooted in a limitation
of TTML1: @ttp:profile, as specified in TTML1, supports only a single
value, thereby preventing a document from claiming conformance to multiple
profiles. For instance, a document could not claim conformance to both
SMPTE-TT (
http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-full) and
IMSC-I (http://www.w3.org/ns/ttml/profile/imsc1/image), something that
may be desirable in some applications.

TTML2 resolves this issue by allowing a document to claim conformance to
multiple profiles simultaneously. In the meantime,
ebuttm:conformsToStandard or external context can be used.

While the presence of an ebuttm attribute would allow a pre-processor to
guess it is not IMSC image profile, the absence of the attribute would not
provide any information.

I propose resolving this issue in IMSC2.

That would be acceptable (to me) provided we specify a fixed fallback
default value for ttp:profile as requested by Issue #111, the proposed
language of which allows the document interchange context to supply a
profile indication, e.g., by guessing a profile.

—
Reply to this email directly or view it on GitHub
#124 (comment).

[skynavga]

More.

On Wed, Dec 30, 2015 at 3:43 PM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

In the Sapporo F2F the WG decided to make ttp:profile optional.

ttp:profile had been optional prior to the Sapporo F2F (see Section 7.1
of the current CR at http://www.w3.org/TR/ttml-imsc1/). The discussion at
the Sapporo F2F was in fact to recommend the presence of either ttp:profile
or ebuttm:conformsToStandard.

This was based on (1) the desire to support EBU-TT-D and (2) the statement
made (and repeated of late) that EBU-TT-D prohibits the presence of
ttp:profile.

The fundamental reason goes beyond EBU-TT-D and is rooted in a limitation
of TTML1: @ttp:profile, as specified in TTML1, supports only a single
value, thereby preventing a document from claiming conformance to multiple
profiles.

There is a somewhat subtle semantic issue here: the @ttp:profile and
ttp:profile element is not (intended to be) used to claim conformance to a
content profile; rather, it is used to establish minimum processor
requirements for processing purposes.

Further, TTML1 permits the presence of multiple ttp:profile specifications
(via multiple ttp:profile elements), which effect is to take union of
requirements for feature support as indicated by the multiple profiles.

For instance, a document could not claim conformance to both SMPTE-TT (
http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-full) and
IMSC-I (http://www.w3.org/ns/ttml/profile/imsc1/image), something that
may be desirable in some applications.

Actually, a TTML1 document could specify the following:

<ttp:profile use="
http://www.smpte-ra.org/schemas/2052-1/2013/profiles/smpte-tt-full"/>
<ttp:profile use="http://www.w3.org/ns/ttml/profile/imsc1/image"/>

which, in TTML1 semantics, means that the processor must support all
features defined as required by either of these two profiles in order to
process the document normally.

In the TTML1 world, neither of these elements make a declaration about
document content conformance.

TTML2 resolves this issue by allowing a document to claim conformance to

multiple profiles simultaneously. In the meantime,
ebuttm:conformsToStandard or external context can be used.

In TTML2, a claim to multiple content profile conformance would be
specified as follows:

<tt ttp:contentProfiles="all(
http://www.smpte-ra.org/schemas/2052-1/2013/profiles/smpte-tt-full
http://www.w3.org/ns/ttml/profile/imsc1/image
)" ttp:contentProfileCombination="mostRestrictive" ...>
...

or

<tt ttp:contentProfiles="all(#p1 #p2)"
ttp:contentProfileCombination="mostRestrictive" ...>
...
<ttp:profile xml:id="p1" type="content" use="
http://www.smpte-ra.org/schemas/2052-1/2013/profiles/smpte-tt-full"/>
<ttp:profile xml:id="p2" type="content" use="
http://www.w3.org/ns/ttml/profile/imsc1/image"/>
...

I propose resolving this issue in IMSC2.

If we can agree to a reasonable fallback defaulting algorithm, then we
wouldn't need to mandate some profile specification.

—
Reply to this email directly or view it on GitHub
#124 (comment).