- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Wed, 11 Oct 2017 21:14:06 -0700
- To: Glenn Adams <glenn@skynav.com>
- Cc: David Ronca <dronca@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Timed Text Working Group <public-tt@w3.org>
Hi Glenn, > As currently expressed in TTML2, this is at the option of the implementer Yes, there will be variations across implementations. However do you agree that it would be undesirable if, given a document that contains only TTML1 syntax, a processor was compelled by the TTML2 specification to process differently than it would have been compelled by the TTML1 specification. For instance, wouldn't it be undesirable if "associate region" algorithm (which is normative in both TTML1 and TTML2) would compel an implementation to end-up with a different associated region given the aforementioned document? In order words, can't we set the objective to achieving equivalence on those features that TTML1 and TTML2 have in common, given a document that contains only TTML1 syntax. Best, -- Pierre On Wed, Oct 11, 2017 at 8:33 PM, Glenn Adams <glenn@skynav.com> wrote: > > > On Wed, Oct 11, 2017 at 8:33 PM, Pierre-Anthony Lemieux <pal@sandflow.com> > wrote: >> >> 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 > > > I want to point out that we do not yet have WG consensus on either of these > points, and the second of these has only just been posted and not even > discussed by the WG. > > Nonetheless, I don't see any problem to resolve the first of these, even > though, IMO, it sets a bad precedent, namely, allowing extensions in a > profile (and, indeed, one not yet deployed, which I claim is the case for > IMSC1.0.1) to dictate future directions in TTML proper. > > As for the second, I responded today on this issue that it is not at all > clear what is meant here, let alone reaching a comment agreement. For > example, one definition of strict superset is syntactic superset. Adding > semantics to this mix pushes it to an entirely different level, and we have > barely scratched that surface. The question that remains in my mind is > whether it is mandatory that every TTML2 processor be a TTML1 processor. As > currently expressed in TTML2, this is at the option of the implementer, and > not a criteria for satisfying TTML2 processor conformance. > >> >> 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 04:14:56 UTC