- From: Glenn Adams <glenn@skynav.com>
- Date: Wed, 11 Oct 2017 23:45:49 -0600
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- Cc: David Ronca <dronca@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CACQ=j+f+fy6+qU1nLFknU_u39Z5VQtpp-GZE4MWLSFjzcu=WNA@mail.gmail.com>
On Wed, Oct 11, 2017 at 10:14 PM, Pierre-Anthony Lemieux <pal@sandflow.com> wrote: > 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. > I would agree that if a TTML2 processor supports TTML1 documents and semantics, that it should process a document that is determined to be a TTML1 document in accordance with TTML1 rules. What I don't know is - whether, as currently written in TTML2, there is anything that would prevent this behavior while still adhering to TTML2 processor conformance [but I'm willing to claim this is an objective; OTOH, I haven't heard anyone make a claim there is a specific conflict, which leaves me with the conclusion that we don't really know, or at least I don't know, since I haven't scoured TTML2 for possible divergence in this scenario]; - in the absence of a user based directive, what criteria determines whether an arbitrary document is designated as a TTML2 or a TTML1 document. However, in theory, it should be possible to answer both these questions, or at least come up with an operational answer. > > 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/6eafca943b2294d2d2d97996098142 > 99e4b361cf/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 05:46:36 UTC