Re: {minutes} TTWG Meeting 2015-12-17

On Thu, Dec 17, 2015 at 9:33 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> Thanks all for attending this the last TTWG meeting of 2015, and to
> everyone for your contributions over the year. Minutes of today's meeting
> can be found in HTML format at
> http://www.w3.org/2015/12/17-tt-minutes.html
>
> We agreed to request transition of IMSC to CR3 while leaving issue 111
> (amongst others) open.
>
> In text format:
>
>    [1]W3C
>
>       [1] http://www.w3.org/
>
>                 Timed Text Working Group Teleconference
>
> 17 Dec 2015
>
>    See also: [2]IRC log
>
>       [2] http://www.w3.org/2015/12/17-tt-irc
>
> Attendees
>
>    Present
>           nigel, andreas, pierre, tmichel, plh, dronca
>
>    Regrets
>    Chair
>           nigel
>
>    Scribe
>           nigel
>
> Contents
>
>      * [3]Topics
>          1. [4]This Meeting
>          2. [5]Action Items
>          3. [6]TTML and WebVTT Mapping Document
>          4. [7]IMSC Substantive Changes
>          5. [8]IMSC Pull Requests
>      * [9]Summary of Action Items
>      * [10]Summary of Resolutions
>      __________________________________________________________
>
>    <scribe> scribe: nigel
>
> This Meeting
>
>    nigel: I think for today we have IMSC substantive changes to
>    review.
>
>    pal: Yes, I've updated the summary of substantive changes on
>    the repo.
>
>    atai2: I want to give some info on the mapping document too.
>
>    nigel: Ok!
>
>    pal: Let's start with that then.
>
>    nigel: I think we can close off the 2015 process issue too.
>    ... We also have the IMSC implementation report, and proposed
>    new tests
>    ... AOB?
>
>    pal: I'd like to go over a bunch of pull requests and see if we
>    can accept them - they're minor but they've only been out for a
>    week.
>
> Action Items
>
>    nigel: There's only one to cover that I'm aware of
>
>    action-451?
>
>    <trackbot> action-451 -- Thierry Michel to Investigate if we
>    are required to move to the 2015 process -- due 2015-12-03 --
>    PENDINGREVIEW
>
>    <trackbot>
>    [11]http://www.w3.org/AudioVideo/TT/tracker/actions/451
>
>      [11] http://www.w3.org/AudioVideo/TT/tracker/actions/451
>
>    nigel: I sent the call for consensus out on Friday 4th December
>    so the 2 week period for review ends tomorrow. So far there
>    have been no objections or negative comments of any kind.
>
> TTML and WebVTT Mapping Document
>
>    atai2: I think there are minor edits and pull requests to
>    correct some errors.
>    ... We don't need to discuss them now.
>    ... I had a call last week with Loretta to discuss how to
>    proceed. I also talked to Simon about it in Sapporo. There was
>    at least one
>    ... problem at that time - we did the mapping according to the
>    specs, but of course in real operation there is no complete
>    implementation
>    ... and there are interoperability issues where different
>    browsers implement different features, so those features aren't
>    safe to use.
>    ... The other thing is that there are substantive changes that
>    Simon has made to the WebVTT spec.
>    ... On the first point we did not come to a conclusion. One
>    approach is to check what is really supported and indicate in
>    the spec
>    ... what mapping is desirable vs what might be practically
>    needed to make it work. Loretta made the point that we should
>    base the mapping
>    ... on the specs not the implementations. Overall what we
>    agreed is to try to fix errors, and make some examples, and
>    start from there.
>    ... That's the most obvious and fruitful work for the mapping
>    document, then we have to see how WebVTT goes towards Rec to
>    know what
>    ... features we can really count on.
>
>    ack
>
>    <Zakim> plehegar__, you wanted to discuss a side comment
>
>    plehegar__: I've missed out on what Loretta's github user is,
>    so I can add her to the repo.
>
>    atai2: It should be there.
>
>    nigel: That seems like a good way forward, and good to know
>    you're working on it with Loretta.
>
>    <inserted> plh and atai liaise re getting Loretta added to the
>    github repo for the mapping document
>
> IMSC Substantive Changes
>
>    <pal>
>    [12]https://github.com/w3c/imsc/blob/master/spec/substantive-ch
>    anges-summary.txt
>
>      [12] https://github.com/w3c/imsc/blob/master/spec/substantive-changes-summary.txt
>
>    pal: Nigel and I have gone through the changes and categorised
>    them. There are some substantive changes.
>
>    nigel: So those are the substantive changes, and also there are
>    a bunch that are not substantive.
>
>    pal: That's correct.
>
>    nigel: Do we have a Director's call booked to go through the
>    substantive changes, as needed to transition from CR to CR?
>
>    plh: We will care about what wide review there was on those
>    changes. The Director needs to be reassured that either the
>    changes do not
>    ... affect the wide review or have been reviewed. If it's
>    straightforward then I can sit down with Ralph and go through
>    them.
>
>    nigel: We have not sought wide review on any of the changes -
>    they have all come from group member comments. However I would
>    ... say that although they are substantive they are all
>    clarifications that make the spec say what it meant before, or
>    looked like it meant.
>
>    pal: I'd agree with that.
>
>    plh: Tell me more about issue-79
>
>    pal: There are two ways to indicate profile in TTML and it was
>    unclear before. Following discussions we decided to omit the
>    ttp:profile element.
>    ... There is no formal profile document for IMSC 1 and there
>    were identified limitations to the profile element. To make it
>    clear we have now
>    ... prohibited the element and encouraged use of the attribute.
>
>    plh: Can I say that SMPTE and EBU are happy with the change?
>
>    atai2: For example, EBU-TT-D, which is a subset of IMSC, also
>    prohibits the ttp:element and the ttp:attribute. If they were
>    required in the
>    ... document then it would be impossible to make EBU-TT-D a
>    subset of IMSC, so EBU is fine with this.
>
> Our review of the EBU-TT-D specification indicates there is no such
prohibition specified.

>
>    plh: In that case my recommendation is we don't do a Director's
>    call, and I arrange it with the Director. I don't think we can
>    publish
>    ... before the moratorium. Unless you want to be around I can
>    get the approval to publish.
>
>    nigel: Sounds good to me!
>
>    plh: I'm going to request approval tomorrow afternoon, so you
>    can prepare the document for publication.
>
> Keep in mind there is a Formal Objection [1] to a new IMSC CR publication
that has not been resolved.

[1]  https://lists.w3.org/Archives/Public/public-tt/2015Dec/0042.html

>
>    pal: Excellent. Nigel mentioned that there's 1 issue here,
>    which is on the 2015 process adoption. Nigel issued a call for
>    consensus for that
>    ... which ends tomorrow, so by tomorrow afternoon you'll have a
>    clean document.
>
>    plh: In general we allow 7 days between the publication request
>    and the publication. Tomorrow we will get the okay to publish.
>
>    pal: Okay, then the other thing is to go through the open pull
>    requests and since we have a quorum make a decision on them.
>
>    nigel: Just to confirm, we're not changing the CR exit
>    criteria, and the earliest date will be the minimum after
>    publication.
>
>    plh: That's 4 weeks.
>    ... You'll also trigger a 60 day call for exclusion due to the
>    substantive changes.
>
>    nigel: That doesn't need a document change does it?
>
>    plh: Correct, it just happens.
>
> IMSC Pull Requests
>
>    pal: PR #106 changes the old process reference to the new one.
>
>    <pal> [13]https://github.com/w3c/imsc/pull/106
>
>      [13] https://github.com/w3c/imsc/pull/106
>
>    nigel: A tool for IRC to generate github links would be nice!
>
>    plh: We can ask Santa Clause! Actually the gitter tool
>    integrates chat with git nicely.
>
>    nigel: Everyone's happy with that, what's next?
>
>    pal: PR #119
>
>    <pal> [14]https://github.com/w3c/imsc/pull/119
>
>      [14] https://github.com/w3c/imsc/pull/119
>
>    pal: This is for issue 110.
>    ... This reminds the user that only cell units can be used for
>    line padding.
>
>    nigel: That's editorial.
>
>    pal: Yes, and factual.
>
>    atai2: It's a good important note.
>
>    <pal> [15]https://github.com/w3c/imsc/pull/120.
>
>      [15] https://github.com/w3c/imsc/pull/120.
>
>    pal: I'll merge those later. Next is #120
>    ... This one clarifies which of #backgroundColor-inline and
>    -block and -region are permitted in the image profile, since
>    they're used as fallback in SMPTE-TT.
>    ... That change falls in the general category of clarifying
>    feature tables and making everything explicit.
>    ... They were not forbidden before but now it is explicit that
>    they are permitted. (block and region)
>    ... -inline is prohibited because there's no inline content. It
>    was before, but now it's absolutely explicit.
>    ... The next one is on the same lines. #121
>
>    <pal> [16]https://github.com/w3c/imsc/pull/121
>
>      [16] https://github.com/w3c/imsc/pull/121
>
>    pal: span was prohibited in image profile, so nested-span,
>    which was implicitly prohibited is now noted as being
>    prohibited. That's purely editorial.
>
>    <pal> [17]https://github.com/w3c/imsc/pull/122
>
>      [17] https://github.com/w3c/imsc/pull/122
>
>    pal: Next is #122
>    ... This resolves a number of related issues, all to do with
>    TTML1 features being derived from other features - if one is
>    prohibited then the
>    ... parent feature has no single disposition. This pull request
>    clarifies that.
>    ... It does so by pointing the reader to the relevant children
>    features that the reader ought to look at.
>    ... For example #visibility -> (#visibility-region,
>    #visibility-block etc). Some are prohibited, others forbidden.
>    ... This is essentially just an editorial change.
>    ... Next one is more substantive: #123
>
>    <pal> [18]https://github.com/w3c/imsc/pull/123
>
>      [18] https://github.com/w3c/imsc/pull/123
>
>    pal: I've followed up with CFF-TT folks on this. The current
>    text limits the number of presented images per region to 1,
>    which has been clear
>    ... for a long time. However what it did not say is that the
>    number of div elements per presented region ought also to be 1.
>    It would be possible
>    ... to create a document with 2 divs in a presented region,
>    only one being a presented image. One of the div elements would
>    be empty,
>    ... and could have a background colour, but that wasn't
>    intended. Glenn pointed out that you could have 2 divs both
>    with an image, but one
>    ... not presented because it falls outside the region. The
>    proposal here is to clarify the text that there can only be one
>    div element per
>    ... presented region in image profile.
>    ... This clarifies the intent. I don't know why anyone would
>    have created more than 1 div per region, but now they clearly
>    cannot.
>
>    nigel: And it's had review?
>
>    pal: It was not clear in CFF-TT and when I followed up with
>    folks there everyone agreed with this intent and nobody could
>    think of a reason
>    ... to do anything differently.
>
>    nigel: Any more?
>
>    pal: Those are all of them.
>
>    nigel: Okay, so everyone seems to be happy with all of those.
>
>    pal: I'll merge those all and create a CR3 version and send an
>    email to the reflector with the proposed CR3 document.
>
>    nigel: Fantastic, thank you.
>
>    pal: Thank you all - I think the document is a lot clearer.
>
>    nigel: Just looking at the outstanding issues, there are some
>    unresolved ones, one of which is associated with a formal
>    objection
>    ... that, since we have been unable to reach a consensus, I
>    propose we take forward to the Director. This is an objection
>    to transition to a new CR.
>
>    plh: This is a different thing now - we will need a Director's
>    call after all. Is the spec ready for CR3?
>
>    pal: This is issue 111.
>    [19]https://github.com/w3c/imsc/issues/111
>
>      [19] https://github.com/w3c/imsc/issues/111
>
>    <tmichel> objection is:
>
>    <tmichel> Unless and until a fallback profile is mandated
>    normatively in IMSC1, SKYNAV formally objects to any new CR
>    being published.
>
>    pal: There is not even consensus that the issue is a real
>    issue. That's fundamental.
>
> Nonsense. If it weren't a real issue, we certainly wouldn't be making a
formal objection.

>    ... There's also consensus that Glenn's proposed solution does
>    not work.
>
> Nonsense. We have an implementation that works and there is no substantive
argument as to why it would not work.

> And thirdly despite much effort online and offline
>    there has been
>    ... no consensus to a solution to the problem. Fourthly, there
>    are no other strong objections to the current text.
>
> Irrelevant.

>
>    plh: Translating, the group has not yet made a clear decision
>    but believes that this should not prevent update of the
>    specification with the
>    ... issue remaining open within the working group. Is that an
>    appropriate summary?
>
> Not from this member's perspective.

>
>    nigel: Yes, I think that is an appropriate summary.
>
>    plh: At some point the group will have to take a position,
>    whether to accept or reject Glenn's position. I need a decision
>    from the group.
>    ... Either you close the issue or keep it open and decide not
>    make it a blocker to CR.
>
>    nigel: I think it was my proposal at the beginning to do the
>    latter.
>
>    plh: It needs to be a decision not a proposal.
>
>    nigel: Okay, I'm formally proposing to move to CR3 without
>    closing issue 111. Any objections to that?
>
> I object to having called this question without this point being placed
explicitly on the agenda. I would have attended the call and made an
objection if it had been on the agenda.

>
>    tmichel: The only thing I can see here is that we may need a
>    further CR.
>
>    nigel: We're caught here because the process has changed under
>    our feet - we would be auto publishing a WD if we were still in
>    WD.
>
>    plh: You can return to WD - I don't think it would worsen the
>    outlook.
>
>    pal: I think we should record that for issue 111 the group
>    chooses to proceed with the current text with Glenn as the sole
>    objector.
>
>    nigel: So right now we have no objections to my proposal, so
>    I'm going to record it as a decision.
>
> Objection.

>
>    tmichel: I think this is better than going back to WD which
>    would send a wrong signal.
>
>    pal: I think the group has been responsive to every comment and
>    has processed all comments and proposed resolutions sometimes
>    with substantive changes.
>    ... In this case the consensus is there may not be a problem
>    and the solution proposed is not acceptable.
>
>    plh: In order to update CR the process does not require you to
>    address all issues. That would apply to PR though.
>
>    pal: And the resolution can be to dispose of the issue.
>
>    plh: That's correct.
>
>    nigel: For the minutes, we have decided to proceed with the
>    request to transition to CR3 with issue 111 remaining open,
>    despite the formal objection.
>    ... This will be resolved before we move to PR.
>
> Objection.

>
>    plh: Then we may need a Director's call.
>    ... We will need to know more about #111 precisely. I can try
>    to represent it. I recommend that we have a Director's call.
>
> Please ensure I am invited to such a call.

>
>    nigel: Can we schedule that?
>
>    plh: Today, afternoon between 1pm and 4:30pm is open, or
>    tomorrow 3-4pm Eastern. Otherwise next week, could be Monday
>    afternoon.
>
>    nigel: Of those choices I would prefer 3pm tomorrow, being 8pm
>    UTC.
>
>    tmichel: I'll try to be there but not 100%. I don't want to be
>    on the critical path.
>
>    pal: Tomorrow at noon (pacific) is fine for me.
>
>    plh: Alright, so I'll send a confirmation email with call
>    information, after the transition request.
>
>    tmichel: Is there other stuff we need to prepare? We have the
>    list of substantive changes...
>
>    plh: Actually, looking at the list of substantive changes,
>    which should I use, the latest set?
>
>    pal: In the next couple of hours I will prepare a CR3 and point
>    to the specific list of changes that need to be presented.
>
>    plh: I'm only interested in the changes since CR2.
>
>    pal: That's the latest list, but one pull request from this
>    morning will need to be added.
>
>    plh: Fine by me, I'll add that to the issues list and note
>    issue 111.
>    ... We have to talk about it since there is a formal objection.
>    ... I expect this to take 30 minutes at most tomorrow. I assume
>    it will be Ralph Swick who is Director, otherwise I will need
>    to sync with timbl's calendar. Hopefully we can keep it simple.
>    ... Okay, thank you.
>
>    nigel: Thanks everyone, whatever you do over the holiday
>    period, enjoy it! [adjourns meeting]
>
> Summary of Action Items
>
> Summary of Resolutions
>
>    [End of minutes]
>      __________________________________________________________
>
>
>     Minutes formatted by David Booth's [20]scribe.perl version
>     1.144 ([21]CVS log)
>     $Date: 2015/12/17 16:31:14 $
>
>      [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
>      [21] http://dev.w3.org/cvsweb/2002/scribe/
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>