SMPTE response as TTML2 review.

[tmichel07]

One Comments sent by alan.lambshead@icloud.com
is now publicly archived at
https://lists.w3.org/Archives/Public/public-tt/2017Oct/0032.html
see attached Pdf file.

For public discussion and processing.

A second private email is archived for your convenience in W3C member restricted space
Please do NOT discuss this email on github, as it is NOT public.
https://lists.w3.org/Archives/Member/member-tt/2017Oct/0001.html

[skynavga]

I don't see a PDF file indicated in https://lists.w3.org/Archives/Public/public-tt/2017Oct/0032.html.

[nigelmegitt]

I don't know why it's not there, perhaps the PDF attachment was forgotten or stripped. In the meantime while we try to sort it out, members can see it at the private address linked above, here.

[tmichel07]

Glenn, You may find the same email with the PDF attachment in the Member-tt archives https://lists.w3.org/Archives/Member/member-tt/2017Oct/0000.html Thierry Le 03/10/2017 à 20:03, Glenn Adams a écrit :

…

I don't see a PDF file indicated in https://lists.w3.org/Archives/Public/public-tt/2017Oct/0032.html. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#453 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGiYfmQIQYLGdM3GWiMFiW9oQyCAscYJks5sonb1gaJpZM4PrzjO>.

[nigelmegitt]

The issue has been resolved thanks to @tmichel07 and the team, and the PDF attachment is now present on the public reflector @skynavga

[nigelmegitt]

I see two substantive points in the PDF:

1. SMPTE also respectfully notes that, in light of mandatory regulatory requirements, it is critical
   that future versions IMSC (and thus TTML2) be designed to minimize changes to existing IMSC1 processors.

We should take this into account when considering how we move IMSC 1.0.1 features into IMSC 1.1 and TTML2.

2. Finally, SMPTE encourages TTWG to create a registry that specifies image/@type and image/@format attribute values for selected image formats. In particular, this mapping should allow a processor to differentiate between HDR and SDR images.

This is a new request I believe, and I'm not certain if we need to do it, or if we can simply reference an existing set of types and formats. I guess the intent here is to limit the number of formats that must be supported.

[palemieux]

This is a new request I believe,

I read it as an encouragement to use tt:image and list potential values for its image/@type and image/@format attributes. This could be done as a separate WG Note, not unlike the TTML profile registry.

[nigelmegitt]

list potential values

This seems like a futile exercise - why would we do that unless we have applied some kind of domain knowledge to filter it to a smaller/easier to implement list?

[palemieux]

why would we do that unless we have applied some kind of domain knowledge to filter it to a smaller/easier to implement list?

I think that is the point actually. For instance, IMSC1 specifies that images conform to PNG.

[skynavga]

I think we should define at least one feature that selects support for some type, probably PNG.

[nigelmegitt]

We could do but it would be hard to extend. The request was for a registry, so perhaps we should create such a registry and delegate definition of profile feature designators for individual formats to that registry.

[nigelmegitt]

This is now dependent on #542 - if we resolve to remove <image-format> then the registry will not be needed.

[css-meeting-bot]

The Working Group just discussed SMPTE response as TTML2 review ttml2#453.

The full IRC log of that discussion

<nigel> Topic: SMPTE response as TTML2 review ttml2#453
<nigel> github: https://github.com//issues/453
<nigel> Cyril: We need to tell authors to use type parameters available in the mime type in preference
<nigel> .. to the format attribute. Then the question is if we should define some tokens, like SDR
<nigel> .. or HDR.
<nigel> Glenn: Yes we should.
<nigel> Chris: I don't think we expect SDR or HDR to be in a MIME type.
<nigel> Cyril: Can we use media queries in format?
<nigel> Nigel: No they should be in the condition attribute. I agree that SDR vs HDR does seem to
<nigel> .. be more of a media query issue though than format.
<nigel> Nigel: Unless we have a concrete use case for removing format - if SDR and HDR are media queries then we have no others.
<nigel> Glenn: It's already interoperably implemented for font format.
<nigel> Cyril: This is about <image-format>
<nigel> David: I think we should remove image-format too - it is underspecified to the point that
<nigel> .. it is not useful. Alternatively tighten it up.
<nigel> Glenn: It would be asymmetrical to leave it on audio, font and data but remove it from image.
<dsinger> we should raise an issue that we should use MIME types for fonts as well https://www.iana.org/assignments/media-types/media-types.xhtml#font
<nigel> Nigel: I have raised #542 for removing `<image-format>`
<nigel> .. And #543 for removing `<font-format>`.

[skynavga]

reopen for WR disposition action

[nigelmegitt]

Disposition sent, archived at https://lists.w3.org/Archives/Member/member-tt/2018Feb/0006.html (members only link).

[nigelmegitt]

No further action on this required.