Port IMSC1.0.1 fixes #322

palemieux · 2018-02-05T06:56:23Z

Closes #292
Built at https://rawgit.com/w3c/imsc/issue-292-port-imsc101-issues/imsc1/spec/ttml-ww-profiles.html

…263)

nigelmegitt · 2018-02-05T11:21:27Z

@palemieux I'm assuming from the "[WIP]" label that there's more to do, so will hold off reviewing.

nigelmegitt

Please could you check the merge conflicts were resolved correctly @palemieux ?

nigelmegitt · 2018-02-06T10:49:10Z

imsc1/spec/ttml-ww-profiles.html

@@ -392,7 +394,7 @@ <h4>Override</h4>
    <h2>Supported Features and Extensions</h2>

    <p>See <a href="#conformance"></a> for a definition of <em>permitted</em>, <em>prohibited</em>, <em>optional</em> and
-    <em>permitted-deprecated</em>.</p>
+    <em>permitted-deprecated</em>.</p>&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD


This looks like a leftover from a (possibly unresolved conflict).

Sigh. Leftover from incomplete delete....

nigelmegitt

One "this doesn't do what I expected" editorial point about indentation in the example, and a query about whether profile signalling should still reference 1.0.1 or should be updated as part of the porting to point to 1.1.

nigelmegitt · 2018-02-06T18:09:27Z

imsc1/spec/examples/fillLineGap-example.xml

-            </p>
-        </div>
-    </body>
+  <head>


This doesn't match the editorial tweak made at b70025d which reduced the indentation spacing.

nigelmegitt · 2018-02-06T18:17:11Z

imsc1/spec/ttml-ww-profiles.html

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


Should this be updated for IMSC 1.1 rather than pointing at IMSC1.0.1?

Authors that really want EBU-TT-D compatibility should stick to IMSC1.0.1.

Do we explicitly say that IMSC 1.1 processors must be able to handle imc1.0.1 designated documents? Presumably it would be reasonable to include both the 1.0.1 and the 1.1 designators - are we recommending that is not done?

Presumably it would be reasonable to include both the 1.0.1 and the 1.1 designators - are we recommending that is not done?

The specification neither discourages nor encourages the presence of the 1.1 designator -- certainly it is not prohibited. I was thinking of avoiding mentioning the 1.1 designator to make things simpler for authors, and avoid anyone believing that any 1.1 document is compatible with EBU-TT-D.

I am not going to object also including the 1.1 designator if you feel extremely strongly about it. Let me know.

I just think it seems strange not to mention the 1.1 designator since this is the 1.1 spec, so I would add it, yes. Otherwise it makes it seem like IMSC 1.1 documents should not declare themselves as such, but as 1.0.1 documents. Whereas they can reasonably declare themselves to be both.

nigelmegitt · 2018-02-06T18:17:31Z

imsc1/spec/ttml-ww-profiles.html

-          which the <a>Document Instance</a> conforms;
+          <li>the designator of the [[ttml-imsc1.0.1]] profile to which the <a>Document Instance</a> conforms and the URI
+          <code>urn:ebu:tt:distribution:2014-01</code> SHOULD each be carried in an <code>ebuttm:conformsToStandard</code> element
+          as specified in [[!EBU-TT-D]] and illustrated in <a href="#ebu-tt-d-interop"></a>.
          </li>
        </ul>

        <p class="note">If <code>ebuttm:conformsToStandard</code> elements signal neither [[ttml-imsc1.0.1]] nor [[!EBU-TT-D]]


Likewise, should this be updated to say IMSC 1.1?

Authors that really want EBU-TT-D compatibility should stick to IMSC1.0.1.

Same comment as #322 (comment)

nigelmegitt

Sorry to go round the loop on this again, the section on EBU-TT-D compatibility still reads strangely to me (though better), and has at least one grammatical issue in note text.

nigelmegitt · 2018-02-23T10:26:03Z

imsc1/spec/ttml-ww-profiles.html

@@ -2684,15 +2702,28 @@ <h4>EBU-TT-D Compatibility</h4>



The first paragraph only refers to IMSC 1.0.1; in the context of IMSC 1.1 that looks strange. Since IMSC 1.0.1 already defines this information, we probably should clarify that conformance to 1.0.1 Text profile also implies conformance to IMSC 1.1 Text profile. So suggest rewording to:

<p>If the <a>Document Instance</a> conforms to both [[ttml-imsc1.0.1]] and [[EBU-TT-D]] (and therefore also conforms to the <a>Text Profile</a>), and compatibility with

we probably should clarify that conformance to 1.0.1 Text profile also implies conformance to IMSC 1.1 Text profile.

I think this is already stated many times before.

I'm still not happy here, but I think the change needed is bigger. I'll open a pull request against the branch that this pull request seeks to merge, which is the best way to demonstrate what I think needs to happen.

I've raised a proposal as pull request #337, whose merge target is the source branch of this pull request.

nigelmegitt · 2018-02-23T10:28:53Z

imsc1/spec/ttml-ww-profiles.html

-          "#ebu-tt-d-interop"></a>, SHOULD be set to the [[ttml-imsc1.0.1]] profile designator corresponding to the profile to
-          which the <a>Document Instance</a> conforms;
+          <li>the value of one <code>ebuttm:conformsToStandard</code> element is equal to the designator of the [[ttml-imsc1.0.1]]
+          profile to which the <a>Document Instance</a> conforms;


I cannot recall why we are not more prescriptive here about the IMSC 1.0.1 Text Profile designator, for example by including it directly as the value to use. Any reason why not?

Also why do we leave it open that it could potentially be the Image Profile, when we state in §I.2 that it cannot?

@nigelmegitt As noted in §I.2, there is a corner case where IMSC 1.0.1 Image Profile can conform to EBU-TT-D.

OK, thanks @palemieux

nigelmegitt · 2018-02-23T10:30:08Z

imsc1/spec/ttml-ww-profiles.html

+          </li>
+
+          <li>the value of one <code>ebuttm:conformsToStandard</code> element is equal to the designator of the <a>Text Profile</a>
+          or <a>Image Profile</a> to which the <a>Document Instance</a> conforms; and


According to §I.2 it cannot conform to the Image Profile as well as EBU-TT-D. If this is to allow for the degenerate case of an empty document then I'd prefer to clarify that, for example by changing or <a>Image Profile</a> to:

(or, if applicable e.g. for an empty document, <a>Image Profile</a>)

The solution is to move 7.9.3 into I.2, to avoid repeating provisions and forcing the reader to toggle between two sections. I propose addressing this as part of #331 . This PR has grown past its original scope.

nigelmegitt · 2018-02-23T10:36:12Z

imsc1/spec/ttml-ww-profiles.html

          </li>
+
+          <li>the value of one <code>ebuttm:conformsToStandard</code> element is equal to the URI
+          <code>urn:ebu:tt:distribution:2014-01</code>.</li>


In support of my comment on line 2706, it seems inconsistent to copy the EBU-TT-D URI here but not the IMSC 1.0.1 URIs there.

EBU-TT-D does not specify the urn:ebu:tt:distribution:2014-01 identifier (anymore?)

I believe that is pending publication of EBU-TT-D 1.0.1, which itself depends on the publication of IMSC 1.0.1 as a Rec. The EBU's pattern is to include a month indicator in the URN. I'll see if we can resolve this circularity with EBU so that we can make an update to this before moving to Rec of IMSC 1.0.1.

nigelmegitt · 2018-02-23T10:38:11Z

imsc1/spec/ttml-ww-profiles.html

+        of this section.</p>
+
+        <p class="note">If none of the <code>ebuttm:conformsToStandard</code> elements specified above are present, the <a>Document
+        Instance</a> conforms is communicated through means outside the scope of this specification, e.g. through the <a>document


Grammar point: "the Document Instance conforms is communicated" doesn't make sense - I think this is supposed to be:

the profiles to which the Document Instance conforms are communicated

Clarify fillLineGap semantics when applied to successive p elements (#…

34d3dae

…263)

palemieux closed this Feb 6, 2018

Editorial tweaks (Close #271)

5b65c2a

palemieux reopened this Feb 6, 2018

palemieux and others added 6 commits February 5, 2018 20:31

Clarify forcedDisplay semantics (#284)

24a7e64

Clarify the limits of Active Area per its syntax (#288)

74ee90f

Clarify handling of foreign elements and attributes (#213)

8aa69f6

Clarify name of IMSC namespaces (#301)

89e01a4

Use Root Container Region consistently (#302)

69be5bd

Clarify style resolution procedure (#300)

c1f7e1f

palemieux changed the title ~~Port IMSC1.0.1 fixes [WIP]~~ Port IMSC1.0.1 fixes Feb 6, 2018

palemieux mentioned this pull request Feb 6, 2018

Port issue #263 to IMSC1.1 #324

Closed

nigelmegitt requested changes Feb 6, 2018

View reviewed changes

Address 24a7e64#r166255170

1d5e696

palemieux added the imsc1.1 label Feb 6, 2018

nigelmegitt requested changes Feb 6, 2018

View reviewed changes

Address #322 (comment)

f612e68

palemieux added this to the imsc1.1 CR milestone Feb 9, 2018

palemieux added 2 commits February 9, 2018 16:38

Adds signaling for IMSC1.1 in EBU-TT-D document

e119318

Adds signaling for IMSC1.1 in EBU-TT-D document

6bd17f4

nigelmegitt requested changes Feb 23, 2018

View reviewed changes

palemieux and others added 2 commits February 28, 2018 10:44

Fix typo at #322 (comment)

2fd8910

Clarify EBU-TT-D signaling in the context of IMSC 1.1

3edf84d

nigelmegitt approved these changes Mar 8, 2018

View reviewed changes

palemieux merged commit 3212412 into IMSC1.1 Mar 8, 2018

palemieux deleted the issue-292-port-imsc101-issues branch April 24, 2018 02:29

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Port IMSC1.0.1 fixes #322

Port IMSC1.0.1 fixes #322

palemieux commented Feb 5, 2018 •

edited

Loading

nigelmegitt commented Feb 5, 2018

nigelmegitt left a comment

nigelmegitt Feb 6, 2018

palemieux Feb 6, 2018

nigelmegitt left a comment

nigelmegitt Feb 6, 2018

nigelmegitt Feb 6, 2018

palemieux Feb 6, 2018

nigelmegitt Feb 8, 2018

palemieux Feb 8, 2018

nigelmegitt Feb 9, 2018

nigelmegitt Feb 6, 2018

palemieux Feb 6, 2018

nigelmegitt Feb 8, 2018

nigelmegitt left a comment

nigelmegitt Feb 23, 2018

palemieux Feb 28, 2018

nigelmegitt Mar 1, 2018

nigelmegitt Mar 1, 2018

nigelmegitt Feb 23, 2018

palemieux Feb 28, 2018

nigelmegitt Mar 1, 2018

nigelmegitt Feb 23, 2018

palemieux Feb 28, 2018

nigelmegitt Feb 23, 2018

palemieux Feb 28, 2018

nigelmegitt Mar 1, 2018

nigelmegitt Feb 23, 2018

Port IMSC1.0.1 fixes #322

Port IMSC1.0.1 fixes #322

Conversation

palemieux commented Feb 5, 2018 • edited Loading

nigelmegitt commented Feb 5, 2018

nigelmegitt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nigelmegitt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nigelmegitt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

palemieux commented Feb 5, 2018 •

edited

Loading