Re: {minutes} TTWG Meeting 2018-03-29

Excellent. That will make it easy for webvtt to pick it up.

Thanks,
Silvia.

On Tue., 3 Apr. 2018, 6:52 am David Ronca, <dronca@netflix.com> wrote:

> > ... features are natively supported in html/CSS as well?
>
> html/css support is not complete, but fairly close, and the CSS groups has
> indicated a willingness to address the missing features.  We have an
> internal TTML2->CSS implementation that has been well tested and seems to
> cover JA subtitle feature set reasonably well, but not always a clean
> mapping.
>
> On Mon, Apr 2, 2018 at 1:32 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com
> > wrote:
>
>> Hi David,
>>
>> This is amazing! Thanks for sharing that blog post. I've not been able to
>> get this much detailed information on what the requirements are around
>> subtitles in Japanese before. Did you with with the i18n group on making
>> sure all these features are natively supported in html/CSS as well?
>>
>> I think the current webvtt specification supports most of these features,
>> apart from the slanting, but we would need to do a proper assessment and
>> write proper test files.
>>
>> I'll add an issue in GitHub for it - it should be in the list for webvtt
>> v2.
>>
>> Kind regards,
>> Silvia.
>>
>>
>> On Tue., 3 Apr. 2018, 12:05 am David Ronca, <dronca@netflix.com> wrote:
>>
>>>
>>> > defined as "essential Japanese subtitle features"?
>>> We define the essential Japanese features in this techblog
>>> <https://medium.com/netflix-techblog/implementing-japanese-subtitles-on-netflix-c165fbe61989>,
>>> which is based on a presentation and paper that we shared with TTWG.  This
>>> is based on our work to launch in Japan, and a rather large set of JA
>>> subtitle assets.
>>>
>>> On Mon, Apr 2, 2018 at 1:55 AM, Silvia Pfeiffer <
>>> silviapfeiffer1@gmail.com> wrote:
>>>
>>>> Hi David,
>>>>
>>>> What I meant was that Microsoft only supports a minimal feature set
>>>> which is about as much as SRT. There's no official definition of
>>>> "minimal feature set". The other browsers support more with Chrome and
>>>> Mozilla basically everything except for scrolling regions. All Apple
>>>> implementations are close to complete.
>>>>
>>>> About ruby support: it's as good as HTML's ruby support for now.
>>>>
>>>> Counter question: what is defined as "essential Japanese subtitle
>>>> features"?
>>>>
>>>> Cheers,
>>>> Silvia.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Apr 2, 2018 at 4:33 PM, David Ronca <dronca@netflix.com> wrote:
>>>> >> because the browsers don't provide sufficient support (specifically
>>>> >> Microsoft's browsers - the others support the minimal feature set)
>>>> >
>>>> > How to reconcile this with David Singer's statement that "VTT is
>>>> supported
>>>> > in all major browsers"?  Also, the how is "minimal feature set"
>>>> defined.
>>>> > Must be more than SRT, I expect.  I am especially curious about WebVTT
>>>> > support for Japanese subtitles.  We have not seen a WebVTT
>>>> implementation
>>>> > that can properly the essential Japanese subtitle features.  Is there
>>>> such
>>>> > an implementation that someone can point us to?
>>>> >
>>>> > On Thu, Mar 29, 2018 at 7:55 PM, Silvia Pfeiffer <
>>>> silviapfeiffer1@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Congratulations on the resolution for webvtt to move to CR! I'll help
>>>> >> where I can.
>>>> >>
>>>> >> About the question of interest: many video player publishers had to
>>>> write
>>>> >> their own webvtt interpreters & renderers because the browsers don't
>>>> provide
>>>> >> sufficient support (specifically Microsoft's browsers - the others
>>>> support
>>>> >> the minimal feature set). At FOMS we consistently hear the request
>>>> by the
>>>> >> player vendors and content publishers who don't want to have to
>>>> write and
>>>> >> maintain their own captioning library but the state of
>>>> implementation in
>>>> >> browsers is a problem. It's a chicken and egg thing and it's my hope
>>>> that a
>>>> >> push for CR/REC will change that.
>>>> >>
>>>> >> I hope this helps.
>>>> >>
>>>> >> Cheers,
>>>> >> Silvia.
>>>> >>
>>>> >> On Fri., 30 Mar. 2018, 3:25 am Nigel Megitt, <nigel.megitt@bbc.co.uk
>>>> >
>>>> >> wrote:
>>>> >>>
>>>> >>> Thanks all for attending today's TTWG meeting. Minutes can be found
>>>> in
>>>> >>> HTML format at https://www.w3.org/2018/03/29-tt-minutes.html
>>>> >>>
>>>> >>> In text format:
>>>> >>>
>>>> >>>    [1]W3C
>>>> >>>
>>>> >>>       [1] http://www.w3.org/
>>>> >>>
>>>> >>>                 Timed Text Working Group Teleconference
>>>> >>>
>>>> >>> 29 Mar 2018
>>>> >>>
>>>> >>>    See also: [2]IRC log
>>>> >>>
>>>> >>>       [2] https://www.w3.org/2018/03/29-tt-irc
>>>> >>>
>>>> >>> Attendees
>>>> >>>
>>>> >>>    Present
>>>> >>>           Cyril, Pierre, Nigel, dsinger, Thierry, Philippe
>>>> >>>
>>>> >>>    Regrets
>>>> >>>           Andreas
>>>> >>>
>>>> >>>    Chair
>>>> >>>           Nigel
>>>> >>>
>>>> >>>    Scribe
>>>> >>>           nigel
>>>> >>>
>>>> >>> Contents
>>>> >>>
>>>> >>>      * [3]Topics
>>>> >>>          1. [4]This meeting
>>>> >>>          2. [5]F2F meetings
>>>> >>>          3. [6]TTML1 3rd Edition CR
>>>> >>>          4. [7]IMSC
>>>> >>>          5. [8]Update feature list per TTML2 imsc#350
>>>> >>>          6. [9]Clarify the use of recommended character sets
>>>> >>>             imsc#354
>>>> >>>          7. [10]TTWG Charter
>>>> >>>          8. [11]WebVTT
>>>> >>>          9. [12]TTWG Charter
>>>> >>>         10. [13]Travis
>>>> >>>         11. [14]Audio Profile of TTML2
>>>> >>>         12. [15]Meeting Close
>>>> >>>      * [16]Summary of Action Items
>>>> >>>      * [17]Summary of Resolutions
>>>> >>>      __________________________________________________________
>>>> >>>
>>>> >>>    <scribe> scribe: nigel
>>>> >>>
>>>> >>> This meeting
>>>> >>>
>>>> >>>    Nigel: Next week I'm able to make the call, but the week after,
>>>> >>>    the 12th, I can't.
>>>> >>>
>>>> >>>    Cyril: I also can't make the 12th.
>>>> >>>
>>>> >>>    Pierre: Regrets for me for the 19th.
>>>> >>>
>>>> >>>    Nigel: For today, we have TTWG Charter, if there's more to
>>>> >>>    discuss on that - will wait for
>>>> >>>    ... staff to join before confirming.
>>>> >>>    ... We also have TPAC, and a possible F2F in Munich in May,
>>>> >>>    ... TTML1 3rd Edition CR needs to be discussed.
>>>> >>>    ... Not sure if there's anything to discuss on TTML2.
>>>> >>>    ... For IMSC there is one agenda point, a pull request, which
>>>> >>>    we may be able to resolve with
>>>> >>>    ... a brief conversation.
>>>> >>>    ... If we have time we can go through the IMSC vNext Reqs pull
>>>> >>>    requests, which have been
>>>> >>>    ... open for a while.
>>>> >>>    ... I don't think there's anything to discuss on CSS.
>>>> >>>    ... Do we have something for WebVTT?
>>>> >>>
>>>> >>>    David: Yes, we should approve the transition to CR.
>>>> >>>
>>>> >>>    Nigel: Any preferences about what order we do these in?
>>>> >>>
>>>> >>>    Pierre: I'd really like to close the IMSC ticket, because it is
>>>> >>>    blocking CR.
>>>> >>>    ... If there's anything missing on that push-back on TTML1 we
>>>> >>>    should address that ASAP.
>>>> >>>
>>>> >>>    Nigel: We should be able to get through everything today -
>>>> >>>    we're scheduled for 2 hours.
>>>> >>>
>>>> >>> F2F meetings
>>>> >>>
>>>> >>>    Nigel: Thierry wants us to discuss if we wish to meet at TPAC
>>>> >>>    in Lyon, which is at the end
>>>> >>>    ... of October this year.
>>>> >>>    ... I expect us to be getting towards the end of our Rec
>>>> >>>    transitions for all our specs at that
>>>> >>>    ... time, but I expect there will be a lot to discuss, so I
>>>> >>>    propose that we ask for what we
>>>> >>>    ... usually ask for, i.e. 2 days.
>>>> >>>
>>>> >>>    Pierre: Sounds good.
>>>> >>>
>>>> >>>    Nigel: Okay, I'll complete the WBS for TTWG asking for that.
>>>> >>>    ... There will be a request for any groups we don't want to
>>>> >>>    clash with, or want to have joint
>>>> >>>    ... meetings with. I would at least propose that we ask for a
>>>> >>>    joint meeting with CSS WG like
>>>> >>>    ... we did last time, on the basis that we expect to have made
>>>> >>>    some progress.
>>>> >>>    ... Any other thoughts?
>>>> >>>
>>>> >>>    group: [silence]
>>>> >>>
>>>> >>>    Nigel: The next proposal is that we have a f2f on May 22 and
>>>> >>>    23rd at IRT in Munich. Andreas
>>>> >>>    ... has kindly offered to make space available there before the
>>>> >>>    IRT subtitle technology symposium,
>>>> >>>    ... and I think the timing will be good to iterate over TTML2
>>>> >>>    and IMSC 1.1 tests for the test suite.
>>>> >>>
>>>> >>>    Cyril: I might be able to make that.
>>>> >>>
>>>> >>>    Pierre: It's unlikely I'd be able to make it.
>>>> >>>
>>>> >>>    Nigel: Okay, I'll send an email round about this; for now it is
>>>> >>>    a proposal. I think if we
>>>> >>>    ... intend to talk about test suites we need the right people
>>>> >>>    in attendance.
>>>> >>>
>>>> >>> TTML1 3rd Edition CR
>>>> >>>
>>>> >>>    Nigel: We submitted the transition request to CR for TTML1
>>>> >>>    Third Edition and Ralph
>>>> >>>    ... responded expressing surprise that no new tests have been
>>>> >>>    created to verify that implementations
>>>> >>>    ... conform to the clarifications and error corrections. He
>>>> >>>    asked if the test suite has been
>>>> >>>    ... updated at all. He's basically asking us to update the test
>>>> >>>    suite to demonstrate it.
>>>> >>>
>>>> >>>    Pierre: I think it only needs to be updated selectively to
>>>> >>>    cover the areas changed.
>>>> >>>
>>>> >>>    Nigel: I think that's right.
>>>> >>>
>>>> >>>    Pierre: I think that's possible to do.
>>>> >>>
>>>> >>>    Nigel: I think if we're claiming that implementations meet the
>>>> >>>    updates already then we need
>>>> >>>    ... to provide evidence.
>>>> >>>
>>>> >>>    Pierre: My recommendation is to change the SOTD to include exit
>>>> >>>    criteria that require
>>>> >>>    ... passing tests, and then create those test suites.
>>>> >>>    Alternatively I could provide GitHub
>>>> >>>    ... pointers to issues on imsc.js, but that might be a lot of
>>>> >>>    work with no guarantee of success.
>>>> >>>
>>>> >>>    Nigel: That would work.
>>>> >>>    ... If we're going to do that we need to make the updates and
>>>> >>>    re-file the transition request.
>>>> >>>
>>>> >>>    Pierre: I'll make the SOTD updates.
>>>> >>>
>>>> >>>    Nigel: When that's done, please let me and Thierry know so
>>>> >>>    Thierry can update the transition request.
>>>> >>>
>>>> >>> IMSC
>>>> >>>
>>>> >>>    Nigel: we have one pull request on the agenda.
>>>> >>>
>>>> >>> Update feature list per TTML2 imsc#350
>>>> >>>
>>>> >>>    github: [18]https://github.com/w3c/imsc/pull/350
>>>> >>>
>>>> >>>      [18] https://github.com/w3c/imsc/pull/350
>>>> >>>
>>>> >>>    Nigel: I think the main issue here is the syntax permitted for
>>>> >>>    tts:extent.
>>>> >>>    ... I don't understand why the `auto` value is permitted for
>>>> >>>    `tts:extent` on `tt:tt`...
>>>> >>>
>>>> >>>    Pierre: It was permitted before.
>>>> >>>
>>>> >>>    Nigel: But has its meaning changed? It used to be defined as
>>>> >>>    the Root Container Region,
>>>> >>>    ... now it is defined as "contains" whose meaning is defined by
>>>> >>>    appendix H.
>>>> >>>
>>>> >>>    Pierre: When I went through this before I decided that
>>>> >>>    "contains" ends up meaning the same
>>>> >>>    ... as "auto" used to mean in TTML1 - it yielded the right
>>>> >>>    outcome.
>>>> >>>    ... Note that in IMSC pixelAspectRatio is prohibited, so
>>>> >>>    "contains" resolves as the display
>>>> >>>    ... aspect ratio of the root container region.
>>>> >>>
>>>> >>>    Cyril: And the algorithm in H.1 and H.2 match?
>>>> >>>
>>>> >>>    Pierre: Yes, if there's no DAR and PAR then it's H.1.1 which
>>>> >>>    corresponds to TTML1 100% 100%,
>>>> >>>    ... i.e. auto semantics.
>>>> >>>
>>>> >>>    Nigel: So Pierre you're arguing that contain and auto resolve
>>>> >>>    to the same so it is better to
>>>> >>>    ... have a single syntax option rather than allow the
>>>> >>>    semantically more precise "contain"?
>>>> >>>
>>>> >>>    Pierre: Yes.
>>>> >>>
>>>> >>>    Cyril: There may be cases where auto and contain resolve
>>>> >>>    differently?
>>>> >>>
>>>> >>>    Pierre: Outside the tt element, maybe, but on the tt element
>>>> >>>    they are identical.
>>>> >>>
>>>> >>>    Cyril: Yes, the spec says if the value is auto, and its the tt
>>>> >>>    element, then it maps to contain.
>>>> >>>    ... So they are equivalent.
>>>> >>>    ... I think the constraint on IMSC is correct.
>>>> >>>
>>>> >>>    Nigel: Okay, I'm persuaded.
>>>> >>>    ... The next comment here is about extends and restricts.
>>>> >>>    Pierre commented that
>>>> >>>    ... there's no requirement for them, and presumably there's no
>>>> >>>    benefit identified for them here?
>>>> >>>
>>>> >>>    Pierre: No, I have not.
>>>> >>>
>>>> >>>    Nigel: I can see that from an implementation perspective it may
>>>> >>>    add a fair amount of code
>>>> >>>    ... and tests to allow extends and restricts.
>>>> >>>
>>>> >>>    Pierre: Also this new TTML2 syntax was not broken out as a
>>>> >>>    specific feature designator.
>>>> >>>    ... I think I raised an issue on TTML2 for that.
>>>> >>>    ... Maybe later it will be made a feature and we can then
>>>> >>>    refactor this text.
>>>> >>>    ... It would be a lot clearer.
>>>> >>>
>>>> >>>    Nigel: Ok, there are conflicts here but I'm happy to approve
>>>> >>>    the changes.
>>>> >>>
>>>> >>>    SUMMARY: @nigelmegitt to approve the pull request
>>>> >>>
>>>> >>>    Pierre: The conflicts are super-boring, I'll fix those.
>>>> >>>
>>>> >>>    github-bot, end topic
>>>> >>>
>>>> >>> Clarify the use of recommended character sets imsc#354
>>>> >>>
>>>> >>>    github: [19]https://github.com/w3c/imsc/pull/354
>>>> >>>
>>>> >>>      [19] https://github.com/w3c/imsc/pull/354
>>>> >>>
>>>> >>>    Nigel: You're waiting on someone from i18n on this, Pierre?
>>>> >>>
>>>> >>>    Pierre: Yes, during the call people used the term "safe" but
>>>> >>>    the comments were against that.
>>>> >>>    ... Instead, I've proposed to use "common" and am waiting for a
>>>> >>>    response on that.
>>>> >>>
>>>> >>>    Nigel: That change was made on the pull request, but there's no
>>>> >>>    comment about it, but
>>>> >>>    ... there is on the issue?
>>>> >>>
>>>> >>>    Pierre: Oh yes, I could prompt Addison to review with a comment
>>>> >>>    on the pull request. I'll just do that.
>>>> >>>
>>>> >>>    Nigel: I'm not sure what we can do more on this at the moment.
>>>> >>>
>>>> >>>    Pierre: It is only a matter of finding the right terminology
>>>> >>>    now, I think we're good on the rest.
>>>> >>>
>>>> >>>    Nigel: Looks that way.
>>>> >>>
>>>> >>>    SUMMARY: WG awaiting review feedback from i18n.
>>>> >>>
>>>> >>>    Pierre: We should communicate to them that we plan to request
>>>> >>>    transition to CR in 7 days
>>>> >>>    ... so they need to come back soon if they have a strong
>>>> >>>    concern.
>>>> >>>
>>>> >>>    Nigel: That sounds like an action for me to send a message
>>>> >>>    immediately after this meeting.
>>>> >>>
>>>> >>>    github-bot, end topic
>>>> >>>
>>>> >>> TTWG Charter
>>>> >>>
>>>> >>>    Thierry: Not much to discuss - I have submitted the draft
>>>> >>>    charter to W3M, and I think they
>>>> >>>    ... were supposed to review it yesterday but I have nothing to
>>>> >>>    report yet.
>>>> >>>
>>>> >>> WebVTT
>>>> >>>
>>>> >>>    <scribe> Chair: David
>>>> >>>
>>>> >>>    David: At TPAC we looked at the transition request, and the
>>>> >>>    actions requested have been
>>>> >>>    ... done. We were waiting on closing out some issues on the
>>>> >>>    spec which Nigel was unable
>>>> >>>    ... to get to for the first few weeks of this year. My feeling
>>>> >>>    is that the remaining issues can
>>>> >>>
>>>> >>>    <dsinger>
>>>> >>>    [20]https://lists.w3.org/Archives/Public/public-tt/2018Mar/0133
>>>> >>>    .html
>>>> >>>
>>>> >>>      [20]
>>>> >>> https://lists.w3.org/Archives/Public/public-tt/2018Mar/0133.html
>>>> >>>
>>>> >>>    David: be closed off in CR. I would like to ask for the formal
>>>> >>>    agreement of the group to do
>>>> >>>    ... the final transition. I sent the final draft of the request
>>>> >>>    a couple of days ago.
>>>> >>>    ... I updated the wide review page a couple of days ago to
>>>> >>>    reflect the current status. I hope
>>>> >>>    ... we're at the formal stages now - we had the [scribe loses
>>>> >>>    track]
>>>> >>>    ... There will likely be some changes to be made during CR,
>>>> >>>    which are not major changes
>>>> >>>    ... for implementors but may for example require a change to
>>>> >>>    the computed CSS property value for something.
>>>> >>>    ... I think we need an updated version of the spec with SOTD
>>>> >>>    etc for CR, which Silvia and/or
>>>> >>>    ... Thierry can do.
>>>> >>>
>>>> >>>    <dsinger> The remaining edits are clarification, warning, and
>>>> >>>    so on and don’t represent technical changes to the
>>>> >>>    specification, so I think it’s safe to do them along with any
>>>> >>>    other disambiguations needed by implementers during CR.
>>>> >>>
>>>> >>>    Nigel: What I normally do at this point is ask Thierry what is
>>>> >>>    needed now for the transition request?
>>>> >>>
>>>> >>>    Thierry: For the SOTD there are a few things that need to be
>>>> >>>    put in, first the exit criteria.
>>>> >>>    ... From David's statement, that is like what we have been
>>>> >>>    using within this group, 2 implementations
>>>> >>>    ... for each feature, so that sound good.
>>>> >>>    ... The second thing I have not seen are the features at risk,
>>>> >>>    because there are some features
>>>> >>>    ... that are not implemented like regions and some others.
>>>> >>>
>>>> >>>    David: We discussed this, it's at the end of point 1, and as
>>>> >>>    discussed, we don't want to drop
>>>> >>>    ... them so we aren't marking them as at risk. They are not
>>>> >>>    features to drop if they are not
>>>> >>>    ... implemented. The group wanted to wait until they're
>>>> >>>    implemented, and have no features at risk.
>>>> >>>
>>>> >>>    Thierry: Okay. Another thing is for the test suite and the
>>>> >>>    implementation report. Of course
>>>> >>>    ... we have to fill the implementation report in later. We
>>>> >>>    should have a link to a test suite
>>>> >>>    ... or something if it is incomplete.
>>>> >>>
>>>> >>>    David: Yes, that's also in the transition request, there's a
>>>> >>>    fairly thorough test suite in
>>>> >>>    ... web platform tests, which generates automated reports for
>>>> >>>    browsers, and we're going to
>>>> >>>    ... have work out how to do that for non-browser
>>>> >>>    implementations during CR. That's for
>>>> >>>    ... me and the group to do during CR.
>>>> >>>
>>>> >>>    Nigel: We don't normally ask for that at this stage?
>>>> >>>
>>>> >>>    Thierry: We don't need the whole thing, just a link to whatever
>>>> >>>    is there.
>>>> >>>
>>>> >>>    David: We believe it is pretty thorough at this point, I'm sure
>>>> >>>    there are bugs that people will
>>>> >>>    ... find during implementation work.
>>>> >>>
>>>> >>>    Thierry: The last bit is the wide review, I guess it is done,
>>>> >>>    we have a URI, and it will be up
>>>> >>>    ... to the Director to review it.
>>>> >>>    ... The last thing is WG approval for transitioning.
>>>> >>>    ... I need a link to point to.
>>>> >>>
>>>> >>>    PROPOSAL: Agree to the CR transition to WebVTT
>>>> >>>
>>>> >>>    Pierre: For clarity, that's based on the gh-pages branch on
>>>> >>>    GitHub?
>>>> >>>
>>>> >>>    David: Yes, that's correct, Silvia will need to update that.
>>>> >>>
>>>> >>>    Pierre: And all the licence and IPR issues have been addressed
>>>> >>>    and there's not going to be
>>>> >>>    ... any drama there?
>>>> >>>
>>>> >>>    David: I don't think so, no exclusions have been filed so far
>>>> >>>    and we asked for FSA from all
>>>> >>>    ... the CG contributors.
>>>> >>>
>>>> >>>    Pierre: And some of the contributions have been from the CG
>>>> >>>    since then, or all from members of the WG?
>>>> >>>    ... (after that commitment was received)
>>>> >>>
>>>> >>>    David: Even if they came from the CG they did sign a CLA. The
>>>> >>>    only issue would be if they
>>>> >>>    ... contributed someone else's IPR and that's a door I don't
>>>> >>>    know how to close. There's nothing
>>>> >>>    ... that's giving me any anxiety.
>>>> >>>
>>>> >>>    Pierre: So the next step is to create a CR branch for the group
>>>> >>>    to review the final version.
>>>> >>>    ... When will that be available?
>>>> >>>
>>>> >>>    David: You'd like a formal branch in GitHub?
>>>> >>>
>>>> >>>    Pierre: Normally that's what happens, so there's a formal
>>>> >>>    document to review.
>>>> >>>    ... I'm encouraging you to do this as soon as possible so there
>>>> >>>    aren't any surprises?
>>>> >>>
>>>> >>>    David: I'll see what we can do - is there anyone on the team
>>>> >>>    who can help?
>>>> >>>
>>>> >>>    Thierry: I can help on the SOTD of course.
>>>> >>>
>>>> >>>    Pierre: I don't have any a priori objections, thank you for
>>>> >>>    doing all this additional work.
>>>> >>>
>>>> >>>    Nigel: I'd second Pierre's request, let's have the actual
>>>> >>>    document that we are going to approve on the table.
>>>> >>>
>>>> >>>    Thierry: It has to be a CR version for approval by the
>>>> >>>    Director.
>>>> >>>
>>>> >>>    Pierre: And to be clear, on the open issues you do not expect
>>>> >>>    any formal objections?
>>>> >>>
>>>> >>>    David: I'm not seeing any clouds on the horizon for the
>>>> >>>    remaining issues.
>>>> >>>
>>>> >>>    Nigel: Me neither.
>>>> >>>    ... David, you've been clear that you have limited resource for
>>>> >>>    chairing and editing. Will there
>>>> >>>    ... be the effort available to make any changes and to work on
>>>> >>>    it post-CR so that it can get
>>>> >>>    ... to Rec? My concern is that it could linger in CR forever.
>>>> >>>
>>>> >>>    <dsinger> PROPOSAL: The editor and the team to prepare the CR.
>>>> >>>    The WG approves the CR transition, with said prepared CR to be
>>>> >>>    presented to the Director for approval, using the transition
>>>> >>>    request in
>>>> >>>    [21]https://lists.w3.org/Archives/Public/public-tt/2018Mar/0133
>>>> >>>    .html
>>>> >>>
>>>> >>>      [21]
>>>> >>> https://lists.w3.org/Archives/Public/public-tt/2018Mar/0133.html
>>>> >>>
>>>> >>>    David: I share your antipathy to specs staying in CR
>>>> >>>    indefinitely, I would suggest that if
>>>> >>>    ... we cannot get to Rec within the next Charter period then at
>>>> >>>    that point we publish the
>>>> >>>    ... spec as a Note and stop working on it in the WG.
>>>> >>>
>>>> >>>    Nigel: Thank you, by time-boxing the CR that addresses my
>>>> >>>    concern.
>>>> >>>
>>>> >>>    Pierre: I think you can confidently create a CR ready spec and
>>>> >>>    state a resolution to proceed
>>>> >>>    ... with CR with this draft, intended to be the CR.
>>>> >>>    ... Then there's no surprise. Otherwise we could take a
>>>> >>>    resolution today, and in 2 weeks there's
>>>> >>>    ... something objectionable to someone and then we restart the
>>>> >>>    clock in 2 weeks.
>>>> >>>
>>>> >>>    David: I was expecting the group to approve transition today.
>>>> >>>    Thierry, can you prepare the
>>>> >>>    ... CR version of the document today?
>>>> >>>
>>>> >>>    <dsinger> Can Thierry do the pull request for the SOTD section
>>>> >>>    in the next 24 hours?
>>>> >>>
>>>> >>>    Thierry: I can work on it, and probably not in the next 2
>>>> >>>    hours, but tomorrow morning.
>>>> >>>    ... We also need in the SOTD the date for earliest advancement
>>>> >>>    beyond CR. Probably we can
>>>> >>>    ... put 3 months or whatever.
>>>> >>>
>>>> >>>    Nigel: Good point.
>>>> >>>
>>>> >>>    Thierry: I propose at least 2 months.
>>>> >>>
>>>> >>>    David: It's not going to happen for at least 6 months. We need
>>>> >>>    implementations of the changes
>>>> >>>    ... and of regions. Give it 6 months.
>>>> >>>
>>>> >>>    Thierry: You don't need to do that, you can do it in 3 if those
>>>> >>>    criteria are met.
>>>> >>>
>>>> >>>    David: Okay, put 3 months then, that's fine.
>>>> >>>
>>>> >>>    Philippe: Hello, I apologise for arriving late.
>>>> >>>    ... I don't mean to derail this meeting, but I have one
>>>> >>>    question. We have not started review
>>>> >>>    ... of the TTWG charter already, but I have one question: How
>>>> >>>    is WebVTT used on the web
>>>> >>>    ... today? Not an implementation question, a usage question. Is
>>>> >>>    it actually used on the web,
>>>> >>>    ... or only as an input format so video services can do their
>>>> >>>    own thing with captions.
>>>> >>>    ... TTML is used as an input format, and then there's client
>>>> >>>    side JS that takes that and displays
>>>> >>>    ... the subtitles and captions at the right time. YouTube,
>>>> >>>    Netflix and others don't use TTML or WebVTT,
>>>> >>>    ... they use their own code to present the captions.
>>>> >>>    ... So you don't need native implementation of captions.
>>>> >>>    ... The second question is how are we going to be able to get
>>>> >>>    out of CR for WebVTT?
>>>> >>>    ... If my assumption is correct, there is no incentive for
>>>> >>>    browser implementers to update
>>>> >>>    ... their implementations. That's part of the questions that we
>>>> >>>    are asking ourselves generally
>>>> >>>    ... about the future of captions on the web.
>>>> >>>
>>>> >>>    David: I agree a lot of captions are done with polyfills and
>>>> >>>    HTML/CSS created on the fly.
>>>> >>>    ... One of the issues with WebVTT is that it is not used for
>>>> >>>    presentation.
>>>> >>>    ... I do know that in [apple products] we take the WebVTT
>>>> >>>    natively. [sorry, scribe subject to a lot of local background
>>>> >>>    noise]
>>>> >>>
>>>> >>>    Philippe: Ok, I didn't find any statistics, for example in
>>>> >>>    Chrome, of how often the native
>>>> >>>    ... implementations are used today.
>>>> >>>
>>>> >>>    David: Okay, I'll try to find out.
>>>> >>>
>>>> >>>    Philippe: The fear is that it is not used so we will never get
>>>> >>>    to the top of the priority list for browsers.
>>>> >>>
>>>> >>>    David: I share your concern, if you can do an adequate job with
>>>> >>>    polyfills then who needs to
>>>> >>>    ... do a native implementation.
>>>> >>>
>>>> >>>    Philippe: Yes, that doesn't undermine it as an input format.
>>>> >>>    ... For example I do not know if the WebVTT implementation
>>>> >>>    natively would allow positioning
>>>> >>>    ... of captions on the fly like YouTube allows.
>>>> >>>    ... We may be chasing something that the market out there is
>>>> >>>    not interested in having in terms
>>>> >>>    ... of native implementation.
>>>> >>>
>>>> >>>    David: Right. Yes.
>>>> >>>
>>>> >>>    Nigel: In terms of resolutions, I think the next steps are to
>>>> >>>    produce the CR version of the
>>>> >>>    ... document and then for David as Chair to send a message to
>>>> >>>    the group specifying the
>>>> >>>    ... resolution that he believes has been made, and highlighting
>>>> >>>    the review period under the
>>>> >>>    ... group charter decision policy (which is 10 working days).
>>>> >>>
>>>> >>>    Philippe: At the moment we could try to run the transition
>>>> >>>    request in parallel as long as it
>>>> >>>    ... is clear to the Director that there is an opportunity for
>>>> >>>    the decision to be reversed.
>>>> >>>    ... On the IPR question, if there's a question about CG/WG
>>>> >>>    working, here it is the same
>>>> >>>    ... as if a contribution comes in on the WG public mailing
>>>> >>>    list, where we have to figure out
>>>> >>>    ... how substantive the contribution is and address that. It
>>>> >>>    doesn't change the risk
>>>> >>>    ... associated with IPR in the spec that is not directly from a
>>>> >>>    contributor. If you have concerns
>>>> >>>    ... about that then we can engage with our legal team here and
>>>> >>>    make an assessment.
>>>> >>>    ... If you tell us that everyone who contributed is in the CG
>>>> >>>    and the WG then we don't have
>>>> >>>    ... an issue.
>>>> >>>
>>>> >>> TTWG Charter
>>>> >>>
>>>> >>>    Philippe: A comment - the agreement you described before is
>>>> >>>    that if you do not have Rec
>>>> >>>    ... of WebVTT by the end of the next Charter then you would
>>>> >>>    drop it. If the theory is correct
>>>> >>>    ... that WebVTT is used as an input format rather than a native
>>>> >>>    implementation then it would
>>>> >>>    ... be no surprise if that happens.
>>>> >>>
>>>> >>>    David: One question is if you would accept two implementations
>>>> >>>    from Apple as being
>>>> >>>    ... independent, because this is in fact the case.
>>>> >>>
>>>> >>>    Philippe: Interesting question, I don't know the answer but I
>>>> >>>    can ask and get back to you.
>>>> >>>
>>>> >>>    Nigel: I have asked this recently, as an issue on the Process.
>>>> >>>
>>>> >>>    Philippe: Yes, you would need to have some evidence that the
>>>> >>>    two teams creating the implementations
>>>> >>>    ... did so by interpreting the specification directly without
>>>> >>>    any other communication.
>>>> >>>
>>>> >>>    Nigel: Any other questions or comments on the Charter?
>>>> >>>
>>>> >>>    Philippe: Not as far as I know. Thank you by the way for
>>>> >>>    providing the draft Charter.
>>>> >>>
>>>> >>> Travis
>>>> >>>
>>>> >>>    Philippe: I'm in communication with Travis to try to make the
>>>> >>>    pull request smoother.
>>>> >>>    ... I do not know why the repositories have been deactivated.
>>>> >>>    We are reaching peaks of 60 concurrent
>>>> >>>    ... jobs on travis at the moment and it keeps increasing. They
>>>> >>>    are doing some of our jobs
>>>> >>>    ... in batches and they can get delayed before they are even
>>>> >>>    started. So there's both a delay
>>>> >>>    ... and then a long queue before they run. So the plan is to
>>>> >>>    conduct an experiment on travis
>>>> >>>    ... to give them a bit of money to provide small guarantees and
>>>> >>>    see how it affects our jobs
>>>> >>>    ... being run. In parallel I've been talking to the web
>>>> >>>    platform tests people because they are
>>>> >>>    ... consuming more than half our jobs, just for testing
>>>> >>>    purposes, and we cannot separate
>>>> >>>    ... them because they are on the same organisation on GitHub.
>>>> >>>    We're potentially considering
>>>> >>>    ... moving them to a "separate" organisation on GitHub because
>>>> >>>    that project is going to
>>>> >>>    ... grow more and more. Then we can separate testing from
>>>> >>>    production of recommendations
>>>> >>>    ... more easily. Every time a pull request on WPT is done it
>>>> >>>    triggers 12 concurrent jobs.
>>>> >>>
>>>> >>>    Nigel: Thanks for that.
>>>> >>>
>>>> >>> Audio Profile of TTML2
>>>> >>>
>>>> >>>    Nigel: I've been in discussion with various organisations
>>>> >>>    (we're up to 12 right now) about
>>>> >>>    ... setting up a CG to produce a profile of TTML2 for audio
>>>> >>>    description, and hope that will
>>>> >>>    ... go ahead in the next few weeks.
>>>> >>>    ... Just noting it here in case people want to join.
>>>> >>>
>>>> >>>    Pierre: That's in a CG not the WG?
>>>> >>>
>>>> >>>    Nigel: Yes, and hopefully bring it to a future iteration of the
>>>> >>>    TTWG Charter when there is
>>>> >>>    ... a document to work on. This is partly about WG mechanics -
>>>> >>>    getting onto the Charter
>>>> >>>    ... without a document as the basis of a specification seems
>>>> >>>    harder these days, so this way
>>>> >>>    ... we can have easy participation from the interested parties
>>>> >>>    and then there's a path towards
>>>> >>>    ... getting to Rec later, albeit one that requires more W3C
>>>> >>>    membership in the case that the
>>>> >>>    ... contributors are not currently members.
>>>> >>>
>>>> >>>    Pierre: And the domain is all applications?
>>>> >>>
>>>> >>>    Nigel: Yes, not only broadcast, also web, and not making any
>>>> >>>    assumptions about where in
>>>> >>>    ... the distribution chain any audio mixing might happen.
>>>> >>>
>>>> >>>    Pierre: Thanks.
>>>> >>>
>>>> >>>    David: What I did with WebVTT is I got a FSA signed by the CG
>>>> >>>    participants - if you're
>>>> >>>    ... expecting them to give IPR away for free then they don't
>>>> >>>    get anything back.
>>>> >>>
>>>> >>>    Nigel: Right, and I've highlighted this to the participants
>>>> >>>    right from the beginning.
>>>> >>>
>>>> >>>    David: It took me months to get this for WebVTT.
>>>> >>>
>>>> >>>    Pierre: Yes, when the legal team looks at it things could take
>>>> >>>    longer.
>>>> >>>
>>>> >>> Meeting Close
>>>> >>>
>>>> >>>    Nigel: Thanks everyone! [adjourns meeting]
>>>> >>>
>>>> >>> Summary of Action Items
>>>> >>>
>>>> >>> Summary of Resolutions
>>>> >>>
>>>> >>>    [End of minutes]
>>>> >>>      __________________________________________________________
>>>> >>>
>>>> >>>
>>>> >>>     Minutes formatted by David Booth's [22]scribe.perl version
>>>> >>>     1.152 ([23]CVS log)
>>>> >>>     $Date: 2018/03/29 16:23:30 $
>>>> >>>
>>>> >>>      [22]
>>>> http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
>>>> >>>      [23] http://dev.w3.org/cvsweb/2002/scribe/
>>>> >>>
>>>> >
>>>>
>>>
>>>
>

Received on Monday, 2 April 2018 21:47:12 UTC