W3C home > Mailing lists > Public > public-tt@w3.org > October 2017

{minutes} TTWG Meeting 2017-10-05

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 5 Oct 2017 16:20:01 +0000
To: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D5FC195F.4AF86%nigel.megitt@bbc.co.uk>
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, 5 October 2017 16:20:27 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:42 UTC