{minutes} TTWG Meeting 2018-07-26

Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at: https://www.w3.org/2018/07/26-tt-minutes.html


Please note that we made one resolution:

RESOLUTION: After resolving the open issues marked as IMSC1.1, publish the IMSC 1.1 Requirements as a Working Group Note
The review period under our decision policy for this resolution will end on 9th July or when the last open issue has been resolved, whichever is the later.

Please also note that we intend to begin working on updates to the TTML Profile Registry document, so if you have any requests to make changes, now would be a good time to raise them as issues on the repository.

In text format:


   [1]W3C

      [1] http://www.w3.org/


                Timed Text Working Group Teleconference

26 Jul 2018

   See also: [2]IRC log

      [2] https://www.w3.org/2018/07/26-tt-irc


Attendees

   Present
          Andreas, Glenn, Pierre, Thierry, Nigel

   Regrets
          Cyril

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This meeting
         2. [5]TTML1 Actions, Pull requests and Issues
         3. [6]TTML2 Actions. Pull Requests and Issues
         4. [7]Add missing @extent attribute to isd:isd. ttml2#919
         5. [8]TTML2 Implementation Report
         6. [9]IMSC
         7. [10]IMSC vNext Requirements
         8. [11]CSS actions
         9. [12]TTML Profile Registry
        10. [13]Meeting close
     * [14]Summary of Action Items
     * [15]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This meeting

   Nigel: Today we have this meeting agenda bash, and topics
   including
   ... TTML1, TTML2, IMSC, CSS TTML Profile Registry.
   ... One item of AOB from me is a reminder that we are subject
   to

   [16]Code of Ethics and Professional Conduct

     [16] https://www.w3.org/Consortium/cepc/


   Nigel: the reason for mentioning this is because we had an
   incident this week in which
   ... at least a couple of people felt that we had not stayed
   within this code.
   ... Of course that is not acceptable.
   ... There's a little more information at:

   [17]Positive Work Environment Home Page

     [17] https://www.w3.org/Consortium/pwe/


   Nigel: which also describes procedures.

   Pierre: On that topic, were the people who it was felt broke
   the code of ethics informed?

   Nigel: Yes

   Pierre: Thank you

   Glenn: I want to object to the categorisation of expressions of
   frustration as violations of
   ... the code of ethics and its a natural product of time
   constraints, and I have not been
   ... informed of a violation of the code of ethics. A couple of
   people expressed concern,
   ... Nigel did and Andreas did too, and that was it.

   Andreas: I added a comment, now deleted, which is fine because
   it was in response to
   ... a comment that was also deleted, because I found that a
   comment from Glenn was
   ... breaching the CEPC defined by W3C. I don't think we need a
   big discussion on this but
   ... from my side it clearly broke that and crossed the line and
   I want to make it clear that
   ... this is not the way we work together. We need to follow the
   guideline from W3C.
   ... This is not the first time I think that such red lines are
   crossed, so I wanted to remind
   ... everyone on that. Okay, different people have different
   views on what is harassment etc
   ... but it is clearly defined. I don't think there is any need
   for escalation now, but we need
   ... to stay within it and be respectful regardless of
   frustration or not.

   Nigel: I think I was clear in a private email that I felt that
   the behaviour was bullying, and my reasons for that.

   Glenn: I just wanted to note that there was no Finding here, if
   you want to escalate it go ahead.

   Nigel: Like Andreas I don't feel we need to escalate this now,
   but regardless of the opinion
   ... of this event, it is worth reminding ourselves that we are
   subject to the CEPC.
   ... Back to the look-ahead,
   ... In terms of agenda stuff, and look ahead, we have meetings
   on 2nd and 9th August
   ... And then two cancelled meetings on 16th and 23rd August,
   back on 30th August.
   ... I have an action to propose some dates when we should plan
   for DST time changes,
   ... which I have not yet done.
   ... This is now we are basing the meeting time on UTC, which
   therefore needs to be
   ... modified twice a year to minimise impact on members.

   Pierre: Why are we making that change?

   Nigel: This is in line with the AC direction of travel.

   Pierre: I'm fairly sure that AC did not make a fixed resolution
   here.

   Andreas: I was at the AC meeting where this came up. There were
   reasonable arguments
   ... for it. It is really difficult if someone wants to join a
   meeting from outside and see when
   ... it is and see when it is in Boston time. It is
   uncomfortable to schedule without using
   ... a time zone converter. I brought this in and proposed it. I
   don't think we need a long
   ... discussion on it. If someone objects we can stick to Boston
   time. I would like to move to UTC
   ... but if there's an objection that is fine by me.

   Pierre: Nobody in the world uses UTC, so that forces everyone
   to check. London and Boston
   ... times do mean something. I'm not sure how the decision was
   made and haven't seen
   ... a pointer to it.

   Nigel: We aren't in a position to debate the AC decision here.

   Pierre: Okay then I will happily raise it with the AC if
   someone can point me to the decision.

   Glenn: I've been using Zulu time for all kinds of scheduling
   for my lifetime. The military
   ... and radio hams use it so it is widely used. We decided this
   already so we should not
   ... revisit it now. The group discussed it so we made a
   resolution, at least there was no
   ... objection so far. Making it zulu means everyone is equally
   dissatisfied.

   Andreas: I agree with Glenn on this, we had this discussion in
   two previous meetings
   ... and I heard concerns but no objections to that. My position
   now is there is no decision,
   ... nobody forces us, it's on the group to decide based on the
   recommendation.
   ... This group is free to decide, we don't need to wait for an
   AC report. If someone
   ... objects to it then it is not worth spending more time on
   it. I am happy either way.

   Pierre: What will it change for people on the West Coast. Can
   we be specific because
   ... some of us need to reserve slots in advance.

   Glenn: For 2 days it will change.

   Nigel: It's my action to go and check the DST date changes and
   propose when we should
   ... change our schedules.

   Andreas: In the past year, most of the times I missed the
   meetings where in the US there
   ... was DST.

   Pierre: For the past 5 years I have had my early mornings
   disrupted on Thursdays.

   Andreas: Yes, unsociable times are fair to comment on also.
   There were also suggestions
   ... of rotating times.

   Nigel: We can separate the points of switching the basis to UTC
   and the DST switchover dates.
   ... UTC is easier because most people know their local time
   relative to UTC but not other
   ... places' local time relative to UTC.
   ... In terms of DST I need to check the dates and impacts. The
   default would be to make
   ... no change and stick with US DST dates, but it could be that
   it's actually better for some
   ... people in the US if we go early/late for a couple of days a
   year, I need to check.

   Pierre: I'll wait to see what you come up with.

   Nigel: And a reminder about TPAC - it looks to me as though
   quite a few people have
   ... not yet registered, so please do so - it will cost more if
   you do it after 31st July.
   ... In terms of the rest of this meeting, any specific topics
   to cover or AOB?

   Glenn: I'd like to cover TTML2 issue #919.

   Pierre: I'd like to talk a little bit about IMSC 1.1 test
   submission process.
   ... I'm looking for group input on how to make it better.
   ... I also want to schedule my review time for upcoming
   specifications so I'd like to know
   ... the timelines.

   Nigel: The CfC for TTML2 was opened on Tuesday so it is stable
   for review now.

   Glenn: As Nigel pointed out the scope of the review is limited
   to the changes that
   ... Nigel pointed out in the email.

   Pierre: That makes sense.
   ... I was planning to do a diff.

   Glenn: I just finished updating the changes document too, which
   has a new section
   ... on CR2 -> CR3 diffs.

   Pierre: Thank you so much.

   Glenn: That reminds me there's an old section in that changes
   document that allegedly
   ... shows the differences between TTML1 2nd Ed and TTML2 CR1,
   but I think I need to
   ... go back and update it from TTML1 3rd Ed to CR1 and make it
   relatively complete. I'll
   ... probably open an issue on that.

   Nigel: Good point!
   ... In terms of our general publication timeline, Pierre
   requested an overview of our
   ... upcoming publication schedule last week, which I took the
   action for, and then realised
   ... this morning would be better done by Thierry if he can, so
   I'm afraid I bumped that
   ... action along, and I'm sure you haven't had chance to do
   that yet Thierry.

   Thierry: Right, I'll work on that today and tomorrow and send
   the full dates out for
   ... synchronising for Rec.

   Nigel: Thank you.

   <tm> [18]https://ethercalc.org/no163r5i5dxv


     [18] https://ethercalc.org/no163r5i5dxv


   Nigel: Thanks Thierry, I updated that this morning, and it is
   picked up on a batch job
   ... once a day to generate a graph, which I don't have the link
   to. Thierry if you can find that
   ... please send it too.

   [19]Project Management boards and reports

     [19] https://www.w3.org/PM/


   [20]TTWG dashboard

     [20] https://w3c.github.io/spec-dashboard/?34314


TTML1 Actions, Pull requests and Issues

   Nigel: We are just over half way through our CfC to publish
   TTML1 3rd Ed CR2.
   ... We have no TTML1 issues or pull requests marked for the
   agenda.

   Pierre: I'm not aware of anything we need to discuss. The main
   action item is to create
   ... those tests, and I think we're going to get there soon.

   Nigel: Thank you.
   ... Are you in the process of creating them, Pierre?

   Pierre: Yes, and I'll be focussing more on this in the next
   couple of weeks so I'd like to
   ... talk about process for IMSC.

   Nigel: Okay let's talk about that in the IMSC agenda item then.
   ... Just to be clear, are some of the TTML1 tests the same as
   the IMSC tests?

   Pierre: I use imsc.js to generate the results, so yes.
   ... It is the same tool and many of the tests we have already
   done to convince ourselves there
   ... is a problem, so yes.

TTML2 Actions. Pull Requests and Issues

   Nigel: Glenn has requested that we discuss issue 919;

   action-443?

   <trackbot> action-443 -- Glenn Adams to Prepare a document
   showing mapping arib ruby extension features to ttml2 for use
   as a liaison document to arib. -- due 2018-07-05 -- OPEN

   <trackbot>
   [21]https://www.w3.org/AudioVideo/TT/tracker/actions/443


     [21] https://www.w3.org/AudioVideo/TT/tracker/actions/443


   Nigel: I think you said you would do some kind of summary for
   us here Glenn?

   Glenn: Right, I think I can get to that this week.

   Nigel: Great, thank you.

   Glenn: It will be in the form of a summary showing the features
   TTML2 provides related
   ... to Japanese, and feel free to comment, etc.

   Nigel: OK
   ... As mentioned earlier in the call, we have a CfC open for
   TTML2 CR3.

   [22]CfC for TTML2 CR3 request for transition

     [22] https://lists.w3.org/Archives/Public/public-tt/2018Jul/0173.html


Add missing @extent attribute to isd:isd. ttml2#919

   github: [23]https://github.com/w3c/ttml2/issues/919


     [23] https://github.com/w3c/ttml2/issues/919


   Glenn: This issue was to define the extent attribute for use on
   the isd syntax, which at
   ... this point I consider to be new and that it will be refined
   over time. So I have avoided
   ... going too far down the path of defining constraints on
   usage here.
   ... The problem here was that in appendix H of TTML2 we compute
   all of the aspect ratios,
   ... the resolution of the root container region and the
   document coordinate space for
   ... the extent of the root container region. In H.2 the
   resolution computes a resolution in
   ... logical pixels near the beginning of processing, at least
   before any time you need to
   ... make use of width or height of root container region, and
   it stays that way during processing.
   ... If the author does not specify a tts:extent on the root
   container element then the
   ... implementation puts in a value that it wants to use, for
   example the SAR of a related
   ... media object, etc. So it always comes up with a number in
   logical pixels to use there.
   ... That means when other measurements are expressed in the ISD
   after going through
   ... the process of using computed style values those might be
   expressed in pixels and
   ... be encoded as pixels as opposed to rw or rh. They might
   have started out as rw or rh
   ... but the implementation might have expressed them as pixels.
   We have made no
   ... assumptions about the units in the ISD. It may be
   disadvantageous to do early
   ... translation to pixels, for example em, c units etc might be
   in the ISD. In the absence
   ... of an extent attribute that records what the implementation
   chose, then it becomes
   ... difficult to resolve them, or it would be done by the
   receiving end.
   ... Nigel you commented that surely a pixel extent is not
   required to compute rw or rh.
   ... That depends on what you're using them for. Maybe, or maybe
   not. I wanted to comment
   ... on your question there.

   Nigel: Thanks for that, I don't disagree, and I think that a
   lot depends on the processing
   ... model. Either way requiring extent on isd:isd would be
   wrong in general, even though
   ... in some processing contexts it would be needed, so
   constrained by the implementation.
   ... Indeed one approach might be to resolve dimensions into
   canonical units and generate
   ... another ISD document based on an input ISD document, for
   example.

   Glenn: I just want to make sure we're on the same page.

   Nigel: I think we are.

   Glenn: I wanted to mention that the condition attribute may
   also show up in the ISD
   ... for example, consider a case when you can only resolve a
   condition at presentation time,
   ... or it is used at layout time and some parameter changes
   from when the ISD was generated.
   ... In those cases you might have condition show up in the ISD
   and whatever processes the
   ... ISD might have to do further processing on it.

   Nigel: That raises the question of if resolution of condition
   expressions can change the
   ... set of ISDs that can be generated?

   Glenn: Sure, they absolutely can. I think there's a note that
   evaluation of a condition
   ... might change results, and in that case the condition needs
   to be propagated to the next
   ... processing stage, or something to that effect. In other
   words, early resolution of
   ... conditions depends on the application and the semantics of
   the condition expression.
   ... For example the parameter based system allows environment
   defined parameters that
   ... are implementation-dependent.

   Nigel: Right, so if an implementation cannot resolve a
   parameter at ISD formation stage
   ... then it needs to propagate that condition downstream until
   something can resolve it.

   Glenn: Right.

   Pierre: My conclusion is it is really not possible to evaluate
   rw and rh until there is a known
   ... aspect ratio and I've not heard anyone disagreeing with
   that.

   Nigel: Yes

   Glenn: I would amend that to say a known resolution - the
   aspect ratios are an input to
   ... the resolution and the resolution is what is needed to
   compute rw and rh units, as
   ... computed in appendix H.2.
   ... I also put in a note near the end of our CfC editing, in
   one of the other issues,
   ... that reminds users that logical pixels do not have a
   defined shape or size until they
   ... are mapped to display pixels, and I've done a better job of
   defining inline terms that
   ... define logical pixel and display pixel and referring to
   them elsewhere using links. Hopefully
   ... that will help readers.

   SUMMARY: Discussion about dimension resolution in ISDs and
   condition evaluation, no changes needed to the spec resulting
   from this discussion.

TTML2 Implementation Report

   Glenn: I'm back on test suites now, for the next couple of
   months.

   Nigel: Thank you, we had a hiatus there for CR3 preparation
   (and holiday!)

   Glenn: We have just under 2 months so we will have to work
   hard.
   ... If anyone has TTML2 related test materials they would like
   to get in my queue for
   ... processing please send them to me, alert me to them
   however.

   Andreas: A comment regarding the tests. Glenn, last meeting you
   said you would generate
   ... an overview that you thought could be finished by today.

   Glenn: Yes, that was overtaken by events, and is on the top of
   my queue to generate a
   ... spreadsheet and put it up for that purpose, so people can
   see gaps to help out with.
   ... I'll be doing that today and the next few days.

   Andreas: Thank you

IMSC

   Nigel: First thing to note is that we published IMSC 1.1 CR2
   today! Congratulations.

   [24]IMSC 1.1 CR2

     [24] https://www.w3.org/TR/2018/CR-ttml-imsc1.1-20180726/


   Nigel: I think Pierre wants to discuss the process for
   streamlining tests.

   Pierre: I'd like to be able to merge into the IMSC 1.1 branch
   more quickly, and then allow
   ... us all to review together in one foul swoop. I think it
   would be more efficient and would
   ... like the group to comment on that.

   Nigel: How far through are we?

   Pierre: We're nearly done. It really extends the process if I
   have to wait for pull requests
   ... to be merged.

   Glenn: Is merge control turned on on that repo? For example it
   is not turned on on the ttml2 tests repo.
   ... I would go along with Pierre and say take off the merge
   control flag right now and later
   ... on when things get more stable the group can decide to turn
   it on again.

   Pierre: I would be happy with a 1 day review to make sure
   nothing horrible is happening.

   Nigel: The 1 day review doesn't ensure that - it might take 5
   minutes to review, but it's
   ... about when you schedule those reviews, hence the 10 days.

   Andreas: From my side it would be okay to turn off the merge
   constraint for the moment
   ... for the test repo, not for the others, but for that one. 1
   day review would be okay but
   ... not realistic.
   ... I'm sure if there's something to correct issues can still
   be found.

   Pierre: Don't get me wrong, if someone wants to review PRs I
   think we can turn them back on.

   Nigel: What I would propose is that we relax the merge control
   until Pierre you tell us that
   ... the test repo is essentially done and then turn the merge
   control back on.

   Pierre: That works, and by the way the work is happening on a
   branch so there's no
   ... action to take right now. I just don't want anybody to be
   surprised by changing this without discussing it.

   Nigel: thank you.
   ... I think we have consensus to allow the tests to be merged
   quickly on the basis that
   ... when the tests are essentially complete Pierre will tell us
   and we can a) begin a complete
   ... review and b) if necessary switch on merge control.
   ... I guess at some point we'll have a formal pull request into
   the master branch that
   ... we will formally review.

   Pierre: Exactly.

   group: [discussion of tt:image test, resulting in filing
   [25]https://github.com/w3c/imsc-tests/issues/66]

     [25] https://github.com/w3c/imsc-tests/issues/66]

   Pierre: The only tests I'm really looking for input on are for
   rh and rw. There are a lot of
   ... tests that need to be created so I'm looking for
   contributions to that.

   Nigel: I sense this comes to me, so I will schedule some time
   to prepare those.

   Pierre: And Cyril, right!

   Nigel: Yes, good point, I will liaise with Cyril!

IMSC vNext Requirements

   Nigel: This is stable, we should publish it, shouldn't we?

   Pierre: Yes, there are two editor's notes that need to be
   tweaked in the light of CR2 so
   ... I will go ahead and create a pull request for that, then we
   should publish it.

   Nigel: That would a WG Note.

   PROPOSAL: Publish the IMSC vNext Requirements as a WG Note

   Nigel: I'm assuming we'll do a quick pass to check it and
   address those editorial notes
   ... because we'll likely never come back to this document.

   Pierre: The notes are related to the at risk features, so we
   could either
   ... 1. Remove the notes, and then have requirements that are
   ultimately not matched by the final spec
   ... because no implementations are presented, which means they
   probably go to vNext.
   ... 2. Have notes in the requirements noting that they are at
   risk in CR2. The problem there
   ... is that it is pointing to a specific version of the spec
   which is not ideal.

   Nigel: The third approach is to classify them as "really want
   these but can live without them"

   Pierre: It's not clear with shear vs lineShear because there's
   uncertainty, both in terms of
   ... the best implementation and the demand. We could label them
   "at risk", right?

   Nigel: I think for shear and lineShear we need to say "we want
   one of these but we're not
   ... sure which one"

   Pierre: That's what it says now, but not for rw/rh, and for
   that one we might want to mark
   ... it as nice to have but not required, maybe.

   Nigel: Okay, I will propose some wording in a pull request.
   ... I've raised
   [26]https://github.com/w3c/imsc-vnext-reqs/issues/37


     [26] https://github.com/w3c/imsc-vnext-reqs/issues/37


   RESOLUTION: After resolving the open issues marked as IMSC1.1,
   publish the IMSC 1.1 Requirements as a Working Group Note

   Nigel: (checks that there are no objections)

CSS actions

   Pierre: I have not yet raised the issue for support for
   lineShear

   Nigel: There has also been discussion about background drawing:

   [27]Extruding border corners (negative border-radius)

     [27] https://github.com/w3c/csswg-drafts/issues/2811


   Nigel: Raising for interest in the group.

TTML Profile Registry

   Nigel: I added this agenda topic because it feels like we have
   some new profile to add,
   ... or will soon.
   ... For example we have TTML2, IMSC 1.1, and IMSC 1.0.1

   Pierre: It occurs to me the way to address the chicken-and-egg
   is that MPEG will want
   ... to be able to get inspired for the IMSC 1.1 profile
   designator, so I think it's better to do
   ... it early rather than late.

   NIgel: Right, it seems that there are changes for us and for
   others.
   ... This would be a good opportunity to prompt Frans to see if
   there any EBU updates to make.

   [28]TTML Profile Registry ED

     [28] https://w3c.github.io/tt-profile-registry/


   [29]TTML Profile Registry repo issues

     [29] https://github.com/w3c/tt-profile-registry/issues


   Pierre: Also what about Mike's point about content profiles vs
   processor profiles

   Glenn: Where's that?

   Nigel: I can't recall

   Pierre: Me neither, but it should be captured somewhere.

   [30]Consider how to handle Content Profiles vs Processor
   Profiles #38

     [30] https://github.com/w3c/tt-profile-registry/issues/38


   Pierre: It's pretty simple, now we have them defined in TTML2
   the Profile Registry should
   ... mention that.

   Nigel: Yes, I think so.
   ... Formally IANA needs processor profiles, so the question is
   for us whether we want
   ... to add content profiles in addition.
   ... We probably don't really have to, but it might be a good
   idea.

   Glenn: I just created an issue to add TTML2 profiles since they
   are not there right now.

   Nigel: Thank you!
   ... I've added IMSC 1.1 profiles as an issue
   ... And one to update the IMSC 1 refs to IMSC 1.0.1

   Glenn: Does IMSC 1.1 update the profile designator URI?

   Pierre: Yes

   Glenn: OK.

   Nigel: I encourage everyone to have a look at the Profile
   Registry and raise any change
   ... requests as issues on the repo please.

Meeting close

   Nigel: Thank you everyone! We meet again same time next week.
   [adjourns meeting]

Summary of Action Items

Summary of Resolutions

    1. [31]After resolving the open issues marked as IMSC1.1,
       publish the IMSC 1.1 Requirements as a Working Group Note

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [32]scribe.perl version
    1.152 ([33]CVS log)
    $Date: 2018/07/26 16:14:22 $

     [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

     [33] http://dev.w3.org/cvsweb/2002/scribe/







----------------------------

http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

Received on Thursday, 26 July 2018 16:18:00 UTC