trackbot, start meeting
<scribe> scribe: nigel
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]
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> 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> 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.
Issue 271 for Philippe to make those changes
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.
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]
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.
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.
https://github.com/w3c/ttml1/pull/264
Pierre: Glenn has requested some changes.
<pal> 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]
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.
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> 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> https://github.com/w3c/ttml1/pull/258/files#r154138166