- 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