Updated profile signaling and resolution to match TTML2 semantics by palemieux · Pull Request #267 · w3c/imsc

palemieux · 2017-10-21T19:47:33Z

Close #3
Close #124
Close #125

Clarified profile signaling requirements

nigelmegitt · 2017-10-23T15:09:32Z

I'd like to step through this during a TTWG call please?

nigelmegitt

This is a pretty significant set of changes - I think the intent is right but some (not huge) changes requested about how they're done.

nigelmegitt · 2017-11-06T22:39:17Z


    <p><dfn>Extension</dfn>. See Section 2.2 at [[!TTML2]].</p>

+    <p><dfn>External Processing Context</dfn>. As defined in [[!TTML2]].</p>


External Processing Context is not actually defined by TTML2. Is this PR dependent on a TTML2 PR?

This should say Document Processing Context, which is already defined later.

nigelmegitt · 2017-11-06T22:41:42Z

+
+        <p>The Profile Semantics specified in [[!TTML2]] apply.</p>
+
+        <p>The following processor profiles are subsets of the <a>Text Profile</a> processor profile:</p>


"Processor profile" should be added as a defined term, and defined to be the same as in TTML2.

I would prefer to say "The Text Profile processor profile includes all of the features required by each of the following processor profiles:"

Rationale is that it makes it clearer that a Text Profile processor can be used in place of any of those, and in passing defines what we mean by "superset".

Sounds good.

nigelmegitt · 2017-11-06T22:45:45Z

+          <li>[[ttml-imsc1.0.1]] Text Profile</li>
+        </ul>
+
+        <p>The following processor profiles are subsets of the <a>Image Profile</a> processor profile:</p>


Similarly here, I would prefer: "The Image Profile processor profile includes all of the features required by each of the following processor profiles:"

Sounds good.

nigelmegitt · 2017-11-06T22:47:20Z

+        <h4>Override</h4>
+
+        <p>If the profile of the <a>Document Instance</a> is specified by the <a>external processing context</a>, then the
+        <em>override content profile</em> is set to this profile.</p>


I would prefer "is set to that profile" for clarity.

Sounds good.

nigelmegitt · 2017-11-06T22:51:28Z

+
+        <aside class="example">
+          The use of <code>mimeType="application/mp4"</code> and <code>codecs="stpp.ttml.im1t"</code> in a [[MPEGDASH]] Manifest
+          signals a track that consists of [[ttml-imsc1.0.1]] Text Profile documents.


I would elaborate this example further, for example: In this case the Manifest defines the external processing context, and the override profile is obtained from the [TTML Profile Registry] as specified by MPEG.

nigelmegitt · 2017-11-06T23:05:37Z

-        <p>Unless one of the mutually exclusive scenarios specified in the following Sections apply, the
-        <code>ttp:contentProfiles</code> attribute SHALL be present on the <code>tt</code> element and include the designator of
-        the profile (either the <a>Text Profile</a> or <a>Image Profile</a>) to which the <a>Document Instance</a> conforms.</p>
+        <p>Unless one of the mutually exclusive scenarios specified in the following Sections apply:</p>


I'm finding it hard to identify which scenarios in the following sections are "mutually exclusive". Can we be more explicit here about the exceptions? Or alternatively move this to the bottom and say "if none of the above scenarios apply then the following requirements apply:"

The idea is that the author needs to select one of the signaling options, and not mix and match.

Oh I see, you're saying "the following options are mutually exclusive", rather than selecting from those of the following options which happen to be mutually exclusive. Let's see, how can we deal with this... Why not just remove the words "mutually exclusive"?

nigelmegitt · 2017-11-06T23:12:38Z

+          <li>the <code>ttp:contentProfiles</code> attribute SHALL NOT be present.</li>
        </ul>
+
+        <p class="note">If the <code>ttp:profile</code> is not set as recommended above, then conformance with the


Worth specifying "ttp:profile attribute" for clarity.

nigelmegitt · 2017-11-06T23:13:04Z

        </ul>
+
+        <p class="note">If the <code>ttp:profile</code> is not set as recommended above, then conformance with the
+        [[ttml-imsc1.0.1]] profile is communicated using the <a>external processing context</a>.</p>


s/is communicated/can be communicated ?

There is no other option than to communicate the profile through the document processing context if @ttp:profile is not specified.

My point is that we cannot compel the document processing context to communicate anything. It's simply out of scope of this spec.

Ok. What about _If the ttp:profile attribute is not set as recommended above, the [[ttml-imsc1.0.1]] profile to which the Document Instance conforms is communicated through means outside the scope of this specification, e.g. through the document processing context.

nigelmegitt · 2017-11-06T23:17:32Z

-          <a>Image Profile</a> and <a>Text Profile</a> in a given <a>Document Instance</a>.
+          <li>the <code>ebuttm:conformsToStandard</code> element, as specified in [[!EBU-TT-D]] and illustrated in <a href=
+          "#ebu-tt-d-interop"></a>, SHOULD include a single [[ttml-imsc1.0.1]] profile designator corresponding to the profile to
+          which the <a>Document Instance</a> conforms;


This is confusing, isn't the profile to which the document instance conforms the IMSC 1 Text profile by definition?

Using the word "single" is possibly ambiguous since it could be interpreted as "one designator in a conformsToStandard element" or "one conformsToStandard element".

Suggest rewording to "SHOULD include the [[ttml-imsc1.0.1]] text profile designator".

This is confusing, isn't the profile to which the document instance conforms the IMSC 1 Text profile by definition?

Not in the degenerate case of an empty document.

Not in the degenerate case of an empty document.

But this is in the section about EBU-TT-D compatibility, so even in the degenerate case it must be a text profile document.

An empty document can conform to Image Profile and EBU-TT-D simultaneously... as I recall this is what someone argued -- see IMSC 1.0.1 text.

nigelmegitt · 2017-11-06T23:20:31Z

+
+      <section class='appendix'>
+        <h4>Profile signaling</h4>
+


"hereing" seems to be a typo, but I'm not sure what was meant? If it's "herein" then also add "the" before "profiles" so it becomes:

adds support for signalling of the profiles specified herein.

skynavga · 2017-11-08T06:10:00Z

To avoid creating new terminology that may confuse people, I suggest keeping with the terms used in TTML2, namely - document interchange context - document processing context The first of these refers to metadata and parameters that may be interchanged in the envelope of an entity whose body is a TTML document; the second of these refers to the decoding (or encoding) processors. IIRC, the language below "communicated through means outside the scope of this specification, e.g. through the document processing context" should be using the phrase "document interchange context" and not "document processing context" or "external processing context". The following term is not used by TTML: - external processing context

…

On Tue, Nov 7, 2017 at 10:43 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In imsc1/spec/ttml-ww-profiles.html <#267 (comment)>: > </ul> + + <p class="note">If the <code>ttp:profile</code> is not set as recommended above, then conformance with the + [[ttml-imsc1.0.1]] profile is communicated using the <a>external processing context</a>.</p> Ok. What about _If the ttp:profile attribute is not set as recommended above, the [[ttml-imsc1.0.1]] profile to which the Document Instance conforms is communicated through means outside the scope of this specification, e.g. through the document processing context. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#267 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb-y9TfTWlMEG2uCksYVbu7Vc7GXHks5s0T9ugaJpZM4QBsRz> .

nigelmegitt

Looks like we need to use a different term than "override content profile" since I can't see it defined in TTML2. Or define it in TTML2.

Plus I'm already bored of the distinction between document interchange context and document processing context, and think we just need a pointer to "a profile defined outside the document instance", since the distinction adds no obvious value - that's a TTML2 issue to be raised though.

nigelmegitt · 2017-11-08T06:28:42Z


    <p><dfn>Linear White-Space</dfn>. See Section 2.3 at [[!TTML2]].</p>

+    <p><dfn>Override Content Profile</dfn>. As defined in [[!TTML2]].</p>


"Override Content Profile" is not defined in TTML2.

It is defined in https://github.com/w3c/ttml2/pull/468/files

Ah, thank you for the reminder.

nigelmegitt · 2017-11-08T06:32:27Z

-          signals a track that consists of [[ttml-imsc1.0.1]] Text Profile documents.
+          The use of the <code>mimeType="application/mp4"</code> and <code>codecs="stpp.ttml.im1t"</code> attributes in a
+          [[MPEGDASH]] Manifest signals a track that consists of [[ttml-imsc1.0.1]] Text Profile documents. In this case the
+          Manifest is part of the <a>document processing context</a>, and the <a>override content profile</a> is extracted from the


Hmm, maybe it is actually the document interchange context. I'm not really sure how useful the distinction is even in TTML2. Either way it's some processor profile determined from a scope external to the document instance. It feels like even arguing this point is splitting hairs, which makes me question the value of the distinction.

nigelmegitt · 2017-11-08T06:33:04Z

+          The use of the <code>mimeType="application/mp4"</code> and <code>codecs="stpp.ttml.im1t"</code> attributes in a
+          [[MPEGDASH]] Manifest signals a track that consists of [[ttml-imsc1.0.1]] Text Profile documents. In this case the
+          Manifest is part of the <a>document processing context</a>, and the <a>override content profile</a> is extracted from the
+          <code>codecs</code> attribute using the [[ttml-profile-registry]].


s/attribute using/attribute and dereferenced via

nigelmegitt · 2017-11-08T06:33:58Z

-      <p>If the resolved profile is a profile supported by the <a>Processor</a>, then the <a>Processor</a> SHOULD process the
-      <a>Document Instance</a> according to the resolved profile. If the resolved profile is neither <a>Text Profile</a> nor
-      <a>Image Profile</a>, processing is outside the scope of this specification.</p>
+          <li><code>urn:ebu:tt:distribution:2014-01</code>, as specified in [[EBU-TT-D]]</li>


nigelmegitt · 2017-11-08T06:35:55Z


-        <p class="note">If the <code>ttp:profile</code> is not set as recommended above, then conformance with the
-        [[ttml-imsc1.0.1]] profile is communicated using the <a>external processing context</a>.</p>
+        <p class="note">If the <code>ttp:profile</code> attribute is not set as recommended above, the [[ttml-imsc1.0.1]] profile


do we need to say "the IMSC1.0.1 content profile"?

nigelmegitt

One tiny nit-pick - will fix myself.

nigelmegitt · 2017-11-14T17:03:59Z

-        <code>ttp:contentProfiles</code> attribute SHALL be present on the <code>tt</code> element and include the designator of
-        the profile (either the <a>Text Profile</a> or <a>Image Profile</a>) to which the <a>Document Instance</a> conforms.</p>
+        <p>Unless one of the scenarios specified in Sections <a href="#imsc1-compat"></a>, <a href="#ebu-tt-d-compat"></a> or
+        <a href="#sdp-us-compat"></a> apply:</p>


Real nit-pick: should be "applies" since this is talking about one of the scenarios applying.

Profile resolution now based on TTML2 profile semantics (#3)

dda2f98

Clarified profile signaling requirements

palemieux added the pr open label Oct 21, 2017

palemieux mentioned this pull request Oct 21, 2017

IMSCvNext profile signaling and version #261

Closed

palemieux self-assigned this Oct 21, 2017

palemieux added this to the imsc1.1 WD2 milestone Oct 21, 2017

palemieux added the imsc1.1 label Oct 22, 2017

nigelmegitt requested changes Nov 6, 2017

View reviewed changes

Addressing review comments

d64eaff

nigelmegitt requested changes Nov 8, 2017

View reviewed changes

palemieux added 3 commits November 7, 2017 22:46

Further review comments

5930eef

Rationalized document/interchange processing context

6e71e89

Clarified mutually exclusive profile signaling

0dda444

This was referenced Nov 9, 2017

I would like to see a requirement to identify an IMSCvNext document as such w3c/imsc-vnext-reqs#5

Closed

Require profile signaling w3c/imsc-vnext-reqs#10

Merged

palemieux added 2 commits November 9, 2017 08:40

Accommodate optional EBU-TT-D profile signaling

542859a

Address feedback from 20171109

8c1a1ea

nigelmegitt requested changes Nov 14, 2017

View reviewed changes

Fix grammatical nit

c91ee18

nigelmegitt approved these changes Nov 14, 2017

View reviewed changes

palemieux merged commit 3c2d4ae into IMSC1.1 Nov 14, 2017

palemieux deleted the profile-signaling-and-resolution branch November 15, 2017 18:00


		<p><dfn>Extension</dfn>. See Section 2.2 at [[!TTML2]].</p>

		<p><dfn>External Processing Context</dfn>. As defined in [[!TTML2]].</p>


		<p>The Profile Semantics specified in [[!TTML2]] apply.</p>

		<p>The following processor profiles are subsets of the <a>Text Profile</a> processor profile:</p>


		<p><dfn>Linear White-Space</dfn>. See Section 2.3 at [[!TTML2]].</p>

		<p><dfn>Override Content Profile</dfn>. As defined in [[!TTML2]].</p>

Conversation

palemieux commented Oct 21, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nigelmegitt commented Oct 23, 2017

Uh oh!

nigelmegitt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skynavga commented Nov 8, 2017 via email

Uh oh!

nigelmegitt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nigelmegitt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

palemieux commented Oct 21, 2017 •

edited

Loading