W3C home > Mailing lists > Public > public-tt@w3.org > June 2017

{minutes} TTWG Meeting 2017-06-08

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 8 Jun 2017 16:22:51 +0000
To: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D55F37D7.419B5%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/06/08-tt-minutes.html

Please note that we made a Decision to approve the proposed IMSC 1.0.1 CR exit criteria prior to publishing the CR. This falls within our Decision Policy however we have outstanding issues to dispose so we have not made a decision to publish CR yet. Nevertheless the next 10 working days would be the appropriate time to raise any issues with those CR exit criteria!


In text format:


   [1]W3C

      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

08 Jun 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/06/08-tt-irc

Attendees

   Present
          Nigel, Andreas, Mike, Thierry, Pierre

   Regrets
          Glenn

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This Meeting
         2. [5]TPAC 2017
         3. [6]IMSC
         4. [7]TTML
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This Meeting

   Nigel: For today I think the main topics are IMSC, and moving
   IMSC1.0.1 to CR, and TTML2
   ... is there anything else?

   Thierry: TPAC

TPAC 2017

   Nigel: The draft schedule has us meeting on Thursday and
   Friday, with Web and TV IG
   ... on Monday, and CSSWG on Monday and Tuesday, with a
   suggestion that we invite
   ... CSSWG for a joint meeting during our meeting at some time.

   Thierry: Will the CSS WG be around on Thursday and Friday?

   Nigel: We can ask!

   <scribe> ACTION: nigel Invite CSSWG to joint meeting at TPAC
   2017, with list of topics. [recorded in
   [10]http://www.w3.org/2017/06/08-tt-minutes.html#action01]

     [10] http://www.w3.org/2017/06/08-tt-minutes.html#action01

   <trackbot> Created ACTION-497 - Invite csswg to joint meeting
   at tpac 2017, with list of topics. [on Nigel Megitt - due
   2017-06-15].

   Nigel: I'd like to get a draft list of CSS features that we
   would need for subtitle and caption
   ... presentation, arising from our work on TTML generally.

   Pierre: For IMSC1 the obvious ones are multiRowAlign and
   linePadding.

   Andreas: What about line gap?

   Pierre: Yes and that too now.

   Nigel: I suspect Glenn and/or Dae will be able to list some
   Ruby features too.
   ... It would be good to have CSSWG issues open for those too.

   Pierre: Look at #218 on imsc, which indirectly indicates where
   there is (not) CSS support.
   ... For example rubyReserve and rubyOverhang are not supported
   in CSS. I think Dae did
   ... an initial pass at doing that so it probably makes sense to
   start from there.

   Nigel: Thank you I will do that.

IMSC

   Nigel: What are our next steps to move to CR?
   ... Thierry, you collated some wide review feedback this week?

   Thierry: Yes, since yesterday I need to do more updates because
   Pierre has been answering
   ... more comments so I will continue to update that wiki page.

   Pierre: My suggestion is to run down the list of issues.

   [11]IMSC 1.0.1 Wide Review Comments collated Wiki page

     [11] https://www.w3.org/wiki/IMSC1.0.1_Comments_tracker

   [12]Add diff from IMSC 1.0.0 and update
   substantive-changes-summary.txt #244

     [12] https://github.com/w3c/imsc/issues/244

   Pierre: This is trivial, there's not much to be said here.
   ... I'll take care of that at the last minute like last time.
   ... The next is:

   [13]Recommended character sets considered harmful #243

     [13] https://github.com/w3c/imsc/issues/243

   Pierre: I have both a question of substance and of process.
   This question came out of the
   ... i18n and we were not involved in the discussion being
   filed. Part of the issue is there's
   ... been a misread of the specification, folk reading more into
   non-normative text compared
   ... to normative text. My take is that this is a
   misunderstanding, and I'm trying to find the
   ... best way to resolve the misunderstanding.
   ... There are two other i18n issues, which fall into a similar
   category. How do we resolve those?

   Nigel: Were they all filed by Addison?

   Pierre: One was, the others by Richard.

   Nigel: I'll invite Richard and Addison to attend this meeting
   next week so we can talk through
   ... the issues and check we understand properly what their
   thinking is.

   Mike: We could raise pull requests to clarify the language.

   Nigel: I agree, that was my thinking, but I'm worried that we
   might not address whatever
   ... caused the misunderstanding, if we don't discuss it and
   find out by conversation.
   ... I think it will be most effective if we find a way to
   discuss this first.

   <scribe> ACTION: nigel Invite i18n to discuss IMSC 1.0.1 issues
   [recorded in
   [14]http://www.w3.org/2017/06/08-tt-minutes.html#action02]

     [14] http://www.w3.org/2017/06/08-tt-minutes.html#action02

   <trackbot> Created ACTION-498 - Invite i18n to discuss imsc
   1.0.1 issues [on Nigel Megitt - due 2017-06-15].

   Pierre: In #243 I don't know what clarification can be made.

   [15]Requirement to support certain Code Point #241

     [15] https://github.com/w3c/imsc/issues/241

   Pierre: My conclusion is we can improve the text to refactor
   the recommendation to use
   ... certain metrics with the recommendations for certain
   character sets. I don't disagree that
   ... the current text is not the most straightforward. I'm
   reluctant to do this in IMSC 1.0.1, so
   ... since it is not exactly a blocker I would prefer to defer
   it to IMSC2.

   Andreas: The text is there and I think it is correct but could
   be read differently so there is
   ... maybe no strict requirement to update it, though it could
   help to do so. What would be
   ... helpful is if the reader is clear that the code points
   listed are not ones for which support
   ... is mandatory, so it is just about the metrics. From the
   text you could read that if you have
   ... this code point and render it then you should produce a
   glyph sequence which is identical
   ... to the reference fonts. Maybe the edge case is that if
   someone has no glyph in the font
   ... for the code point then he may nevertheless render it with
   a substitute glyph. So if the
   ... condition is there (because the glyph is being rendered)
   then the glyph sequence
   ... rendering must be identical to the reference font, which is
   circular because it implies
   ... that the code point must be supported.

   Pierre: There are two conditions - 7.3 Reference fonts only is
   supposed to apply when the
   ... glyphs are supported.

   Nigel: I never understood it that way.

   Pierre: The reference font section 7.2 says which code points
   should be supported. Then
   ... 7.3 says "if you're going to support a code point for a
   reference font AND it is in the list
   ... in Annex A" then you must end up with the same result, but
   it does not compel support
   ... for all the code points.

   Andreas: Would it be possible to add explicitly a condition
   that it only applies when all
   ... the code points are supported by the font used to meet the
   reference font requirements?

   Nigel: +1

   Pierre: I don't think that would be controversial - it is the
   intent already. I would be happy
   ... to clarify that.
   ... [adds a note to the issue] I will generate a pull request
   that clarifies this.

   [16]Clarify "All regions shall not extend beyond the root
   container" #239

     [16] https://github.com/w3c/imsc/issues/239

   Pierre: There's a pull request open for that.

   Nigel: I just added an approval for that (it was wording
   suggested by me).

   [17]Why exclude hebrew and arabic proportional reference fonts?
   #237

     [17] https://github.com/w3c/imsc/issues/237

   Pierre: This is an i18n comment. I think we ended up rewording
   one of the sentences and
   ... Nigel you suggested a tweak, so I'm tempted to generate a
   pull request to use as input
   ... to our discussion.

   Nigel: Makes sense.

   Pierre: I will generate a pull request [adds note].

   [18]Should the character sets be minimum *font* requirements?
   #236

     [18] https://github.com/w3c/imsc/issues/236

   Pierre: The recommended character sets is worded as an
   authorial requirement rather than
   ... a processor requirement. This occupied a lot of discussion
   for IMSC 1 so I'm reluctant in
   ... IMSC 1.0.1 to change it into a processor requirement.
   ... I propose a "won't fix" for IMSC 1.0.1 and add it to the
   list of things to discuss with i18n.

   Nigel: Ok.

   [19]imsc1-all.xsd has a bad pointer for SMPTE-TT schemas #235

     [19] https://github.com/w3c/imsc/issues/235

   Mike: The current IMSC 1 uses the SMPTE 2010 namespace and I'm
   on a mission to develop
   ... some tight schemas for IMSC 1. When I started digging into
   this I discovered that the
   ... backgroundImage wasn't documented until the 2013 namespace,
   so if you were to try
   ... to write a comprehensive schema you would get stuck there.
   It is trivial of course, as per
   ... the email I sent. The question is how to go about
   addressing this. We could write to
   ... SMPTE and note that 2010 is missing backgroundImage, but
   the answer would probably
   ... be to use 2013. Or we could write it ourselves but it would
   be a little weird to write
   ... something in the SMPTE namespace.
   ... It would be disruptive to switch to the 2013 namespace
   because it is incompatible
   ... with the 2010 namespace.

   Pierre: To Mike's suggestion, we or SMPTE could conceivably
   create a 2010 schema.

   Mike: All we need is one attribute of type xs:anyURI.

   Pierre: We either create that one definition and move on, or
   get SMPTE to write it so that
   ... they have control of it.

   Mike: There's maybe a hybrid where we ask SMPTE to do it but
   offer to do the work.

   Pierre: Or we could create it, send it to SMPTE and ask them to
   publish it.

   Nigel: This is informative only. [traces through the SMPTE
   references]

   Mike: There's an example in ST2052-1-2010 where
   smpte:backgroundImage has a URI

   Nigel: I see there's a substantive issue here in that the
   normative specification isn't completely
   ... clear that backgroundImage takes a URI, though it can be
   inferred. Possibly we need to
   ... add a clarification to IMSC1.0.1. On the schema, which is
   informative I'm not so bothered.

   Mike: That's why 2013 was done! I think it would be good to
   clarify in IMSC 1 and offer a
   ... proposed update to the 2010 schema to include it. While
   we're writing to SMPTE we can
   ... also ask to verify that it is supposed to be an xs:anyURI.
   ... I'll draft the liaison to SMPTE, and we ought not to touch
   IMSC1 until we get an
   ... answer back and then there will probably be a follow-up
   action to modify the spec.

   Nigel: [adds note to issue]

   Mike: Aside from this issue, the question I have for this group
   is, if I write all these schemas
   ... and post them as a contribution, how do we attach them to
   IMSC1?

   Nigel: We can just add it to the linked documents we publish.
   Another alternative is we
   ... could create a new repository just for the schemas and link
   to that. It is much easier for
   ... people to use that way too.

   Mike: Sounds good to me.

   Pierre: +1

   Mike: Then it provides a good way to update it in case any
   changes are proposed later.

   Nigel: Agreed.
   ... Should we add a new repo?

   Pierre: The schemas are already in the spec repo. We could keep
   it there as a directory
   ... and when it feels right to create a repo, do that. We can
   do everything we want on a
   ... separate branch on the IMSC repo and when we're ready
   create a separate repo.

   Mike: I like the first part, maybe we don't need to create a
   new repo.

   Nigel: Okay, works for me.

   [20]Recommend avoiding tab characters #232

     [20] https://github.com/w3c/imsc/issues/232

   Pierre: There's a pull request:

   -> [21]https://github.com/w3c/imsc/pull/242 Discourage the use
   of tab characters in <p> and <span> #242

     [21] https://github.com/w3c/imsc/pull/242

   Pierre: As you point out Nigel, it seems valuable to explain
   this unusual exception. I also
   ... do not like informative text. Glenn seems to oppose it.

   Nigel: Glenn says a note would be acceptable but bad practice.

   Pierre: I'm happy to not have it, put it in the text or put it
   in a Note.

   Nigel: I prefer to put it in a Note.

   Pierre: The text will say "should not use the TAB character"
   and the note will say that no
   ... presentation semantics are specified for the code point.

   NIgel: +1

   Pierre: [adds note to pull request]

   [22]Determination of the color in leading in tts:fillLineGap
   #228

     [22] https://github.com/w3c/imsc/issues/228

   Pierre: I left the ticket open because we need disposition
   comment from the commenter,
   ... but we have a conclusion in the group.

   Nigel: Where did this come from originally?

   Pierre: From the ARIB liaison.

   Nigel: I believe that we only need to send a message back to
   the commenter explaining
   ... the disposition, and offering a last opportunity to
   comment.

   Mike: We can send a link to the ED to make it easier, and to
   the issue.

   Nigel: Yes.

   Thierry: We don't need to publish a new WD say.

   Nigel: We have so few comments here I don't think we need a
   tool.

   Thierry: Yes, I think manually will be good enough. We can use
   GitHub also, if the commenter
   ... adds a note.

   Nigel: That's good for i18n say but not for ARIB.

   Thierry: So for ARIB we will send an email.

   [23]ittp:activeArea clarification #227

     [23] https://github.com/w3c/imsc/issues/227

   Pierre: this is in the same category as the previous one - we
   have agreement here, and need
   ... to confirm the disposition.

   [24]Create tests for CR exit criteria #226

     [24] https://github.com/w3c/imsc/issues/226

   Pierre: I created the tests, so I think we can close this.

   Nigel: Can we review what the exit criteria actually are?
   They're the same as we used for
   ... IMSC1, right?

   <pal>
   [25]https://github.com/w3c/imsc/blob/4f199de739945656838423d18f
   f8df6235be4277/imsc1/spec/ttml-ww-profiles.html

     [25] https://github.com/w3c/imsc/blob/4f199de739945656838423d18ff8df6235be4277/imsc1/spec/ttml-ww-profiles.html

   Pierre: This has actually been merged into the ED.

   <pal>
   [26]http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html

     [26] http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html

   Pierre: It is the same as we used in IMSC1 but only applying to
   new features.

   Thierry: Looks good to me.

   Nigel: The implementation report is a wiki page.

   Pierre: Like for IMSC1.

   Nigel: The Exit Criteria Test Suite is a 404.

   Pierre: Yes that is because github.io won't let you browse
   directories - it needs to point to

   <pal>
   [27]https://github.com/w3c/imsc/tree/4f199de739945656838423d18f
   f8df6235be4277/imsc1/spec/exit-criteria-tests

     [27] https://github.com/w3c/imsc/tree/4f199de739945656838423d18ff8df6235be4277/imsc1/spec/exit-criteria-tests

   <pal>
   [28]https://github.com/w3c/imsc/tree/master/imsc1/spec/exit-cri
   teria-tests

     [28] https://github.com/w3c/imsc/tree/master/imsc1/spec/exit-criteria-tests

   Pierre: That directory has TTML files and PNGs.

   Nigel: And the examples match what is in the spec for
   fillLineGap.

   Thierry: And there are just two.

   Pierre: I think that is sufficient for this particular case.

   Thierry: Yes.

   Pierre: Especially since the fillLineGap test is pretty gnarly.

   Nigel: Agreed.
   ... Any other comments?

   group: [silence]

   Nigel: Okay that's a decision to accept those proposed CR exit
   criteria and test suite.

   Thierry: If we need more tests we can add them later.

   Pierre: [closes issue]

   [29]Attribute syntax definition: missing spaces #221

     [29] https://github.com/w3c/imsc/issues/221

   Pierre: This is contingent on whether or not spaces are allowed
   alongside delimiters in
   ... tts:fontFamily. I think we are getting close to a
   resolution, so when we get there I will
   ... generate a pull request for IMSC1.
   ... I have not seen any comments back on the reflector about
   this issue.

   Nigel: Me neither.

   Pierre: And Nigel and Glenn prefer option 2 so I think we will
   go with that.

   Nigel: If we have not had any more comments by this time next
   week shall we just go with
   ... that option?

   Pierre: Yes.

   [30]Copy referenced schema to the schema directory for ease of
   validation #212

     [30] https://github.com/w3c/imsc/issues/212

   Pierre: We are waiting on you for this Nigel. The last I heard
   you were going to give it a try.

   Nigel: When I tried this I got into all sorts of trouble but I
   accept that it *should* work
   ... without copying the referenced schemas in.
   ... [closes issue]

   Andreas: [leaves]

   Pierre: That completes the review of IMSC 1.0.1 issues
   scheduled for CR.

   Nigel: So the next step is to complete the disposition with
   i18n and write to ARIB about
   ... two issues. Thierry please could you find the usual
   boilerplate, and send it to Pierre?

   Thierry: Yes I will do that tomorrow.

   Pierre: I will draft the email.

   Nigel: Thank you both.

TTML

   [31]Appendix R [June 4 ED] is overly constrained and does not
   represent current best practice #384

     [31] https://github.com/w3c/ttml2/issues/384

   Nigel: I'm preparing a pull request for this.
   ... I'm concerned that progressive decoding is not always
   possible.

   Mike: My concern is that all of the text in the appendix should
   be removed, so I'd like to
   ... start there, and then if someone argues the existing text
   is fine then discuss that.

   Nigel: That works for me.
   ... I plan to add a section referencing ISOBMFF and EBU-TT Live
   explaining the temporal
   ... fragmentation approach used there.

   Mike: I would like to take the TTML1 approach out and just
   reference it as an alternative.
   ... Then this appendix is shorter. I know there's a document by
   Cyril about this.

   Nigel: Oh yes that's on github, written by Romain, Cyril and
   me. We could reference that
   ... informatively.

   Mike: I'm concerned about how stable that is though.

   Nigel: Okay I understand, I'll submit a pull request along
   those lines for review.
   ... I'll put a picture in too, because that's always helpful.

   Mike: That sounds fine.
   ... And rather than perpetuate the fragmentation mechanism,
   just point back to TTML1.

   Nigel: Okay I'll make some changes and make that happen.

   [32]Support for conditional styling. #128

     [32] https://github.com/w3c/ttml2/issues/128

   Nigel: I just want to check with you about this even in the
   absence of Glenn.
   ... Is it okay not to be able to conditionally select a region
   for content based on whatever
   ... input parameters are available? I think it might be because
   the properties of the selected
   ... region can be conditionally set without having to choose a
   whole different version.
   ... Otherwise we might end up needing to change the region
   attribute to IDREFS.

   Pierre: I need to see use cases for this otherwise I don't know
   how to evaluate it.

   Nigel: Makes sense to me. The way I'm thinking right now is
   that using condition to support
   ... media queries (screen size) and user preferences (e.g. text
   size) would be helpful, even
   ... in IMSC2 perhaps. But I'm not settled on a firm viewpoint
   on that just yet.

   Mike: I second Pierre's concern here that we need to understand
   the requirements.

   Nigel: Okay I agree that we need to address practical
   considerations primarily, and I haven't
   ... any evidence so far to say that we should make any more
   changes relative to what is
   ... present currently.
   ... So I will not open a new issue on this right now.
   ... On the issue of foreign namespace elements and where they
   can go, we discussed
   ... it in the context of IMSC 1 and TTML1 but there's no issue
   for it in TTML2 as far as I can
   ... see. Maybe one is needed.
   ... I'm hesitant to raise an issue without checking that there
   actually is one, in case
   ... changes have already been made to TTML2.

   Mike: I can do that right now.

   Nigel: Thank you.
   ... I think we've run out of agenda, a little ahead of time, so
   I'll close for today.
   ... Thank you all! [adjourns meeting]

   /

Summary of Action Items

   [NEW] ACTION: nigel Invite CSSWG to joint meeting at TPAC 2017,
   with list of topics. [recorded in
   [33]http://www.w3.org/2017/06/08-tt-minutes.html#action01]
   [NEW] ACTION: nigel Invite i18n to discuss IMSC 1.0.1 issues
   [recorded in
   [34]http://www.w3.org/2017/06/08-tt-minutes.html#action02]

     [33] http://www.w3.org/2017/06/08-tt-minutes.html#action01
     [34] http://www.w3.org/2017/06/08-tt-minutes.html#action02

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [35]scribe.perl version
    1.152 ([36]CVS log)
    $Date: 2017/06/08 16:20:00 $

     [35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [36] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 8 June 2017 16:23:25 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:40 UTC