- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sat, 6 Apr 2019 08:51:03 +0200
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
Hi all, Quick confirmation on the WebTT state of things: * Bugzilla WebVTT bugs have all migrated to GitHub * https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html needs to be rescued and updated to match the current spec. It was a deliverable of this WG at some stage (not sure if it still is). I would not just dump it into the WebVTT GitHub repo, but create a new one if possible. * for the DIFF I simply used the W3C diff service at https://services.w3.org/htmldiff Hope this helps. Cheers, Silvia. On Thu, Apr 4, 2019 at 6:21 PM Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: > > Thanks all for attending today's TTWG meeting. Apologies if my comms about the start time were not clear enough. If it helps, I always add a timeanddate URL for every meeting that you can use to display the meeting time in your time zone. > > Minutes for today's meeting can be found in HTML format at https://www.w3.org/2019/04/04-tt-minutes.html > > In text format: > > [1]W3C > > [1] http://www.w3.org/ > > Timed Text Working Group Teleconference > > 04 Apr 2019 > > [2]Agenda > > [2] https://github.com/w3c/ttwg/issues/31 > > See also: [3]IRC log > > [3] https://www.w3.org/2019/04/04-tt-irc > > Attendees > > Present > Gary, Thierry, Nigel, Pierre, Glenn > > Regrets > Cyril, Andreas > > Chair > Nigel > > Scribe > nigel > > Contents > > * [4]Topics > 1. [5]This meeting > 2. [6]Bugzilla > 3. [7]Mercurial > 4. [8]CVS > 5. [9]WebVTT Implementation report and CR update > 6. [10]TTWG Charter > 7. [11]TTML Profile Registry > 8. [12]September F2F meeting > 9. [13]TTML3 > 10. [14]Add module framework > 11. [15]Specify fixed, implied semantics for xlink:type > and xlink:actuate (#1039). ttml2#1050 > 12. [16]Prevent font element from overriding generic font > family (#1042). ttml2#1049 > 13. [17]Meeting close > * [18]Summary of Action Items > * [19]Summary of Resolutions > __________________________________________________________ > > <scribe> scribe: nigel > > This meeting > > Nigel: We have possible regrets from Cyril. > ... For today, [iterates through agenda]. Any particular points > to make sure we cover, or other business? > > Thierry: No. > > Gary: No. > > Nigel: Okay let's get going. > ... In the light of the low attendance (maybe people were > confused about the start time today?) let's do > ... what we can for now. > > Bugzilla > > Nigel: This may affect WebVTT? > > Gary: Yes, I think most of the bugs have been transferred but > its possible some old things could have > ... been forgotten. > > Thierry: I just saw the message this morning about Mercurial > and Bugzilla. I know they will be archived > ... but I don't know more. > ... We have not used it for any TTML based work so this goes > back some time. > > Gary: I went to the page and it says its an archived snapshot > so maybe its fine to see stuff that existed > ... but not add new things. > ... Also the newest bug on VTT there is 2015, so I'm not sure > how relevant it is. > > Thierry: I think Silvia handled it. > > Nigel: OK unless someone says otherwise, let's assume there's > no action to take. > > Mercurial > > Nigel: I am 99% sure we transferred all the Mercurial content > to GitHub already. Certainly the > ... GitHub ttml1 repo contains what used to be in the TTML > Mercurial repo, since it was created by > ... transfer from Mercurial. For example the draft API docs are > in there, and the requirements docs. > ... So I don't think there's any work to do there. > > Thierry: I can't think of more on the top of my head. > > Gary: There is one old draft spec on the TTCG about 608 to VTT > that seems to be on Mercurial that may > ... be useful to capture. > > <gkatsev> > [20]https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVT > T/608toVTT.html > > [20] https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html > > <gkatsev> > [21]https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVT > T/ > > [21] https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/ > > Nigel: I see there's a sketch of an authoring guideline. > > Gary: We can probably drop that. > ... There's also an old version of the region spec. > > Nigel: That's all in the WebVTT spec now isn't it? > > Gary: Yes, exactly. > > Nigel: Is it worth creating a repo for the 608 one? > > Gary: We can just grab it and add it to the VTT repo as a > supplement, just to keep it visible. > ... I think it's outdated and needs to be updated. > > Nigel: OK, do you want to do that? > > Gary: Sure! > > Nigel: Thank you. > > CVS > > Nigel: We've not used the decommissioned CVS for anything have > we? > > Thierry: No I don't think so. It's different to the CVS for our > W3C site, for example > > Nigel: Great, so we don't need to do anything there. > > WebVTT Implementation report and CR update > > Nigel: On the Implementation Report, any answers to the Netflix > questions about Japanese language support? > > Gary: There is support for ruby positioning, ta te chu yoko > (text combine upright) in WebVTT > ... because they are permitted CSS, but no browser has > implemented it. > ... There is browser support for bouten (text-emphasis in CSS) > but it is not on the whitelist for WebVTT. > ... Then slanted text: I'm not sure what is necessary for it, > but it seems potentially possible in CSS with > ... tranform(skew) but that is definitely not whitelisted. > ... I think Japanese support is important but I don't think it > should hold up getting the current CR > ... through into PR, and then the Japanese support can come as > the next thing that I work on. > > Nigel: That's clear, thank you. > ... Does that mean web platform tests for ruby positioning > fail? > > Gary: There are no tests for it at the moment, and it is > something we can potentially add now. > > Nigel: I think it makes sense to do that because it is > whitelisted CSS. > ... Do you think any implementations might pass that? > > Gary: I could likely get it working in vtt.js. > > Nigel: I wonder if it might work on iOS. > > Gary: Also the cue setting of vertical is sort-of available. > Firefox and Chrome position it wierdly and > ... Safari inverts the two vertical options - it's possible > that can be fixed quickly so I will ping Eric and hope > ... it does not hold anything up. > > Nigel: That's definitely not one of those WebVTT non-intuitive > oddities? > > Gary: I'll check but I don't think so. > ... Chrome puts it in the middle. Firefox puts it on the > correct side but indented quite a lot, like a quarter > ... of the way in from the side. > > Nigel: Thanks for that. Moving on to the CR publication. > ... I see that we published the CR today. > > [22]WebVTT 2nd CR published today > > [22] https://www.w3.org/TR/2019/CR-webvtt1-20190404/ > > Nigel: There are some things that need fixing and can hopefully > be done in-place. > ... The Latest Version link takes you to the old one, > [23]https://www.w3.org/TR/webvtt1/ > ... And I noticed that the changes and diff links are not up to > date, in the SoTD. > > [23] https://www.w3.org/TR/webvtt1/ > > [24]Changes document > > [24] https://www.w3.org/TR/webvtt1/changes.html > > Nigel: The addition of at risk features is not listed. > > Gary: Yes > > Nigel: And the diff is the diff to the old version. > > Gary: And it doesn't include the at risk piece. > > Nigel: Yes > > [25]Diff FPWD to CR1 > > [25] https://www.w3.org/TR/webvtt1/diff.html > > Nigel: I don't know why this diff was done in this style, it's > odd. We normally see the HTML diff > ... generated by the W3 diff service, which gives nice looking > HTML output. > ... It doesn't seem like an Editorial change is needed, can you > please look at it Thierry? > > Thierry: I will look into it. > > Nigel: There's one other point - the Editor has not been > updated! > ... Silvia raised this already, she needs to be moved to the > former Editors list and Gary added as the > ... current Editor. > > Thierry: As a matter of fact today I updated the publication on > the wiki page - it says Silvia but when > ... I saw the published version I left it like that, because > that reflects what it says. > ... Sorry Gary! > > Gary: It's ok, I was just focused on getting the CR out there. > > TTWG Charter > > Nigel: Thank you Pierre for preparing a simpler charter draft > for us to work on. > > [26]Charter draft pull request #47 > > [26] https://github.com/w3c/charter-timed-text/pull/47 > > Nigel: Pierre and I had a bit of discussion offline and I think > you processed my comments before > ... opening the pull request? > > Pierre: I did one of them, we can go over the other two now. > > Nigel: Yes please. > > <gkatsev> > [27]https://htmlpreview.github.io/?https://github.com/w3c/chart > er-timed-text/blob/fc3f5e948afd372cccc7dac647da20ab943bddd7/ind > ex.html > > [27] https://htmlpreview.github.io/?https://github.com/w3c/charter-timed-text/blob/fc3f5e948afd372cccc7dac647da20ab943bddd7/index.html > > Pierre: One of your comments was about the sentence present > before that mentioned adopting features > ... from other groups like SMPTE, EBU etc. > > Nigel: Yes > > Pierre: I don't think that's a scope issue, fairly certain it's > not a success criteria issue. > ... So I think it's more of a coordination and dependency issue > with other groups. > ... I added a sentence under 4.2 instead. > > Nigel: It's good to have that in 4.2, but my request to add it > to Scope follows a conversation I had with > ... Philippe, in which I was discussing adoption of live > contribution functionality from EBU, and he said > ... no member submission, for example, was needed, because it > was clearly in scope of the WG to do this > ... based on the Charter. > ... I think we may need explicit permission here rather than > relying on implicit acceptance. > > Pierre: We should state the work we are going to do rather than > having an obtuse unmeasurable statement. > ... If we want to work on live contribution we should add it to > the deliverables. > > Nigel: On the obtuse and unmeasurable... > > Pierre: it's obtuse in the light of what you just said, before > I just thought it was unmeasurable. > > Nigel: Like you say, it's not a success criterion, rather it's > a permission, so yes, it is unmeasurable because > ... it doesn't require us to do anything. > ... I see that the Scope as drafted here already allows for > prepared and live formats, and the > ... Deliverables allows for development of new technical > reports, Rec or non-Rec. > ... So I think we're probably covered on that point. > ... Any other comments about the freedom and permission to do > new stuff? > > group: [no other comments] > > Pierre: The next question is why list existing technical > reports? > ... I guess there are some weird rules about IP where you have > to list WDs, which the team addresses. > ... Take SDP-US, why should the group address that explicitly? > ... You pointed out the wiki has that list. I looked at it and > it is not complete. > ... If I were reviewing a Charter I think it would be important > to put that list somewhere. > ... It's okay for it to be the wiki, my preference would be the > wiki, but the wiki is not complete. > ... How do we deal with this? > > Nigel: The obvious thing, regardless of the Charter is to > complete the wiki list. Thierry? > > Thierry: What is the delta? > > Pierre: All the Notes and Recs the WG has produced. > ... We can just point to the wiki then from the Charter. > > Thierry: Okay, I don't know if that's do-able. > > Pierre: The alternative is to list them in the Charter. The > downside is the list may become > ... obsolete when new documents are added. > > Nigel: Yes > > Thierry: That's the drawback with a frozen document like the > Charter. > > Pierre: We can delete that then? > > Nigel: I think we do need to say we can update or publish new > versions of existing publications, and > ... I prefer to point to the list on the wiki > > [28]Wiki publication list > > [28] https://www.w3.org/wiki/TimedText/Publications > > Pierre: Just pushing that change right now. > > Nigel: The wiki list is pretty good, I'm not sure what's > missing. > > Pierre: I found one at least... > ... The role registry for example. > > Thierry: There's a colour code showing if the spec is done > (green), ongoing (yelllow), notes (blue), abandoned (grey) > ... maybe I should highlight it better. Then there's the status > column, Rec/CR/WG Note etc. > > Pierre: I pushed that change. > > Nigel: Looks good to me, thank you. > > Thierry: I will add the role registry. > > Nigel: I wonder if the RDF from /TR would help. > > [29]/TR RDF file > > [29] https://www.w3.org/2002/01/tr-automation/tr.rdf > > scribe: It has Notes in but not the publishing WG by the looks > of things. > > Thierry: The Role registry is only on the wiki, which is why it > is not there. > > <tm> [30]https://www.w3.org/wiki/TimedText > > [30] https://www.w3.org/wiki/TimedText > > Thierry: This shows publications including the Role registry in > the wiki. Should I have a link to that wiki page? > > Nigel: I would say so. > > <tm> [31]https://www.w3.org/wiki/TTML/RoleRegistry > > [31] https://www.w3.org/wiki/TTML/RoleRegistry > > Pierre: Or turn it into a WG Note, I'm happy either way. > > Nigel: The wording "entertainment chain" needs a bit of > wordsmithing, to include any media context > ... The only other point I'd make is the scope is restricted to > formats, but should it include APIs, for example? > > Pierre: I kept that because it seems core to the existing > scope. > > Nigel: I agree the current scope does say formats. > > Pierre: To mimic the broader mission we should allow ourselves > to publish other specifications. > ... First line would become: > ... This group is chartered to develop specifications used for > the representation of timed text in online media. > > Nigel: Any objections to that? > ... > ... Okay, go for it. > > Pierre: Alright. > > Nigel: I had a question. The current draft charter has, under > Deliverables, "Normative Specifications" and > ... "Other Deliverables". Is it important to keep that? The > draft we're working on here replaces them with > ... Technical Reports, and Other Deliverables. > > Thierry: I don't know what a normative specification is, I know > what a normative section is. > > Glenn: That's a good point, specifications aren't normative in > themselves. > ... Say Rec track if that's what you mean. > > Nigel: We don't even need to do that. > > Pierre: I've done another push to fix the scope as discussed. > ... On the "entertainment chain" point, we can just remove that > sub-clause... > > Nigel: Yes, do that (enthusiastically)! > > Pierre: Alright, done. > > Nigel: Brilliant. I suggest we merge this and use it as the > basis for a new review. > > Pierre: +1 > > Nigel: Any objections to merging this? > > group: [no objections] > > Nigel: Okay please merge it. > ... Still to do, after our review, is addressing the Chair > section and basis documents for listed > ... deliverables, which Philippe tells me are both jobs for W3 > staff. > > Pierre: I will merge that. > > Nigel: Thank you Pierre for your work here! > > TTML Profile Registry > > Nigel: Unless anyone has anything to discuss here, I think the > only thing is to note that we are half > ... way through the Decision review period for publishing a new > version of the Note and addressing > ... issue 71 later. > > September F2F meeting > > Pierre: Tuesday to Thursday is the best I can do at TPAC. > > Glenn: Have we signed up to Thursday and Friday? > > Nigel: Yes, so far. > ... If we scheduled our meeting for Tuesday and Thursday we > would likely clash with AC on both days. > > TTML3 > > Glenn: Pull #30? > > Add module framework > > github: [32]https://github.com/w3c/ttml3/pull/30 > > [32] https://github.com/w3c/ttml3/pull/30 > > Glenn: I don't know what we're waiting on for this. > ... We discussed it, and Pierre preferred not to define public > and private, which are gone. I'm just waiting > ... for an approval. It's fine to consider backporting this to > TTML2, but I want it wrapped up in TTML3 > ... first. If it satisfies concerns about new functionality > then that may be something to discuss later. > > Pierre: The spec still references private modules. > > Glenn: Yes, just in prose, not as a defined term. That was > intentional. > > Pierre: I'm happy to file a separate issue on TTML2. > ... What I find really hard is not being able to do a diff. > Reviewing the snippets out of context is really hard. > ... Any plans to get a diff working? > > Glenn: There used to be a W3 diff service. I haven't tried it > for a while, but last year it wasn't working at all > ... and the only way I could get a diff was to request Philippe > to do it manually and send me a link, which > ... was inefficient. If the service is working then someone has > it working somewhere. I agree with you it > ... would be nice to have it working, but it's orthogonal to > this particular issue. > > Nigel: This is important for working group effectiveness. We > already build the spec onto a different branch. > ... all that is needed is to present it in a useful form. > Thierry, can you follow up with Philippe on this? > > Thierry: There have been many requests about the diff tool not > working, but the systems teams has > ... not yet resolved that issue. > > Nigel: That is part of the problem, but this is broader than > that. The PR-Preview tool can generate diffs, > ... but we can't use it here, which is the painful part. > ... It's hard to know what more to do. > ... Perhaps we can use htmlpreview.github.io > > Pierre: I do have a technical question about this pull request. > ... Document conformance: How does pruning for conformance work > in the context of modules? > ... Section 4 step 1. > ... It currently refers to vocabulary in section 5 Vocabulary, > but that's no longer true. > > Glenn: The pull request modifies the text in section 4. It > effectively incorporates the language into the > ... previous sentence by saying it is defined in terms of a > collection of functional modules. > ... It doesn't distinguish between internal and external > modules. > > Pierre: The requirement for this to work, profiles of TTML have > to implicitly or explicitly define the > ... collection of functional modules that they support. > > Glenn: Yes, and right now I think that's how they work, and it > is implicit at this point. > ... All of the feature designators in TTML2 for example can be > associated with some internal module, > ... in terms of element and attribute definitions. > ... Then there's the additional loosey-goosey link between > modules and schemas. > ... The language in 4.1 has always been rather general and I > didn't want to make it less general. > ... I also wanted to introduce modules and have it cover the > existing functionality as well as new functionality. > ... That language is simpler than what was there previously and > works at least in my mind. > > Nigel: There's a lot more complexity about relating profiles to > vocabulary which I don't think we can > ... really address in 4.1 without getting very verbose. This is > probably as good as we can get. > > Pierre: Section 5 is still referenced from 4.2 and 4.3. > > Glenn: Is that a barrier to resolving this pull request? > > Pierre: It's a copy-paste wouldn't you say, would you be able > to address it? > > Glenn: I see what you mean, not just referencing 5 Vocabulary. > ... I agree and will make that change before I merge it. > > Pierre: Fine with me. > > Glenn: Thanks for pointing that out. > > Pierre: I'm hunting for every reference to section 5 for > vocabulary. > > Glenn: I'll make those changes and merge if there are no > objections. > > Nigel: Yes, I've heard no objections, go ahead and do that > please. > ... If more issues get raised on the merged text we can address > them later. > > Specify fixed, implied semantics for xlink:type and xlink:actuate > (#1039). ttml2#1050 > > github: [33]https://github.com/w3c/ttml2/pull/1050 > > [33] https://github.com/w3c/ttml2/pull/1050 > > Glenn: The only comment is to ask if there are any tests, and I > don't think we can test it. > > Nigel: That's right, so this is a normative change that we > cannot test? > > Glenn: That's right, it's an ambiguity being resolved. If it is > possible to demonstrate that an implementation > ... ignores this, but how could you test it? > ... You could create content but only that implementation could > look at the results and see if they > ... satisfy the test. We could create the test without the > sample output. > > Nigel: We don't always define the test output as a sample > though? > > Glenn: We always do for presentation tests. There's no > validation to be done because it's never specified. > ... I think we should go ahead and accept it and we will have > to describe this as a category of substantive > ... changes that we cannot test except by reference to > undefined external behaviour. > > Nigel: I think that's true, but if we can't test it doesn't > that mean we don't need the change? > > Glenn: No it's important to clarify it. In the future we might > define the actuate and type attributes, in which > ... case we would have something testable. > > Nigel: Can we move on then? > > Glenn: Can you add an approval? > > Nigel: Yes. Just for the record, any objection to merging this > normative change without a test? > > group: [no objection] > > RESOLUTION: Merge this pull request > > Nigel: I've approved it. > > Glenn: Thank you. > > Prevent font element from overriding generic font family (#1042). > ttml2#1049 > > github: [34]https://github.com/w3c/ttml2/pull/1049 > > [34] https://github.com/w3c/ttml2/pull/1049 > > Nigel: I think we need language here like under tts:extent that > describes errors for validation processing > ... and ignoring for presentation processing. > > Glenn: If we make that change here we need to do it elsewhere > in the spec too. For example > ... in rubyPosition, where we did not call out validation > processing vs presentation processing. > > Nigel: Yes, it would be good to make that kind of change here > too. > > Glenn: If you'd like to file an issue asking to qualify the > phrase "considered an error" with "with respect > ... to validation processing" elsewhere in the spec, but I > would rather not deal with it here. > > Nigel: I'd rather get this right first time. > ... We could do that, it may generate some additional test > cases. > > Glenn: Can you take off your change request here and then deal > with that in another issue and pull request? > > Nigel: I'm a bit grumpy about this but yes, okay. > > Meeting close > > Nigel: Thanks everyone, we're slightly over time, so I'll > adjourn now. Hopefully we can fit our work into > ... a 1 hour meeting next week. [adjourns meeting] > > Summary of Action Items > > Summary of Resolutions > > 1. [35]Merge this pull request > > [End of minutes] > __________________________________________________________ > > > Minutes manually created (not a transcript), formatted by > David Booth's [36]scribe.perl version 1.154 ([37]CVS log) > $Date: 2019/04/04 16:18:19 $ > > [36] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [37] 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. > > ---------------------
Received on Saturday, 6 April 2019 06:51:46 UTC