- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Wed, 11 Oct 2017 19:33:04 -0700
- To: David Ronca <dronca@netflix.com>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, Timed Text Working Group <public-tt@w3.org>
Hi David, > Adding a significant amount of TTML2 functionality into IMSC1 and mixing TTML 1 and 2 seems untenable. In the current IMSC1.1 draft, all references to TTML1 have been replaced with reference to TTML2. > We need an IMSCvNext profile that is a pure subset of TTML2. That remains the objective. In order to achieve it, - TTML2 needs to be tweaked to match industry practice and expectations, e.g. make sure that fillLineGap behaves identically in TTML2 as it does in IMSC1.0.1 [1]. - TTML2 has to be a strict superset of TTML1, i.e. given a document that conforms to TTML1 and does not use any TTML2 features, a TTML2 processor needs to process the document as a TTML1 processor would have [2]. [1] https://github.com/w3c/ttml2/issues/429 [2] https://github.com/w3c/ttml2/issues/458 Hope this makes sense. Best, -- Pierre On Mon, Oct 9, 2017 at 4:45 PM, David Ronca <dronca@netflix.com> wrote: >> Given that we're not proposing a pure subset of TTML2 I would propose >> calling this >> ... IMSC v1.1, especially since we seem to be targeting IMSC 1 >> compatibility. > > Adding a significant amount of TTML2 functionality into IMSC1 and mixing > TTML 1 and 2 seems untenable. Will a processor have to decide > feature-by-feature, whether to interpret as TTML1 or TTML2? > > We need an IMSCvNext profile that is a pure subset of TTML2. Giving it a > version 1.1 seems to obfuscate the fact that IMSCvNext necessarily carries > significant changes from V1. Especially WRT JA features. > > > On Thu, Oct 5, 2017 at 9:20 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: >> >> Thanks everyone for attending today's TTWG meeting. Minutes can be found >> in HTML format at https://www.w3.org/2017/10/05-tt-minutes.html >> >> Please note the proposal to publish a FPWD of IMSC v1.1 next week, and to >> publish the IMSC v1.1 requirements. >> >> Minutes in text format: >> >> [1]W3C >> >> [1] http://www.w3.org/ >> >> Timed Text Working Group Teleconference >> >> 05 Oct 2017 >> >> See also: [2]IRC log >> >> [2] http://www.w3.org/2017/10/05-tt-irc >> >> Attendees >> >> Present >> Nigel, Pierre, Andreas, Mike, Thierry, Glenn >> >> Regrets >> Cyril >> >> Chair >> Nigel >> >> Scribe >> nigel >> >> Contents >> >> * [3]Topics >> 1. [4]This meeting >> 2. [5]IMSC vNext Issues >> 3. [6]SMPTE backgroundImage deprecation >> 4. [7]TTML2 Wide and Horizontal Review >> 5. [8]IMSC vNext FPWD >> 6. [9]TTML2 #454 Missing ruby attributes from list of >> styling attributes >> 7. [10]TTML2 #440 Condition attribute missing in Core >> catalog. >> 8. [11]Other TTML2 issues >> 9. [12]Meeting close >> * [13]Summary of Action Items >> * [14]Summary of Resolutions >> __________________________________________________________ >> >> <scribe> scribe: nigel >> >> This meeting >> >> Nigel: I haven't had confirmation of whether David or Silvia >> will join, so we'll bump WebVTT >> ... down the agenda until they join. >> ... Today then we have IMSC vNext requirements, TTML2 wide >> review comments, and >> ... then WebVTT review comments. >> ... Anything else to cover, or specific points to raise? >> >> Pierre: I sent an email - suggest getting to FPWD of IMSCvNext >> as soon as possible, >> ... hopefully by next week so that it can be in time for MPEG. >> >> Nigel: OK got that for the agenda, anything else? I know for >> TTML2 we need to think about >> ... review comment timing. >> >> Pierre: I'd like to cover Mike's two IMSC issues too. >> >> Nigel: I don't think there's anything to discuss re TPAC so >> I'll drop it from today's agenda. >> >> IMSC vNext Issues >> >> Pierre: Mike brought up two issues: a) if all IMSC vNext >> references should be to TTML2, >> ... and if TTML2 is in fact a superset of TTML1 and processing >> a TTML1 document with the >> ... TTML2 processor will yield the same result. >> ... b) deprecation of smpte:backgroundImage - to me that was a >> good exercise to try >> ... deprecating that. >> >> github: [15]https://github.com/w3c/imsc/issues/258 >> >> [15] https://github.com/w3c/imsc/issues/258 >> >> Mike: I was concerned that the focus has shifted from being an >> extension of IMSC 1.0.1 >> ... to being a subset of TTML2 and those things aren't >> necessarily incompatible but they >> ... change the risk profile, so I'd like the group to consider >> the choice here. It may be that >> ... we have to reference both TTML1 and TTML2, but changing >> everything to TTML2 when >> ... there's a risk that the processing would change. >> >> Nigel: I've always thought that TTML2 is a superset of TTML1, >> and I've never seen anything >> ... that made me doubt that. >> >> Pierre: There's a related issue w3c/ttml2#442 requesting that >> the scope of TTML2 is >> ... defined as a superset of TTML1. For example there are >> changes to prose for style resolution. >> >> Glenn: Something to bear in mind is that a TTML2 document will >> be processed differently >> ... by a TTML1 processor and a TTML2 processor. But more >> importantly if a TTML2 >> ... processor is processing a TTML1 document then its incumbent >> on the implementation >> ... to behave modally as a TTML1 processor. It's not completely >> clear what we're talking about. >> >> Mike: We need to make a fundamental decision that either IMSC >> vNext is a superset of >> ... IMSC 1.0.1 or a subset of TTML2. Based on what Glenn just >> said I'm really concerned here >> ... about replacing TTML1 references with TTML2 ones. >> >> Andreas: I think this is really important, that IMSC vNext is a >> strict superset of 1.0.1. >> ... The question for this superset in the next version of which >> version of TTML should be >> ... referenced for already present features is not easy to >> answer. If we change any TTML1 >> ... reference to TTML2 that could be a blocker for adoption of >> IMSC vNext because all >> ... implementers need to check everything that's referenced and >> verify that their >> ... implementation is still compliant. >> >> Pierre: I thought the goal was to make TTML2 a superset of >> TTML1, but are you saying >> ... that a TTML2 processor would process a document differently >> from a TTML1 processor? >> >> Glenn: Not if it is processing it as a TTML1 processor. >> >> Pierre: What has changed? >> >> Glenn: Lots of things, I'd have to check. Looking at the >> version number, treating origin and >> ... position if both are present - if processing as a TTML2 >> document it would use position >> ... in preference to origin. >> >> Nigel: I think that's a different question - position would >> never be present in a TTML1-only document. >> >> Mike: But other TTML2 properties may be added to a TTML1 >> document, such as disparity, >> ... as has been adopted by ATSC. If the presence of that TTML2 >> attribute triggers different >> ... processing of the whole document than in TTML1 that would >> be a worry. >> >> Glenn: It may be that we need to think about this a bit more. >> >> Pierre: I'm happy to back out the TTML2 references and replace >> by TTML1 in IMSC vNext, >> ... or I'm equally happy to make TTML2 a superset of TTML1. >> >> Glenn: It is a superset in that it supports the features. The >> question is which mode is it >> ... operating in, either with the knowledge of some fixes >> relative to TTML1, or if the author >> ... declares that it's a TTML2 document, and puts a version="2" >> parameter on it, then the >> ... author has said that TTML2 rules should apply. >> ... I don't see this as a binary answer. >> >> Mike: In the case of TTML1 vs TTML2 we can sort that out as we >> go, but in the case of >> ... IMSC vNext it's fundamental. If the intent is backwards >> compatible then that's a different >> ... thing to "it's compatible with some different behaviours". >> >> Glenn: I agree >> >> Mike: I'm aligned with Andreas that IMSC vNext should be a >> superset of IMSC v1.0.1. >> >> Glenn: It may be that when there is an identified difference, I >> wonder if we can make a default choice without studying each >> case. >> ... Absent of information, I would assume that a reference to >> TTML1 would be a safer bet >> ... than simply adopting references to TTML2 across the board. >> >> Nigel: How does rendering using CSS factor into this, given >> that we're putting the mappings >> ... from TTML style attributes to CSS informatively into TTML2? >> >> Pierre: If we want to continue referencing TTML1 for processing >> behaviours but also add >> ... TTML2 features like ruby, then we will have to create new >> extension features for that syntax. We >> ... can't reference the TTML2 features because that brings the >> whole TTML2 processing model. >> ... For disparity it's not an issue but for something like Ruby >> then it might be an issue. >> >> Nigel: Adding something else into the mix here, we have an >> intention to work on TTML1 Third Edition >> ... which essentially backports the important fixes to TTML1 >> Second Edition. Which version >> ... of TTML1 do we want to reference in IMSC vNext? >> >> Pierre: Going back to Andreas's suggestion, if we explicitly >> state in TTML2 that the >> ... processor should process TTML1 documents as TTML1 then we'd >> be good right? Why >> ... can't we say that? >> >> Nigel: I have no reason not to be able to say that. >> >> Pierre: Can we say in TTML2 that a TTML2 processor should >> process a TTML1 document >> ... exactly as a TTML1 processor? >> >> Glenn: Yes, that's always been the goal. >> ... There are no blanket statements to that effect. >> >> Pierre: Then we have the specific issue here that Mike has >> raised - that ATSC allows >> ... tts:disparity to be used in a TTML1 document without >> specifying ttp:version="2". >> ... Could one solution in the case of IMSC vNext be never to >> use ttp:version="2" except when >> ... using a whitelist of features that are known to affect the >> processing model. Or prohibit >> ... ttp:version altogether? >> >> Andreas: A question for my understtanding for ttp:version - if >> we have a TTML1 document >> ... and we add ttp:version="2" the rendered outcome of a TTML1 >> document would be no >> ... different from a TTML1 processor at the moment? That should >> not have any effect on the >> ... outcome. >> >> Pierre: The particular example that Glenn brought up is >> position, if ttp:version="2". >> >> Glenn: More substantively if there's no profile present then >> signalling ttp:version="2" >> ... causes selection of a different default profile. If it is >> missing then the default would be >> ... as in TTML1, the old DFXP profiles. However if >> ttp:version="2" is present then it would >> ... substitute the TTML2 default profiles which bring in new >> processor profile defaults. >> >> Pierre: If ttp:version is absent, and a TTML2 processor >> encounters a ruby element what does >> ... it do? >> >> Glenn: It depends on whether it is processing it as a TTML1 or >> a TTML2 document, independently of ttp:version. >> ... If it is processing as a TTML1 document then it might >> ignore ruby even if it knows how >> ... to process ruby. That's an implementation choice. We can't >> from a spec perspective >> ... mandate the implementation in terms of backward >> compatibility in this regard. >> >> Pierre: If we remove ttp:version and let profile signalling >> completely drive processing then >> ... there would be no ambiguity. >> >> Mike: An IMSC1.0.1 document could add all the vNext features, >> and the processor might >> ... understand it, then the version becomes critical, because >> you're explicitly telling the processor >> ... to do something different. >> >> Pierre: In the case of IMSC vNext there would be a profile >> identifier so version wouldn't be needed. >> >> Glenn: I disagree. We changed the profile mechanism. The >> processor needs to know which >> ... profile processing system is being used. >> >> Pierre: The mere presence of ttp:contentProfiles signals that >> the new system is being used. >> ... The processor can unambiguously identify which TTML version >> it would be using. >> >> Glenn: You're suggesting removing ttp:version and adding an >> algorithm for deriving the >> ... TTML version being used. I don't see that as being any >> different. >> >> Pierre: I'm addressing the case identified by Mike that >> everyone might start putting ttp:version="2" in the IMSC >> documents. >> >> Glenn: That's maybe something that IMSC vNext should say >> something about but I see it >> ... as a different issue from what is in TTML2. >> >> Pierre: TTML2 requires ttp:version="2" if any TTML2 feature is >> used including ttp:contentProfile. >> ... That's what the thread has said. >> >> Glenn: No you're overstating it. I said if an author requires >> TTML2 processing they can >> ... specify it. They can still not do so. If they fail to do so >> then it would still provide some sort >> ... processing dependent on the implementation. I guess the >> question is what should TTML2 >> ... say regarding documents without ttp:version that do use a >> TTML2 feature. My response >> ... would be as an implementer, since the author hasn't said it >> is required, I would derive it >> ... using other methods, for example seeing if contentProfiles >> were present. I don't know >> ... what you can say about authors blanket putting ttp:version >> in the document. Maybe add >> ... a big warning saying "If you put ttp:version="2" then that >> may cause processing differences in TTMl2 processors compared >> to TTML1". >> >> Pierre: What will ATSC signal as the profile in documents with >> tts:disparity? >> >> Mike: There's no choice, just IMSC 1.0.1 with the extensions >> and with no other signalling. >> ... I don't remember if we suggested explicitly stating the >> profile. >> >> Pierre: Yes, IMSC, absolutely. >> >> Mike: Ok, but there's no version, or other profile and there >> probably never will be. To the >> ... extent that IMSC 1 is deployed in the US, nobody believes >> that the additions in IMSC vNext are needed. >> ... If the additions land somewhere else, in a different >> country, what is an ATSC decoder >> ... going to do? I don't know, this isn't heading in a good >> direction... >> >> Pierre: Imagine an IMSC 1 processor - it would ignore >> tts:disparity. >> >> Mike: The ATSC processor would know what to do with it. It was >> explicitly agreed by this >> ... group that an IMSC processor ignore attributes it doesn't >> understand. >> >> Pierre: Now the same document appears in a non-ATSC decoder, >> but one that is IMSC vNext, >> ... and it is labelled as IMSC v1 and there's no profile, and >> it has tts:disparity, are we trying >> ... to solve the case of what it does? >> >> Andreas: Isn't the question if we can make IMSC vNext use TTML2 >> features in a TTML1 processor? >> ... If a TTML2 feature is used then the processor must be a >> TTML2 processor. >> >> Pierre: It's hard to specify that, is TTML2 processing required >> whenever a TTML2 feature is encountered? >> >> Glenn: Here's something to consider: a complicated thing was >> introduced in HTML5 - is it compatible with previous >> specifications? >> ... Probably not. Have implementers verified that it's >> compatible with their own implementations? >> ... Probably not. It was just defined. We have a similar issue. >> We have to go ahead with >> ... caution about changes that affect processing in older >> processors. I don't know how we >> ... check that we don't break compatibility. It's not out >> intention to break it, and I don't have >> ... a list where we have made that decision either. >> >> Mike: I understand the analogy, I'm not sure it's a good one. >> >> Nigel: It's hard to move from the abstract to the concrete >> without any specific examples >> ... where a TTML2 processor has a significantly worse >> presentation than a TTML2 processor >> ... for a TTML1 document. >> >> Pierre: I'm encouraged by Glenn's response that there's no >> intention to differ. Glenn, do >> ... you have any objection to making a blanket statement in >> TTML2 that a TTML2 processor >> ... processing a TTML1 document should yield identical results? >> >> Mike: Be careful of the language. >> >> Glenn: TBD the language, but I have no reason to object to >> doing so. >> ... The question is do we want to introduce extra language. I >> think I added a compatibility section. >> >> Pierre: I would add it up front in the scope so the objective >> is clear. >> >> Glenn: Putting that in the front matter should be okay. I'm >> just going to find the section I think I added. >> >> Andreas: [I have to drop off] I support what Pierre suggested. >> It's a good opportunity to >> ... start the IMSC requirements and to keep the backward >> compatibility, which means that >> ... a TTML2 feature being used in an IMSC vNext processor would >> not change any TTML1 >> ... features used in IMSC. >> >> Glenn: I added §3.4 under conformance, and it has forward and >> backward sections. It is >> ... marked as non-normative but says things along the lines of >> what we're talking about. >> >> Mike: The conformance is one angle - it's important that a >> presentation processor also >> ... does the same thing. >> ... Currently all the language is about conformance of >> documents as opposed to rendering. >> ... Let's work on the language a bit - I'll take a run at it. >> >> Glenn: It's §3.4 in TTML2. >> ... I recall we had a look at this in the past for TTML2 too. >> >> SUMMARY: Mike to study TTML2 §3.4 and propose any >> modifications. >> >> SMPTE backgroundImage deprecation >> >> Nigel: We should defer discussing this. >> >> Pierre: Maybe a public document would help also. >> >> TTML2 Wide and Horizontal Review >> >> Thierry: I went through the archives and verified all the >> comments sent in are there plus >> ... I've added some sent as liaisons. They're all on GitHub. >> Some issues don't need any >> ... processing - if they say everything is fine. I still put >> them on GitHub so they will be on >> ... our disposition of comments. All the comments have a label, >> open, pending, etc. When >> ... the issue status changes we will add a new label. >> >> Nigel: Fantastic, thanks for that - a lot of work. >> >> Action-506? >> >> <trackbot> Action-506 -- Thierry Michel to Draft a wiki page >> explaining our review and disposition steps and labels -- due >> 2017-09-21 -- OPEN >> >> <trackbot> >> [16]http://www.w3.org/AudioVideo/TT/tracker/actions/506 >> >> [16] http://www.w3.org/AudioVideo/TT/tracker/actions/506 >> >> close action-506 >> >> <trackbot> Closed action-506. >> >> Nigel: There were a number of issues that said thank you, they >> would look at TTML2 but >> ... not before 30th September. >> >> Thierry: If you agree I would take the action to write to them >> to say we will process their >> ... comments but they should send them ASAP after their >> meetings. >> >> Pierre: I recommend to do nothing, and process them when they >> come in, and put them >> ... in a queue. >> >> Thierry: I've had comments come in 6 months late in the past >> and the Director still wants >> ... to take them into account. >> ... I want to add a bit of pressure. >> >> Pierre: They know how this works, I would say nothing! >> >> Nigel: I'm happy to do nothing - they've told us they will do >> something and we should assume that they will do so. >> ... I just wanted to check if we want to explicitly extend the >> deadline. >> >> Pierre: I would not. >> >> Thierry: I would not. >> >> Glenn: I agree, the deadline has passed. I would not put those >> in as wide review comments anyway, they're not comments about >> the spec. >> >> Nigel: The point at which we draw a close to the wide review >> opportunity is when we >> ... have agreed to request transition to CR. >> >> Thierry: Correct. >> >> Mike: Would it help to track comments as late and put them at >> the bottom of the pile? >> >> Pierre: I like that, a priori put them at the bottom of the >> pile unless we all see that it's a big >> ... issue. >> >> Nigel: Okay this is all fine for me, thanks everyone, we don't >> need to take any action at all here. >> ... We simply need to come up with a disposition for every >> substantive comment. >> >> Thierry: Some issues are marked as editorial - we should have a >> type label for editorial vs substantive. >> >> Nigel: That works for me. >> ... I think in the old tracker there was a flag for exactly >> that. >> >> <scribe> ACTION: Thierry Check if there are >> editorial/substantive labels for TTML2 issues and add if not. >> [recorded in >> [17]http://www.w3.org/2017/10/05-tt-minutes.html#action01] >> >> [17] http://www.w3.org/2017/10/05-tt-minutes.html#action01 >> >> <trackbot> Created ACTION-508 - Check if there are >> editorial/substantive labels for ttml2 issues and add if not. >> [on Thierry Michel - due 2017-10-12]. >> >> Nigel: Between now and next week please could everyone look at >> the GitHub issues and >> ... propose any dispositions, so that we can start to agree >> them in next week's meeting, or >> ... at any rate discuss them? >> >> Glenn: I've already addressed a couple of TTML2 issues, so if >> we can get resolution on those >> ... today then I would be happy to close something. >> >> IMSC vNext FPWD >> >> Pierre: I propose a 1 week review of the draft and the >> requirements document, which go >> ... hand in hand, and I keep synchronised. If there are no >> major objections publish as a FPWD >> ... and send a liaison informing them of the beginning of this >> work and inviting them to provide comments. >> >> Nigel: What's the URL of the thing we're discussing? >> ... I see that IMSCvNext is not on the master branch of the >> imsc repo. >> ... Can we put IMSC vNext in a new folder so we don't get a >> clash of URIs? >> >> Pierre: I didn't do that because then I'd have to synchronise >> IMSC 1.0.1 changes with >> ... vNext. Also we haven't got a name for it yet. >> >> <pal> >> [18]https://rawgit.com/w3c/imsc/6eafca943b2294d2d2d979960981429 >> 9e4b361cf/imsc1/spec/ttml-ww-profiles.html >> >> [18] >> https://rawgit.com/w3c/imsc/6eafca943b2294d2d2d9799609814299e4b361cf/imsc1/spec/ttml-ww-profiles.html >> >> Nigel: Given that we're not proposing a pure subset of TTML2 I >> would propose calling this >> ... IMSC v1.1, especially since we seem to be targeting IMSC 1 >> compatibility. >> >> Pierre: That's what I'm thinking too. >> >> Nigel: In that case I think we need an imsc1_1 folder. >> >> Pierre: I really would like to delay that as much as possible. >> Once it's published on /TR >> ... it doesn't really matter where it is in the repo. >> >> Nigel: It makes it really awkward to navigate though. When >> would you move it to a different folder? >> >> Pierre: I think it will become obvious. >> >> Nigel: We're not really expecting any changes to 1.0.1 >> >> Pierre: Compare with software development - you'd maintain >> different versions on different branches. >> ... Here all the tests, examples etc are going to be >> substantially the same. >> >> Nigel: The other thing you'd do is use release tags. >> ... Okay, Pierre, you proceed as Editor. >> >> Pierre: Can you request a short name? >> >> <tmichel> >> [19]https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0 >> 005.html >> >> [19] >> https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0005.html >> >> Thierry: Yes I will. Just to let you know there's a new rule as >> per the above link, and it >> ... would be worth Editors looking at this. >> >> Nigel: This is a convention for Latest Version links, mainly. >> ... Thanks for the reminder Thierry, I had seen that and not >> taken any action. >> >> <pal> ttml-imsc1.1 >> >> PROPOSAL: Publish a FPWD of IMSC v1.1 with the short code >> ttml-imsc1.1, based on the ED in the IMSCvNEXT branch >> >> Pierre: Would you like me to propose liaison text? >> >> Nigel: Yes please >> >> <scribe> ACTION: pal Propose liaison text for the IMSC 1.1 FPWD >> [recorded in >> [20]http://www.w3.org/2017/10/05-tt-minutes.html#action02] >> >> [20] http://www.w3.org/2017/10/05-tt-minutes.html#action02 >> >> <trackbot> Created ACTION-509 - Propose liaison text for the >> imsc 1.1 fpwd [on Pierre-Anthony Lemieux - due 2017-10-12]. >> >> action-507? >> >> <trackbot> action-507 -- Nigel Megitt to Add imsc vnext repo to >> agenda, board, github-bot etc -- due 2017-10-05 -- OPEN >> >> <trackbot> >> [21]http://www.w3.org/AudioVideo/TT/tracker/actions/507 >> >> [21] http://www.w3.org/AudioVideo/TT/tracker/actions/507 >> >> Nigel: I link from the agenda to >> [22]http://www.w3.org/AudioVideo/TT/board/ >> ... Has anyone here ever followed that link and looked at it? >> >> [22] http://www.w3.org/AudioVideo/TT/board/ >> >> Pierre: I have not. >> >> Thierry: No. >> >> Nigel: Does anyone use it? >> >> Pierre: I didn't realise it existed >> >> Nigel: The reason I ask is that if nobody uses it then I will >> drop it; conversely I could maintain it. >> >> Thierry: I think it's valuable. I did use it some times, I >> recall, but I'd forgotten about it. >> >> Nigel: Okay I'll update the board and continue with it. >> >> TTML2 #454 Missing ruby attributes from list of styling attributes >> >> github: [23]https://github.com/w3c/ttml2/issues/454 >> >> [23] https://github.com/w3c/ttml2/issues/454 >> >> Glenn: This was an editorial change, I've already fixed it and >> updated the ED. >> ... I guess we can change the status of this with labels. It's >> done. >> >> Nigel: I see, there's nothing significant to review here - >> Thierry do you want to apply the >> ... appropriate labels? >> >> Thierry: Yes, it's spec updated and WG approved. >> >> Nigel: I've assigned it to you Thierry. >> >> TTML2 #440 Condition attribute missing in Core catalog. >> >> github: [24]https://github.com/w3c/ttml2/issues/440 >> >> [24] https://github.com/w3c/ttml2/issues/440 >> >> Glenn: This is from Andreas and he's reviewed to say it looks >> good. >> >> Nigel: Okay I'm assigning to Thierry to update the labels. >> >> Thierry: Once we have all three of: WG resolution + spec >> updated + commenter agreement >> ... we can close issues. >> >> Glenn: What if we cannot get agreement from the commenter, do >> we have to leave issues >> ... as open if we have disagreement? >> >> Thierry: We can close issues but it will red flag to the >> Director that we will have to explain >> ... to the Director. >> >> SUMMARY: WG approves, Thierry to update labels >> >> Other TTML2 issues >> >> Glenn: We haven't discussed XML, CSS comments etc. >> >> Pierre: I would like to close those issues off, so can we >> schedule a time to do so? >> >> Nigel: Sure, if we cannot resolve it on the GitHub issue. >> ... We have discussed over the years some issues about time, >> mediaOffset, and begin and >> ... end clipping, which I want to resolve soon too. >> >> Glenn: Check if there are existing issues. >> >> Nigel: Will do. >> >> Meeting close >> >> Nigel: Thanks everyone, we've done what we could on the agenda. >> [adjourns meeting] >> >> Summary of Action Items >> >> [NEW] ACTION: pal Propose liaison text for the IMSC 1.1 FPWD >> [recorded in >> [25]http://www.w3.org/2017/10/05-tt-minutes.html#action02] >> [NEW] ACTION: Thierry Check if there are editorial/substantive >> labels for TTML2 issues and add if not. [recorded in >> [26]http://www.w3.org/2017/10/05-tt-minutes.html#action01] >> >> [25] http://www.w3.org/2017/10/05-tt-minutes.html#action02 >> [26] http://www.w3.org/2017/10/05-tt-minutes.html#action01 >> >> Summary of Resolutions >> >> [End of minutes] >> __________________________________________________________ >> >> >> Minutes formatted by David Booth's [27]scribe.perl version >> 1.152 ([28]CVS log) >> $Date: 2017/10/05 16:17:51 $ >> >> [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm >> [28] http://dev.w3.org/cvsweb/2002/scribe/ >> >> >
Received on Thursday, 12 October 2017 02:33:52 UTC