Re: {minutes} TTWG Meeting 2017-10-05

> 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/
>
>
>