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

{minutes} TTWG Meeting 2017-06-15

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 15 Jun 2017 16:09:31 +0000
To: W3C Public TTWG <public-tt@w3.org>
Message-ID: <D5686D4D.42470%nigel.megitt@bbc.co.uk>
Thanks to all for attending today's TTWG meeting. Minutes can be found in HTML format at http://www.w3.org/2017/06/15-tt-minutes.html

In text format:


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

                Timed Text Working Group Teleconference

15 Jun 2017

   See also: [2]IRC log

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


          Nigel, Mike, Pierre, Thierry, Dae

          Andreas, Glenn




     * [3]Topics
         1. [4]This meeting
         2. [5]TPAC 2017
         3. [6]IMSC
         4. [7]TTML
         5. [8]IMSC (revisited)
     * [9]Summary of Action Items
     * [10]Summary of Resolutions

   <scribe> scribe: nigel

This meeting

   Nigel: Today we need to move forward with IMSC and TTML. I will
   briefly mention TPAC. Any specific points to cover, or other

   Mike: The IMSC 1 issue regarding SDP-US

TPAC 2017

   Nigel: I've had confirmation from the newly re-chartered Media
   and Entertainment IG (was Web and TV)
   ... that we can meet them jointly for 30 minutes on the Monday.
   ... I proposed a draft agenda of an update on subtitle and
   caption work including TTML2, IMSC 1.0.1, industry adoption
   ... Seek input on IMSC 2 requirements
   ... Gauge interest in a possible profile of TTML2 for AD
   ... plus any other topics of interest.
   ... I suggested afternoon would be better than morning in case
   there's any last minute preparation to done.


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


     [11] http://www.w3.org/AudioVideo/TT/tracker/actions/497

   Nigel: I haven't progressed this yet.
   ... I will gather together the details as discussed last week
   and hopefully progress that in the next week.
   ... Registration is now open, as are the preferred rates for
   hotels - early booking is recommended.



   <trackbot> action-498 -- Nigel Megitt to Invite i18n to discuss
   imsc 1.0.1 issues -- due 2017-06-15 -- PENDINGREVIEW


     [12] http://www.w3.org/AudioVideo/TT/tracker/actions/498

   Nigel: I did invite Richard and Addison but they have not
   either joined or said they would be (un)able to do so.
   ... However there has been some discussion offline.

   Pierre: I suggested it would be easier to have the discussion
   live but we can go ahead and try to propose a solution and
   ... and deal with the response.
   ... I'm fairly confident that the root of the issues is mainly
   a misunderstanding of the specification.

   Nigel: Some of the github issues have been discussed offline.

   Pierre: By the way I'm not blaming anyone, but conflating
   reference fonts with recommended character sets is a problem.
   ... They are really separate. I hope I clarified some of that.
   Specifically the idea of recommended sets is for author to have
   ... that characters for a particular language will be displayed
   and for implementers to have confidence that they are
   supporting the
   ... correct code points. Separately and independently there are
   a set of reference fonts that are specified, but the choice of
   recommended character
   ... sets was made independently of the reference fonts. And the
   "rendering fidelity" associated with recommended character sets
   is whether they
   ... display at all, period, whereas for reference fonts it is
   about metrics, line breaking positions etc. So I think this is
   where the misunderstanding lies.
   ... So in a pull request I tried to clarify it. At some point
   we have to propose something and let them restart the
   discussion if they feel the issue is not
   ... resolved.

   Mike: I'm sympathetic - this is a complicated topic, but I also
   believe the spec is clear. I think we have done what we can.

   [13]Clarified the requirement for processors to implement
   reference fonts #245

     [13] https://github.com/w3c/imsc/pull/245

   Nigel: This is for #237 and #241.

   Pierre: It has also been discussed in relation to #236.

   Nigel: From the discussion are there more changes you want to
   apply to resolve the misunderstandings?

   Pierre: Maybe less not more!
   ... The note "Since the flow of text..." is the one we maybe
   need to work on.

   Nigel: Did you see my proposed alternate wording?


     [14] https://github.com/w3c/imsc/pull/245/files#r121123051

   Pierre: I'm fine with it - I hope people won't read too much
   into it.
   ... It's not only the flow of text but also the background, the
   effective size of the subtitle.

   Mike: Yes, line height, characters per line.

   Pierre: Gaps between lines.

   Mike: It's sweeping so having the reference font is critical.
   ... From a web browser perspective some of this must seem
   strange, but for this application the web approach doesn't
   really work.
   ... I don't know how you say that in a note!

   Nigel: So "flow of text" is too generic?

   Pierre: Or not broad enough. It is the whole appearance of the
   subtitle - I think that's a true statement. We could try to
   list it all but
   ... evidently it is not obvious.

   Nigel: The other thing we maybe need to clarify is the
   scenarios where reference fonts apply - it maybe does not jump
   ... enough that reference fonts only come into play for a very
   specific subset of computed values of tts:fontFamily.

   Pierre: That's extremely explicit though. Without Richard on
   the call I think we're grasping at straws.
   ... In light of what we just talk about what should we do? Have
   a more generic note about the appearance of the subtitle?

   Nigel: Yes, if you want to try to craft that I'd be happy to
   review it.

   Pierre: I'll do it now and we can review it later.
   ... My recommendation is to apply the pull request and propose
   it as a disposition and get the response.

   Nigel: I think that's fair. Any other views?

   Mike: No.

   [15]Attribute syntax definition: missing spaces #221

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

   Pierre: Option 2 was preferred and there was no reaction
   against it, so I've drafted a pull request on that basis
   assuming that TTML1 will
   ... clarify that spaces are in fact permitted, and rejiggered
   IMSC to take that into account.

   [16]Required spaces between non-terminal components of styling
   and parameter attributes (issue #221) #230

     [16] https://github.com/w3c/imsc/pull/230

   Pierre: This PR puts references into TTML1 for the sections on
   attribute syntax, and IMSC assumes it is permitted and says
   "you should not do that" (in document instances).

   Nigel: I see you've specified no white space between digit
   tokens... That's not to say you can't distinguish numerator
   from denominator!

   Pierre: No just between digits. If you look say at %age in
   TTML1 it is clear that no LWSP is permitted between them.
   ... It is obvious to me, but it was obvious that there would be
   no spaces between fontFamily components, so I'd rather err on
   the side of completeness.

   Nigel: +1
   ... Do you want to merge that then?

   Pierre: Yes

   Nigel: okay, nobody has any objections, go ahead.

   Pierre: Done.

   Nigel: We have one more, which is #242:

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

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

   Pierre: That's one day away from the 14 days and there have
   been no comments.

   Nigel: I've just approved it by review.
   ... When it comes to Dispositions the main one we need to
   address is ARIB since all the other comments are W3 internal.

   [18]IMSC 1.0.1 comments tracker wiki page

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

   Nigel: Thierry the ARIB liaison has listed on that wiki page
   that it is under review and not edited in the spec.

   Thierry: That was the status about a week ago.

   Nigel: I'm puzzled I thought it had been done.

   Pierre: Yes, they are #227 and #228 and they have been merged
   and are ready for review.
   ... The proposed email states that.
   ... You said that you and Thierry would review and send it
   after this meeting.

   Nigel: The last email in the thread is:


     [19] https://lists.w3.org/Archives/Public/public-tt/2017Jun/0066.html

   Nigel: OK I see. Does anyone have any comments or changes on
   the proposed response and dispositions?

   group: [silence]

   Nigel: In that case let us take that as approval!

   Thierry: OK I will send that.

   Nigel: Thank you.

   Thierry: Just one thing - is 1 week response time enough?

   Nigel: I think 1 week is very short.

   Pierre: Do we have to get a response? Or can we proceed with no
   response after some time?

   Thierry: The best is a response, but if not then we can go
   ahead to the Director in any case.

   Pierre: Can we work backwards from when we want to publish the

   Nigel: I don't want to have our TTML2 and IMSC 1.0.1
   publications clash.

   Thierry: Only one is a transition - the other is just another

   Pierre: How about transitioning on July 6? Mid-July would not
   work for me.

   Thierry: We can go straight to PR if we have implementation
   experience already. I've seen that before.

   Nigel: I thought the Process sets a minimum duration for CR?
   But if not, then okay fine.
   ... I believe we have one implementation of fillLineGap
   already, and implementing activeArea is trivial.

   Thierry: I'll check the process.

   Nigel: [also checks] - the 4 week minimum appears to be for
   getting comments on the way into CR not on the way out.
   ... In that case when are other implementations expected?
   ... I'm happy either way - we can go straight to PR otherwise

   Pierre: We can review that on July 6.

   Nigel: July 6 is 3 weeks out, so we could offer 2 weeks.

   Pierre: Then we could plan on transitioning on June 30.

   Nigel: Accepting TTML2 is a WD only, it is much bigger so I
   would rather not schedule 2 document publications on the same
   day - I would rather wait until
   ... July 6 for IMSC.
   ... If we say that then we need a resolution to publish IMSC
   1.0.1 as a CR (or PR) no later than next week's meeting.
   ... That gives us this coming week to mop up any remaining open
   ... Thierry can we say 2 weeks for the disposition response?

   Thierry: Yes

   Pierre: I would say explicitly the date we plan to transition.

   Thierry: We need to have the response before meeting the

   Pierre: Okay then 2 weeks for sure. I would be explicit about
   the planned transition dates too.

   Nigel: I'm happy with the 2 weeks but I don't agree that we
   should include more dates of planned transitions etc - just say
   when we need the response back.

   Pierre: Okay I'm fine with that too.

   [20]SDP-US is listed as a normative reference, but it is not

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

   Mike: This was prompted by a discussion with someone who
   thought that SDP-US is critical to implementation of IMSC1.
   ... implementation of SDP-US is not critical at all, so the
   normative reference is an error.

   Pierre: Does a normative reference imply complete
   implementation of the referenced document or just the relevant

   Mike: The latter.

   Pierre: That's my understanding too. The current text says "if
   the document conforms to SDP-US you shouldn't use ttp:profile".

   Mike: That's poor choice of words and not IMSC1's business.
   ... Conformance with SDP-US is not IMSC1's business. If you
   want an SDP-US document do that. This is just a declarative

   Pierre: So you're arguing that's a statement not a conformance

   Mike: Yes absolutely. If you want to go there (and I don't),
   it's a declarative note only. It is not a conformance term for
   IMSC 1 and has nothing to do with
   ... IMSC 1 conformance.

   Pierre: My thinking is: as currently written it is evidently
   misleading, but not wrong. If we are going to move the
   normative reference to an informative one then
   ... we should change this clause and remove any conformance.

   Mike: I don't think we should wander into conformance here.

   Nigel: There is also Annex I about compatibility with other
   TTML-based specifications.
   ... Effectively the same wording is duplicated there.
   ... And that's a useful service given the design goal to be a

   Pierre: Looking at 6.9 Profile Signaling...
   ... SDP-US prohibits the ttp:profile attribute from being
   ... In order for me to evaluate the clause in 6.9 I need to go
   and read SDP-US.

   Mike: And it shouldn't make me do that.

   Pierre: That's the root cause of this. You're suggesting that
   we should change the wording to be informative and move the
   reference to the non-normative section?

   Mike: Yes, I'd like to refactor this to remove the normative
   ... The ramifications are editorial: the use of SHOULD
   originally was a bad choice.

   Pierre: Section I.3 has the declarative statement.

   Nigel: Just checking all the other references to SDP-US, they
   all seem to be declarative.

   Pierre: We could reword 6.9 to match I.3.

   Mike: Why do we need to repeat it?

   Pierre: Because it is important to clarify the profile
   signalling from TTML1.

   Mike: I'm okay either a) deleting the sentence or b) restating
   it as a declarative statement.
   ... There are a number of ways to remove this from the
   normative references.

   Nigel: I don't have any objection to removing it from normative
   references. By the way it is only a WG Note, so it's a bit odd
   for us to normatively
   ... reference it anyhow, I'm not sure how that slipped by.

   Pierre: It could be just a missing ! - I can prepare a pull

   Mike: I do believe this was just a mistake.

   Pierre: I believe we will have to list this as a substantive
   change even though it has no conformance impact.

   Nigel: I agree.

   Pierre: I will prepare a pull request later today, if you could
   review it and let me know if there are any issues.

   Mike: Thanks guys.

   Pierre: Shall we go back to #245 which I have now updated?

   Nigel: Given the time let's do that offline please.
   ... Summarising for the minutes, we have done what we can on
   the i18n issues, agreed the disposition response and made a
   ... to make the resolution to transition to CR or possibly even
   PR in next week's meeting for a July 6 publication target.


   Nigel: We said we would publish the WD for wide review by June
   30, and that we would need a 2 week review period to approve
   ... We have a number of open pull requests now and no final
   draft of the WD to review.
   ... We also a number of open issues.
   ... I wanted to propose that we merge all the current open pull
   requests and turn that into a draft that the group can
   ... review prior to approving publication for wide review. That
   gives a 2 week review period for everyone. How does that grab

   Mike: Okay for me.

   Nigel: Clearly we can still make further changes prior to CR,
   or resolve issues with this version by pull requests in the
   next few days as long as there is
   ... positive review from enough key people, and no negative

   Dae: I'm more interested in the deadline than having 2 full
   weeks. 1 week review is enough for me.

   Pierre: Movielabs will abstain on this at this time.

   Thierry: The proposal sounds reasonable to me.

   Nigel: OK then I think we're agreed.
   ... I will ask Glenn to progress that.
   ... Let's go through the pull requests then.

   [21]Issue 0384 streaming ttml appendix #389

     [21] https://github.com/w3c/ttml2/pull/389

   [22]HTML version

     [22] https://rawgit.com/w3c/ttml2/04a3ea7dd0b15e9cb6451f4655a7d1aea38d32de/spec/ttml2.html

   Nigel: It's appendix R
   ... I didn't quite do what we said last week in that I didn't
   reference the TTML1 appendix but left it in as a subsection.
   ... I did that on the basis of one of Glenn's comments on the

   Mike: I would rather do what we said last week and diminish the
   relevance of the section that isn't common practice by making
   it a reference back to TTML1.

   Nigel: I have limited time available in the short term to fix
   this so unless there are strong objections to what we have I
   propose to keep it as is,
   ... or otherwise I'd welcome if anyone else wants to implement
   the reference change.

   Mike: I haven't had time to check the detail on the rest of

   Nigel: Unless there are any more issues or pull requests to
   discuss let's return to the IMSC topic.

IMSC (revisited)

   Pierre: On the SDP-US issue the sentence above about EBU-TT-D
   has the same issue. I'm wondering if we should change that too.

   Nigel: That's true.

   Pierre: I'm thinking of dealing with that at the same time.

   Mike: Having parallel language would probably be the best thing
   to do but since EBU-TT-D and SMPTE-TT are essential I'm not
   pushing for that.

   Pierre: I'm asking for permission to make the two bullets
   consistent in language.

   Nigel: I agree - please change "should not be present" to "is
   not present" for EBU-TT-D.

   Mike: I'm happy with that.

   Pierre: Okay I will do that and you'll see the pull request
   later today. Thank you.

   Nigel: We're out of agenda, also time. Thanks everyone.
   [adjourns meeting]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [23]scribe.perl version
    1.152 ([24]CVS log)
    $Date: 2017/06/15 16:08:41 $

     [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [24] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 15 June 2017 16:10:03 UTC

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