- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 02 Apr 2018 20:32:18 +0000
- To: David Ronca <dronca@netflix.com>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, Philippe Le Hegaret <plh@w3.org>, Public TTWG List <public-tt@w3.org>
- Message-ID: <CAHp8n2naHy3iXVqtRdDnTFZTNV6t_dL8h66JTCw=8CgTA_XZLQ@mail.gmail.com>
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 20:33:04 UTC