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

{minutes} TTWG Meeting 2017-11-30

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Fri, 1 Dec 2017 11:33:41 +0000
To: TTWG <public-tt@w3.org>
Message-ID: <D645EC4F.4F5BB%nigel.megitt@bbc.co.uk>
Thanks all for attending the TTWG meeting on 30th November 2017. Minutes can be found at: https://www.w3.org/2017/11/30-tt-minutes.html


Please note that we have tentatively agreed to hold a face to face meeting in the week 8-12 Jan 2018 (precise days to be confirmed) almost certainly in the US West Coast.

In text format:


   [1]W3C

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


                Timed Text Working Group Teleconference

30 Nov 2017

Attendees

   Present
          Nigel, Philippe, Cyril, Andreas, Glenn, Pierre

   Regrets

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [2]Topics
         1. [3]This meeting
         2. [4]TTML Pull Request policy
         3. [5]Next face to face meeting
         4. [6]IMSC 1.1, TTML2, features, namespaces etc
         5. [7]Clarify semantics in absence of begin attribute
            TTML pull 264
         6. [8]Clarify that the computed value of
            tts:lineHeight='normal' is 'normal' ttml1#260
         7. [9]Clarified TAB character presentation semantics
            ttml1#258
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

   trackbot, start meeting

   <scribe> scribe: nigel

This meeting

   Nigel: Today we have 10 minutes on Pull Request policy stuff;
   ... Next face to face meeting
   ... IMSC 1.1, TTML2, features, namespaces etc (Andreas
   requested time, some asked to
   ... defer)

   Andreas: I think it's worthwhile to recap and assess our
   current status and solution options
   ... but am happy to hear other views - if everyone wants to set
   it aside for the moment.

   Pierre: If there are questions to ask today then we can do
   that.

   Cyril: David Ronca did not join because he thought this would
   not be discussed today.
   ... Fine to spend a bit of time to answer questions.

   Nigel: Half an hour feels like too much but let's cover it and
   see how we go.
   ... Other agenda topics: TTML2 vs TTML1 and ttp:version,
   ... Pull Requests - there are lots open, on various repos.
   ... And I'd like to confirm if we are going to remove HTMLCue
   proposal from the agenda.
   ... Any other business or points to make sure we cover today?

   <inserted> Andreas: I also asked to discuss the TTML2
   publication timeline and deadlines for publication.

   group: [no others]

TTML Pull Request policy

   Nigel: The main thing to discuss is the permissions on repos.
   ... Right now, on all 11 of our repos, changes to the default
   branch can only be made by
   ... merging pull requests, and pull requests can only be merged
   if there is at least one
   ... approval.

   Philippe: This is the direction we want to go in in W3C. As I
   said at TPAC, we want to be
   ... able to avoid the Editor's being bottlenecks and also
   enable more of the community to
   ... contribute to specifications. Pull Requests do this. Plus
   it is easier to get support for
   ... Pull Requests going directly into GitHub. You don't
   necessarily have to know if there is
   ... support. I encourage WG participants to give +1s to pull
   requests when they are happy
   ... with them. Additionally we are pushing for better testing
   policy as a consequence, that
   ... I also discussed at TPAC. You can also link tests to pull
   requests when you submit them,
   ... so you know how well you are doing in terms of tests.

   <plh>
   [12]https://www.w3.org/2017/Talks/tpac-slides/plenary-project/#


     [12] https://www.w3.org/2017/Talks/tpac-slides/plenary-project/


   Glenn: As I mentioned, I have no problem with the new policy
   for substantive changes,

   <plh>
   [13]https://www.w3.org/2017/Talks/tpac-slides/plenary-project/#

   editing

     [13] https://www.w3.org/2017/Talks/tpac-slides/plenary-project/#editing


   Glenn: and we've basically been doing something like that
   informally already, though not
   ... controlled by the system. The main issue I have was for
   non-substantive changes, for
   ... example process step changes like what Pierre has done much
   of recently. I hope we
   ... can use that in TTML2 also. It will reduce the need for
   process step commits not related
   ... to changes. However Philippe said he assumed typos could be
   fixed without going through
   ... a PR, however the current system does not permit that. I
   still think it is overkill to impose
   ... this PR approach to every change in the repository. I would
   like a solution for non-substantive
   ... changes to not require pull requests.

   Philippe: Non substantive changes are always to some extent in
   the eye of the beholder.
   ... In my slides I did include both editorial and substantive
   changes as needing PRs.

   Glenn: I proposed an approach that would allow any member to
   label an issue as substantive
   ... with only the Chair able to remove that label and to make
   the conditional merge process
   ... make use of that substantive label. That particular
   proposal has not been accepted to see
   ... if it would work or not. I think Pierre dismissed that
   approach. If it is easily done and
   ... doesn't require a lot of config work I think it would be
   worth trying, however if it requires
   ... a lot of work then I would be willing to concede that
   point. It still leaves us with the issue
   ... of dealing with simple typos or process steps like updating
   a README file on the repository,
   ... how can we make those without going through the PR process.

   Nigel: On the first point I don't see any simple permissions to
   base merge ability on labels
   ... so I think it would be a lot of work, unless anyone knows
   otherwise.

   Philippe: The default settings of GitHub allow you to put
   restrictions based on reviews
   ... not based on labels. Right now the TTML2 repo says require
   pull request review before
   ... merging, and those are per branch settings. Another way is
   to require a status check
   ... before merging, which means you have to implement the
   status check based on the
   ... GitHub API. I don't have the resources to do that at the
   moment. We have much higher
   ... priorities in terms of tooling.

   Glenn: I wonder if other groups would have the same request or
   not.

   Philippe: It's the first time I'm hearing it.

   Glenn: I'm willing to conceded the issue on the label based
   approach.

   Nigel: My proposal is to fast track editorial changes with
   initially me and if not then Thierry
   ... rapidly approving editorial pull requests and confirming
   that they are editorial.

   Andreas: I want to note that at TPAC everyone except Glenn
   agreed to try the new approach.

   Glenn: To address Andreas's point, as far as I can tell there
   were no minutes taken on the
   ... topic and it was not on the agenda, so there was no
   warning. I don't consider anything
   ... discussed at TPAC as final. However I am willing to go
   along with the process. Since it
   ... would take a non-trivial amount of work to do my proposal
   I'm willing to conceded that.
   ... It seems overkill to me for typos to require pull requests
   and I think it will cause delays.

   Nigel: Thank you, in that case I propose to continue with this
   and if delays are caused then
   ... to return to it.
   ... I believe that the only thing left to do based on Pierre's
   good work on TTML1 is to
   ... allow travis to commit to the gh-pages branch to move the
   build artefacts in there.

   Philippe: We are really moving away from personal access tokens
   because they can be used
   ... to grant full permissions on GitHub. The full solution is
   just to deploy an SSH key which
   ... I'm willing to do.

   Pierre: It also requires maintaining a custom script.

   Philippe: They don't change very often.

   Pierre: If someone wants to fix the bugs that's fine with me.

   Philippe: Sure, I'm happy to do that. Doing the push back to
   github using SSH key is the
   ... easy part when the build has been done. I have done it many
   times.

   Nigel: Please could you do that for TTML1 Philippe?

   Pierre: There are a bunch of pull requests waiting for that
   before they can be merged.

   Philippe: Yes, I will.

   Nigel: Thank you.

   [14]Issue 271 for Philippe to make those changes

     [14] https://github.com/w3c/ttml1/issues/271


   Nigel: Does it make sense to do that on the TTML2 repo at the
   same time?

   Glenn: It hasn't been proven so I want to wait until it works
   on TTML1.

   Philippe: I can still deploy the SSH key so that it's ready
   when you want to switch travis on.

   Pierre: Be careful because there's different behaviour on
   master branch and other branch.
   ... Just look at the deploy script and it will be pretty
   obvious.

   Nigel: The only way to open the built HTML is to use something
   like rawgit - I'd be happy
   ... to have other ways of doing that if anyone knows of one.
   Also to post a link to the built
   ... artefact URL for easy viewing.

   Pierre: Ask the editor to post that link.

   Glenn: Question: previously the gh-pages branch was the default
   on both repositories,
   ... and was also the branch that the new PR merge commit policy
   was imposed on. In TTML1
   ... that's been changed to master?

   Nigel: Correct.

   Glenn: I wasn't sure when Philippe was commenting on this
   whether or not that commit
   ... policy can apply to more than one branch?

   Nigel: It's per branch, and both the master and gh-pages are
   protected. The gh-pages
   ... branch gets flattened by the build script and its contents
   are replaced by the build
   ... artefacts based on what's in the master branch.
   ... If you try to merge something into gh-pages then it will
   get overwritten next time a pull
   ... request is merged into master.
   ... So don't try pull requesting into gh-pages.

Next face to face meeting

   Nigel: Thank you for everyone who completed the questionnaire.
   Did anyone have problems
   ... and never manage to complete it?

   Andreas: I didn't complete the questionnaire. I am unsure how
   efficiently we work in our
   ... face to face meetings. It is quite some effort in budget
   and time for all of us and as we
   ... saw in the last meeting when we discussed issues, made
   resolutions, we cannot trust
   ... that they are stable it is hard to justify travel budgets,
   at least at IRT.

   Nigel: The number of times that resolutions have been
   challenged using the decision policy
   ... since the 2016 charter is 1 time. It seems unfair to cast
   that shadow over the whole
   ... thing.

   group: [general desire for meetings to be more efficient]

   [15]Survey results

     [15] https://www.w3.org/2002/09/wbs/34314/early2018ttwgf2fplanning/results


   Nigel: The preferred date and place was 8-10 Jan US West Coast,
   with 10-12 being next best, still US West Coast.

   Glenn: I could also attend an Editor's meeting on the same
   dates if we cannot hold a full meeting.

   Cyril: All the other dates and places except 15-19 Jan are
   possible too.

   Nigel: Yes that's true.

   Glenn: I would also be able to attend in Europe in the week
   8-12 Jan.

   Nigel: I didn't ask that. Any other constraints?

   Pierre: I cannot make it to Europe that week.

   Nigel: Agenda topics - harder to interpret, but it is clear
   that IMSC 1.1 Reqs and Spec, and TTML2 are wanted.
   ... Followed by TTML1 Third Edition, TTML 1.0.1 transition and
   Charter, though.

   Cyril: Can we agree to have a meeting in West Coast 8-10 Jan or
   8-9 or 9-10?

   Nigel: I think so - in terms of meeting efficiency, are there
   any other dependencies?

   Pierre: I'd like to set those dates tentatively and have the
   Chair work with the Editors over
   ... the next 7 days to generate a detailed agenda for that
   meeting, for consideration at
   ... next Thursday's meeting.

   Cyril: I agree, and would add that when the list of issues is
   proposed then people's positions
   ... should be posted a week before the meeting.

   Pierre: It should be clear and up to date, yes.

   Glenn: It's 5-6 weeks ago and I'll be starting full time on
   TTML2 about a week and a half
   ... before the meeting it will be very difficult to pin down
   the issues to discuss this far ahead.

   Pierre: There are some issues we know there are concerns with
   so we should highlight
   ... those next week.

   Glenn: I have no problem with flagging those problem areas,
   maybe I can do that this week.

   Nigel: My schedule will allow me to work on this on Tuesday so
   if the Editors could submit
   ... those main issues to me by Tuesday then I can generate a
   strawman proposal for the
   ... face to face agenda in time for Thursday.

   Glenn: Please let me or Nigel or the group know if there are
   any particular issues that would
   ... need face to face discussion.

   Nigel: +1
   ... Any other proposals for efficiency?

   Pierre: Obviously we need quorum - if critical members cannot
   attend then it would not
   ... be a great meeting.

   Nigel: Fair enough - I should reach out to the people who have
   not responded to the survey.

IMSC 1.1, TTML2, features, namespaces etc

   Andreas: Maybe we have different views on how critical this is.
   I see these as really critical
   ... and serious blockers for both TTML2 and IMSC 1.1
   standardisation activities. Therefore
   ... it is important to spend some time on it, and to reassess
   the situation. At the moment
   ... I see that we are completely blocked but if we do not
   resolve these issues then possibly
   ... none of the specs go live. We may not come to agreement
   today. However it is worth
   ... reevaluating and maybe restating positions.
   ... As I see, Netflix has objected to the decisions we would
   have had, from TPAC, which
   ... was to leave IMSC extensions as is and not include them in
   TTML2 at all. From the
   ... thread I see that Glenn objects to including in TTML2 any
   vocabulary in namespaces
   ... not defined in TTML2.
   ... I made it clear that IRT objects to Netflix's proposal of
   redefining existing extension attributes
   ... and redefining them in a new namespace, even if the old
   attributes continue. This is
   ... quite blocking from my side. From the thread I got no
   opinion from BBC, acknowledging
   ... that you are also chairing this, so the BBC perspective
   would be interesting.
   ... Mike Dolan who did not attend the F2F was also present on
   the thread and I'd like to know
   ... his views.

   Glenn: To reiterate where we are on TTML2 at least, we
   currently have 3 attributes that
   ... have been defined, ttp:activeArea, tts:fillLineGap and
   ttp:displayAspectRatio. Those are
   ... already accepted in TTML2 from the most recent WG and the
   actions to put those in were
   ... partly driven by the London F2F discussions. Right now
   there are no definitions of
   ... multiRowAlign or linePadding in TTML2. At one point we
   hoped to use other mechanisms
   ... like padding on inline blocks to accommodate that but we've
   discovered issues with those.
   ... Other than the Netflix proposal to add an equivalent of
   multiRowAlign and linePadding
   ... there's nothing in TTML2 to support that functionality. If
   it were only included in IMSC 1.1
   ... that would be a potential exception to the desire to be a
   subset of TTML2.

   Nigel: From a BBC perspective the point that we got to at the
   end of TPAC was a reasonable state to get to.

   <glenn> SKYNAV has no objection to the BBC approach.

   Nigel: In particular I think the practical concerns are
   important and understanding the
   ... onward journey for industry and the community, of how to
   transition to a cleaner spec,
   ... is really important. So I think that IMSC 1.1 does not have
   to be a clean subset of TTML2,
   ... rather that should be reserved for a future IMSC2, and that
   we should make sure that
   ... the way we incorporate functionality to meet the
   requirements of the IMSC extensions
   ... into a future version of TTML is compatible with whatever
   CSS approach is decided upon,
   ... assuming that some way to meet the captions requirements we
   presented is achieved
   ... in CSS.

   Glenn: To add more, the idea that we help the CSS WG to turn
   the crank and come up with
   ... solutions would be a good idea, and make people less
   uncomfortable than they are with
   ... our approach of forging ahead. Also, if it is a matter of
   incorporating a foreign namespace
   ... into TTML core vs allowing IMSC 1.1 not to be a pure subset
   I'm for the latter. I'm not

   s/I'm not

   s|s//|

   Glenn: Is Netflix using multiRowAlign or linePadding?

   Cyril: No we are not

   Glenn: My understanding of the priorities for IMSC 1.1 is to
   get Japanese language support
   ... in place, and multiRowAlign and linePadding are not needed
   to do that.
   ... Perhaps that part of IMSC 1.1 does not need to be a full
   subset of TTML2.
   ... Then we can continue to work with CSS WG to build the
   features in, and bring them
   ... into TTML later, maybe not in TTML2.
   ... I think we should explore the option of IMSC 1.1 not being
   a pure subset of TTML2.

   Cyril: That's not been Netflix's position for a while.

   Glenn: I understand, but it's worth considering that option as
   a way forward out of this impasse.

   Cyril: The proposal we made has generated two pieces of
   feedback that are interesting to study further.
   ... 1. The way it would work if you had 2 attributes, one in
   IMSC 1.1 namespace, the other in TTML namespace,
   ... especially in terms of inheritance etc. so I'm willing to
   look at that.
   ... 2. How does it work with EBU to incorporate EBU's text into
   a W3C spec.?
   ... I will investigate both of those and come up with
   proposals.

   Andreas: You also took into account the IRT objection?

   Cyril: Yes but as far as I understood there is no technical
   aspect of it. For example one
   ... concern you raised is about the timeline, there's nothing I
   can do about that.

   Andreas: No, there's a really technical issue - if
   implementations have already implemented
   ... something how would they deal with the same thing in
   another namespace.

   Cyril: That's the first point.

   Andreas: Your view of what is technical or not may not be the
   same as ours.

   Nigel: I see actions for Cyril to discuss this further with
   Netflix and also EBU has asked for
   ... some time.

Clarify semantics in absence of begin attribute TTML pull 264

   [16]https://github.com/w3c/ttml1/pull/264


     [16] https://github.com/w3c/ttml1/pull/264


   Pierre: Glenn has requested some changes.

   <pal>
   [17]https://github.com/w3c/ttml1/pull/264#discussion_r152838603


     [17] https://github.com/w3c/ttml1/pull/264#discussion_r152838603


   Pierre: I didn't understand the changes you requested Glenn

   Glenn: This is about the content of an informative note.

   Pierre: The issue raised was the behaviour in the absence of a
   begin, which we should
   ... make sure we address.

   Glenn: The decision is whether to try to paraphrase SMIL, which
   I don't like doing unless
   ... there's an ambiguity. You're basically paraphrasing
   normative text.

   Pierre: This is a note to point people to the particular part
   of SMIL.

   Cyril: Pierre's proposal removes the paraphrase and addresses
   your comment.

   Glenn: I see, I'm happy with that proposed change from 7 days
   ago [marks on GitHub]

Clarify that the computed value of tts:lineHeight='normal' is
'normal' ttml1#260

   [18]https://github.com/w3c/ttml1/pull/260


     [18] https://github.com/w3c/ttml1/pull/260


   Pierre: There's consensus on the outcome, that the inherited
   value for lineHeight="normal"
   ... is the specified value.
   ... My first take was to introduce "used value" which as Nigel
   pointed out has some drawbacks.
   ... When I dug deeper into the inheritance in TTML1 and the
   prose specifically says that only
   ... the computed value of relative values is inherited, so as
   long as it is clear that tts:lineHeight="normal"
   ... is not a relative value so the used value is the specified
   value and we don't need to change
   ... the algorithm.

   Glenn: In TTML2 we have begun to introduce special inheritance
   semantics where something
   ... out of the ordinary is required, for example on fontSize we
   point out that it is resolved
   ... in respect to the parent's computed value. I would prefer
   an approach like that. The
   ... overall goal we're in complete agreement on. The only
   quibble is how to go about saying
   ... it in a way that is unambiguous and readily understood.
   ... I am still not completely comfortable with how you did that
   so I would like to see
   ... some improvements so I will generate a replacement proposal
   and suggest something
   ... that we can discuss further.

   Pierre: [see ยง8.4.4.3 in TTML1 Second Edition]
   ... Step 4 applies. This is the step that replaces style
   properties with their computed
   ... values for inheritance purposes.
   ... Here, as long as the value type of P is not relative, my
   read of the algorithm is that the
   ... value in CSS(E) is not replaced, but is kept as is. For
   example fontWeight="bold" etc.
   ... I think all that we need to do is clarify that
   lineHeight="normal" is not a relative value.

   Glenn: I understand your reasoning now.

   Pierre: I think part of the confusion is that "Computed Style
   Set" in fact contains some
   ... uncomputed styles, but once that is clarified we just need
   to add a note both in the
   ... algorithm and in lineHeight to emphasise that normal is not
   a relative value.

   Cyril: Just to clarify - is the inheritance mechanism the same
   as CSS?

   Pierre: it's different because XSL makes some modifications to
   it. I've never compared the
   ... XSL inheritance mechanism to TTML1 so I'm not sure if there
   are further changes.

   Glenn: CSS has precedence rules, multiple stylesheets etc.

   Pierre: There's an explicit exception made in CSS 2.1 and XSL
   for line-height normal, to
   ... say that the specified value is inherited.

   Glenn: I'd like to be able to propose a slight tweak of the
   language you proposed while
   ... maintaining the nature of it. I need to think about the
   language so I'll do it offline, by
   ... the end of this week.
   ... It was useful to discuss this because now I understand what
   Pierre was trying to do,
   ... and I don't disagree with the approach.

Clarified TAB character presentation semantics ttml1#258

   [19]https://github.com/w3c/ttml1/pull/258


     [19] https://github.com/w3c/ttml1/pull/258


   Glenn: There was a difference in understanding between Pierre
   and I on what the behaviour
   ... is as currently defined in XSL, CSS and TTML. I had removed
   a portion of his clarification
   ... which I think is not factually correct, which is the text
   about tab not collapsed. The current
   ... XML and TTML behaviour is that tab is collapsed in
   non-line-initial position but that
   ... there is some ambiguity about line-initial tabs. It is not
   really clear. I tried to get clarity
   ... from the XSL-FO working group but got no response. I think
   we're on our own to try
   ... to address this. I proposed a slight change where we would
   normatively say that it may

   <pal>
   [20]https://github.com/w3c/ttml1/issues/235#issue-218675902


     [20] https://github.com/w3c/ttml1/issues/235#issue-218675902


   Glenn: be treated as a single space character but did not
   mandate that it must be, in that context
   ... and add a note that it is not recommended to use it because
   of the lack of fixedness.
   ... Nigel then suggested we should just go ahead and mandate
   collapsing behaviour to be
   ... consistent with TTML2 and also CSS 2.1 semantics. I'm okay
   with doing that.

   Pierre: I pasted Glenn's original analysis that concludes that
   in fact the tab character is
   ... not collapsed. My read of the normative references is
   pretty unambiguous that line initial
   ... TAB characters are not collapsed.

   Pierre and Glenn: [some discussion]

   Pierre: My proposal is to be very vague and point out the lack
   of presentation characteristics
   ... mandated for the TAB character, but it could generate a
   glyph area, so just don't use it.

   Glenn: I would agree with that and only that, but you had an
   additional bit.
   ... If you take out the sentence "Furthermore .. glyph area"
   then I'd be happy with that.

   Pierre: It's important to say it can generate a glyph area.

   Glenn: But you said the tab character is not collapsed.

   Pierre: How about: "Furthermore, the TAB character can generate
   a glyph area." for the second
   ... sentence?

   Glenn: I can go with that.

   Pierre: I think it's going to far to mandate a collapse.

   <pal>
   [21]https://github.com/w3c/ttml1/pull/258/files#r154138166


     [21] https://github.com/w3c/ttml1/pull/258/files#r154138166


Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [22]scribe.perl version
    1.152 ([23]CVS log)
    $Date: 2017/11/30 18:25:27 $

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

     [23] 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 Friday, 1 December 2017 11:34:11 UTC

This archive was generated by hypermail 2.3.1 : Friday, 1 December 2017 11:34:12 UTC