- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 2 Aug 2018 16:59:15 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D788F6B2.63363%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2018/08/02-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
02 Aug 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/08/02-tt-irc
Attendees
Present
Nigel, Pierre, Thierry, Glenn, Cyril, Andreas
Regrets
None
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]DST date changes
3. [6]Publication timings
4. [7]TTML1
5. [8]TTML2
6. [9]Change resolved computed value to used value
(#959). ttml2#960
7. [10]TTML2 pull requests
8. [11]Improve non-negative-real interoperability (#943).
ttml2#944
9. [12]Remove application of tts:rubyPosition to ruby
annotation text. ttml2#945
10. [13]The set element is included in [resolve computed
styles]. ttml2#950
11. [14]Meeting Close
* [15]Summary of Action Items
* [16]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: Hi everyone, today we have future meetings DST change,
publication timings,
... and the usual run through our documents' issues and pull
requests as needed.
... Any particular points to cover or other business?
group: [no aob]
DST date changes
Nigel: As promised I looked at the upcoming DST change to see
what impact it could have
... on us, and put 3 choices into the agenda.
... [iterates through choices in the agenda]
... 1st November: Cancel/1500 UTC/1400 UTC
... 8th November onwards: 1500 UTC
... Any votes for any of those three options at this stage?
Glenn: Cancel on the 1st
Andreas: +1
Pierre: Just for the record, this UTC thing seems a lot of
work. What I was not happy with
... was the meeting being officially moved to UTC at a set time
for the entire year, which
... seemed a detriment to everyone. Merely changing the
reference point from Boston to UTC
... is fine with me. If we realise we need a meeting after
TPAC, we can schedule it otherwise
... for now we can just not have it.
Cyril: I'm fine with cancelling it.
Glenn: Presumably we will not meet on the 25th since we are
meeting on the 22/23 at TPAC?
Nigel: Correct
Thierry: I'm fine with cancelling also.
Nigel: We have consensus to cancel the 1st November meeting, so
let's do that.
... Any objections to moving to 1500 UTC from the 8th November
onwards?
... (that's the same time as normal for us)
group: [no objections]
Nigel: Okay, that's what we'll do.
Glenn: Starting now or on the 8th Nov?
Nigel: It'll stay at this time in UTC until end of October then
I'll switch to 1500 UTC beginning on the 8th Nov.
Publication timings
Nigel: Thank you Thierry for preparing the detailed spreadsheet
and circulating it.
... The main point for us to note and consider action on is
that we will need a WG decision to
... transition to PR, and this will be subject to the Decision
Policy in our Charter, which Plh's
... tool did not take into account. This could mean a
publication date for TTML1 Rec of 8th Nov
... and for TTML2 Rec of 13th Nov, but we would get IMSC 1.1
Rec out on 30th Oct.
... The questions are: is that okay? and if not, what can we do
about it?
Glenn: Obviously we do the CfC 2 weeks before the scheduled PR
date of 25 Sep just like
... we're doing with all the CRs, so why do anything different?
Nigel: The issue is that we would be beginning the decision
review period before the end
... of the CR deadline for comments. So comments could come in
after the CfC begins.
... Then resolving those could add some further delay
Glenn: The 6th Sep is the deadline for comments on CR3 as
published. Where does 11 Sep come from?
Nigel: I didn't notice that.
Glenn: The schedule is based on publication of TTML2 CR3 on
August 9.
Thierry: That's not possible.
... If the end of the CfC is on the 7th then I have to send the
transition request that day, then
... it takes a week from 7th August until publication. After
7th August I need Director's approval,
... send the announcement to the comm team, request publication
from the webmaster,
... that takes a week.
Glenn: In the previous CR we began the previous transition
prior to the end of the CfC.
Thierry: That was a real mess and the Director was unhappy and
I got complaints. I don't
... want to do that again.
Glenn: That's new information.
Thierry: Last time we kept changing the spec after requesting
the transition. The spec was
... a moving target and the Director could not understand what
was going on. We don't
... want to go through that again.
... I didn't invent these dates, they came from Philippe's
tool.
Glenn: I understand, and the August 9 date also came from that
tool.
... I recall Nigel asking you previously if we could do August
9 and you said it was fine, so
... this is new.
Nigel: I'd have to check my notes, I'm not sure.
Thierry: I don't understand how we could have got to 9th unless
we have a shorter CfC.
Glenn: Is that possible?
Nigel: I don't see how it would be, it's in the Charter.
Thierry: Philippe's tool can't take into account CfC periods
because they vary across groups.
... If we all agree that we can shorten the CfC I'm fine with
that, if everyone from the WG is
... okay, e.g. we could make it 3 days.
... It started on July 24, so we're 9 days in.
Glenn: I'm prepared to suggest that we terminate the CfC early
if the WG is acceptable with that.
... We have some pull requests approved for merging, I would
make it contingent on doing
... those merges.
Nigel: I don't think I can accept that, midway through this
CfC, though we could consider
... it for a future one. For example we could make a resolution
ahead of time to reduce the
... CfC review period for PR transition on the basis that we
will make no substantive changes,
... because that decision would be reviewable by the entire
group. If we change this current
... CfC period now mid-flight, say in this meeting, then nobody
absent from the meeting,
... can comment, and we don't know if they are going to come up
with something unexpected.
Thierry: Another solution is a bit hairy but what we could do
is I could try sending a
... transition request for tomorrow based on a stable document
but that document would
... be considered to be frozen. If we need to do more edits
then I would cancel the transition
... request and we would have to issue another one later.
Glenn: We had originally tried to go to Rec for all 3 specs on
the same day, so if we go with
... this timeline then we would have to go through that
decision.
... So far we have only made editorial changes since we began
the CfC. One substantive
... change was made 9 days ago.
Nigel: There are 2 substantive pull requests open at the
moment.
Glenn: We don't have to merge those.
Pierre: How many weeks difference are we talking about?
Nigel: 2 weeks, to Tuesday 13th Nov.
Thierry: We don't have to publish them all on the same day.
Nigel: We agreed last week to try to publish them all on the
same day.
Glenn: Right, so we might need to delay the others.
... There is one substantive pull request, the other has a
suggestion to push it out to 2nd Ed
... which I agree with.
... The other is #958
Nigel: Yes, we already agreed to do that.
Glenn: We could defer that until 2nd Ed.
Nigel: If Thierry's request is a stable version for tomorrow
then we could do that?
Glenn: I could do that.
Pierre: The timeline is fine though. For all intents and
purposes, a PR published on 4 Oct is
... fine, for anyone who wants to reference a stable spec.
Glenn: We had already agreed to publish Recs for all three on
the same date.
Pierre: I'm not saying that, the schedule that Thierry proposes
looks fine to me.
Glenn: We agreed to publish on the same day.
Pierre: Yes but what does it matter?
Glenn: We can change our mind, that's fine with me.
Pierre: We didn't make a hard decision.
Nigel: We did decide this last week but now we have better
information. I've not heard any
... primary reason why we need the same date, the only thing we
would lose is publicity impact.
Pierre: I've never seen a timeline like this before.
... (the clearest so far)
Nigel: This is the best I've seen.
Thierry: We can publish the PR on 25th Sep
<glenn>
[17]https://w3c.github.io/spec-releases/milestones/?cr=2018-08-
11&noFPWD=true
[17] https://w3c.github.io/spec-releases/milestones/?cr=2018-08-11&noFPWD=true
Nigel: Hang on, I'm looking at the "with PR CfC" sheet which
shows 4 Oct
Glenn: According to plh's tool ...
Nigel: [interrupts] This is going in too many directions. If we
don't have any objections to
... publishing PR on 4 Oct and Rec on 13 Nov then that's what
we should do.
... [group discussion, some confusion caused by looking at
Plh's tool and Thierry's workbook]
Glenn: I have no objection to pushing Rec out to 13th Nov.
... I'll have to change the dates in the current CR doc but
that should be no problem.
Nigel: The end of the CfC is 7th August, we have time to
process the current CfC comments.
... I just want to check if anyone else has any problems with
the 13 Nov Rec date?
... So far Glenn and Pierre have said it's okay, and it is with
me too.
Pierre: Unless TTWG issues additional delay, you're confident
those dates can be met, correct?
Thierry: This is a very tight schedule, the shortest we can
get.
Pierre: Understood.
Cyril: It's realistic, right?
Thierry: It's do-able but very tight.
Pierre: I like the idea of now having a really concrete
schedule and I think it's a lot better
... than what we had before and only 2 weeks later than the
self-imposed deadline. I'm happy.
Nigel: And no problems with MPEG?
Cyril: hmm
Pierre: To be transparent, I'm not sure Oct 30 helps with MPEG,
their meeting will be over
... by then. What I think really helps is having a PR ready
before their meeting and being
... able to provide a liaison regarding that.
... I think that's really important to me. It would have been
great to have had a Rec before but
... we're not going to hit that. The meeting is mid-Oct.
Cyril: 8-12.
Thierry: The PR would be the 4th.
Nigel: Any deadline for incoming liaisons at MPEG?
Cyril: No, they can be very close to the meeting.
Pierre: Also SMPTE, their following meeting is in November.
Being informed of a Rec date
... well before the end of the year would really help
organisations to plan.
... My personal opinion is I would rather have a good realistic
schedule than something
... more aggressive with a high risk of not happening.
Nigel: I'm happy with this plan to, in Thierry's "with CfC"
spreadsheet.
... If we need to co-time spec publications and make IMSC1.1 a
bit later that's okay.
Cyril: I agree with that but I'm not sure that completing the
test suite for IMSC1.1 by Sep 10
... is feasible.
Glenn: W3M will hold up IMSC1.1 Rec until TTML2 Rec because it
has a normative reference.
Nigel: I'm not sure about that, but maybe they should.
Glenn: Even if the AC has signed off, generally W3M has held up
Rec publishing until the
... normative rec has become solid, especially W3 specs.
Nigel: I think they regard PR as solid now.
Thierry: Yes
Cyril: I think the timeline for IMSC1.1 is going to change
anyway because the implementation
... report will be later.
Nigel: It's a good point, the upshot of delaying IMSC 1.1 to
sync with TTML2 would be
... 17 more days to do the test suite and implementation
report.
Cyril: I think that would be fine. I think what matters to MPEG
is PR not Rec.
Glenn: We were talking a moment ago about going out the door
with IMSC 1.1 before
... TTML2 goes to Rec. If it did that it would have to refer to
the PR not the Rec. You can't
... forward the reference.
Pierre: My assumption is it would simply be held. I don't know
what date W3M would pick.
Glenn: That's my assumption.
Nigel: Does anyone have a problem if that happens?
Pierre: I don't have a problem, and also in the scenario that
we have to hold back IMSC1.1
... PR because not all tests are available, I'm happy with that
as well.
Nigel: Good we effectively have agreement to target publication
of TTML2 and IMSC 1.1 on Nov 13.
Thierry: Should I update the dates on the spreadsheet so they
match?
Nigel: I don't think we need to, as a planning tool this is
fine as is. The process is the same
... for TTML2 and IMSC 1.1 so we can see the range of
acceptable dates right now.
Thierry: I propose to publish this on the wiki, for ease of
reference.
Nigel: Sounds good to me, yes please.
TTML1
Nigel: The CfC ended and I asked Thierry to request transition
to CR2, and Thierry did that.
Thierry: Yes, that was done yesterday.
Nigel: Thank you!
... We don't have any issues to deal with here.
... The next thing is the test suite to demonstrate the changed
features since 2nd Ed.
... As far as I know those tests don't exist at the moment?
Pierre: No, but hopefully after today I'll be very close to
being done with the IMSC1.1 tests
... so I'll be able to move on to that.
Nigel: Great, thank you.
... We haven't any more on the agenda for TTML1.
TTML2
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>
[18]https://www.w3.org/AudioVideo/TT/tracker/actions/443
[18] https://www.w3.org/AudioVideo/TT/tracker/actions/443
Glenn: Yes, push that on another week please.
Nigel: Ok
... We have some agenda issues.
Glenn: Before we get to specific issues maybe I can ask you to
deal with the editorial pull
... requests that are open right now?
Nigel: On the call now?
Glenn: Yes, first I need approval to merge early on the
approved pull requests.
... There were a couple that Nigel didn't take a look at yet
(or anyone else) that we can do
... quickly now, #959 and #963.
... and #961.
Nigel: Those are the issues.
Glenn: Okay the pull requests are #960, #962 and #964.
Change resolved computed value to used value (#959). ttml2#960
github: [19]https://github.com/w3c/ttml2/pull/960
[19] https://github.com/w3c/ttml2/pull/960
Glenn: This came from a comment from Pierre that we should
probably just go with the
... terminology in CSS of used value, in place of "resolved
computed value" and this introduces
... a definition to accomplish this. It is an editorial change.
Pierre: I think you had convinced me no change was necessary so
this came as a surprise!
Glenn: I agree, it helps avoid confusion to go with something
CSS understands when we talk
... to other groups. I note that XSL-FO did not use "used
value" because the earlier version
... of CSS 2 did not have that term in. Since then the CSS
folks added "used value".
Pierre: Stupid question, if these are editorial, we can do them
between CR and PR, right?
... Shouldn't we focus on the substantive issues?
Glenn: I'd like to knock them off now if we can agree to it.
Pierre: Just prioritising the time.
Nigel: I'd like to propose that we continue to review the
editorial pull requests offline
... and merge them early.
Glenn: Okay, we can do that, as long as I have approval to
merge the PRs between now
... and the end of the CfC.
TTML2 pull requests
Nigel: We should prioritise (in descending order):
... * Pull Requests that are substantive
... * Pull requests relating to the review scope
... * Pull requests not relating to the review scope.
Glenn: Can I merge the approved pull requests early?
Nigel: Yes, noting that based on that prioritisation some might
get deferred if they don't
... get an approval.
Glenn: Yes. I assume that.
Nigel: Just checking in, is everyone happy with that? Any
objections to merging approved
... pull requests early in the CfC period?
Cyril: No
Glenn: So far we have not merged any substantive pull requests.
Nigel: We won't be issuing the transition request until we have
stability at the end of the CfC period.
... No objections so please go ahead and merge approved pull
requests early.
Glenn: On #958 if we merge that then there will be changes
during the CfC.
Thierry: The Director wants a stabilised document after
transition request.
Nigel: This is a non-issue.
Glenn: I thought Thierry said the Director had a problem with
changes during CfC, if it's
... about instability during the transition request, then
that's okay, got it.
Improve non-negative-real interoperability (#943). ttml2#944
github: [20]https://github.com/w3c/ttml2/pull/944
[20] https://github.com/w3c/ttml2/pull/944
Glenn: I have no problem deferring this to 2nd Ed, and note
that if we do that then we
... need to approve #956 in the meantime.
Nigel: This is about making the value "0." that is illegal in
TTML1 legal by adopting xs:decimal.
... I think we should do nothing and nobody will care.
Glenn: If we don't do it then we have to do #956.
Nigel: Any other views on this?
group: silence
Glenn: The reason #956 is important is that if we use
xs:decimal in our schema then all
... the tools that take the schema will make it impossible to
tell if 0. was used because the
... resulting value will be a double floating point number
whose original lexical value will
... be lost. Changing it to a string will pass that through to
implementations.
Nigel: And the XSD is not normative and it is not a requirement
for implementers to use it.
Glenn: Sure.
Nigel: There are no comments on this.
Glenn: I will move this issue to TTML.next.
Nigel: OK
SUMMARY: Close pull request and mark as TTML.next.
Remove application of tts:rubyPosition to ruby annotation text.
ttml2#945
github: [21]https://github.com/w3c/ttml2/issues/945
[21] https://github.com/w3c/ttml2/issues/945
Pierre: This is simply achieving better alignment with CSS. CSS
does not allow
... ruby-position on text, only on text-container. My
suggestion is to follow the same route.
Nigel: I see Glenn's comment from 2 days ago that Pierre's
suggestion is probably workable.
Glenn: I have a problem with this. It will require a
substantive change to back out the
... language that defines in what way ruby position is applied
to text content. I have to
... dispute what was just said by Pierre. It does not disallow
specifying it on ruby text, it
... just doesn't say that it applies to it. If we don't allow
the currently specified semantics
... to apply in the way that it is defined that means we have
to substitute some other
... normative text that says the ruby position that would be
inherited from the container
... (tts:ruby="container") also applies to the implied ruby
text container that is constructed
... during the presentation processing. It's a substantive
change. It is not necessary to make
... any change here because the mapping to HTML5 and CSS is
trivial to accommodate this.
Pierre: It is not.
Glenn: All you have to do is create an explicit ruby text
container.
Pierre: If one already exists that doesn't work.
Glenn: If one already exists then it is an error to put another
one on.
Pierre: Sure but that means you cannot always add a ruby
position. I'm trying to avoid
... exceptions and make things more robust.
... A ruby text container is already created anonymously if not
present, so this does not
... change anything.
Glenn: What that means is we have to redefine the semantics to
say that the inheritance
... explicitly applies to the ruby text container. I do not
agree with this change at this point.
... I'm willing to look again in 2nd Ed.
Pierre: I would accept putting this feature as at risk.
Alignment with CSS is important.
Glenn: I object.
... To putting it at risk - it is already implemented in two
implementations.
Pierre: Which we've seen no tests for. I'd rather not get there
Glenn. What I'd rather say is
... that we should be aligned with CSS. Half of this section is
dedicated to stating how
... it is aligned with HTML and CSS.
Glenn: We have never made syntactic alignment a requirement,
always functional alignment.
Pierre: It's confusing for people.
Andreas: I'm not really into this issue in itself and have not
reviewed this ruby application
... but I would heavily support Pierre's approach to align with
CSS as much as possible.
... From the last discussion we had at TPAC with the CSS WG we
really would like to bring
... TTML closer to CSS functional of course but also
syntactically if possible would be better.
... There are a lot of reasons why we are not aligned with CSS
but that is all history now.
... The direction is that we are getting closer to CSS and
after TTML2 with TTML3 I do not
... know how it will go on but possibly there could be a major
change. So in general I support
... what Pierre said.
Glenn: The last published CR of CSS ruby level 1 was in 2014.
The current text that
... Pierre is using is an ED that has no status. There is no
certainty about when we are going
... to see a CSS Ruby layout level 1 Rec. I don't think we can
talk about alignment with CSS
... in any real way here. Also Pierre has pointed out a number
of times that the only
... implementation is in Firefox anyway so one wonders if, even
if they solidified the spec now
... could they achieve closure without any other
implementations. The risk is high and there
... are a number of unresolved issues in CSS.
Pierre: We should take the conservative approach.
Glenn: IRT (Stefan) reviewed the current language and did not
point out any misalignment.
Pierre: This came from implementation work.
Andreas: The message from CSS was to come if there is a
requirement not in CSS. If there
... is a possibility to step back and say we have a requirement
not in CSS right now then
... we should take it there first and see how it gets on.
Glenn: Good suggestion.
Cyril: If you want TTML2 published in 2025 you should do that.
We should favour stability
... at this point, in CR3. Alignment with CSS is fine but
should not jeopardise TTML2 publication.
... In this case it does not look like a bug in the spec, but a
problem of alignment to an ED
... that is not stable.
Pierre: You're trading risk of implementation for risk of
stability.
Cyril: It is exactly how the process works, to trade spec risk
for implementation risk. Why
... don't we follow the process?
Pierre: At this point imsc.js does not implement it correctly
because of the spec.
Cyril: It is not impossible to fix though. It is too late to
fix [in the spec] now. We have to publish, we have to get it
done.
Pierre: You don't want to remove one word on the spec?
Cyril: yes, now is too late. When it is it going to end?
Glenn: I don't care what Pierre says about implementations.
There are at least two implementations
... with tests already even if they are not visible. This
change requires at least two implementations
... to be changed, so I don't go with that. This issue is out
of scope of the CfC review.
... Substantive changes out of scope here cannot pass muster.
Pierre: If we take this really seriously, no more changes, then
we should make no more
... changes and move on. The time it will take to review all
the other changes, which are
... editorial only in name because they affect substantive
statements, is outweighed by
... the time it takes to fix this. We make a change if it is
worth it.
Glenn: We do not have consensus on whether it is worth it.
Nigel: That is a key point.
... Pierre, is this something that you can live with, to make
no change, given that a path
... has been laid out for how to implement in HTML and CSS,
even if it is not the optimum for you?
Pierre: I will have to check with my sponsors on that.
Nigel: Okay.
SUMMARY: No consensus for a change now.
The set element is included in [resolve computed styles]. ttml2#950
github: [22]https://github.com/w3c/ttml2/issues/950
[22] https://github.com/w3c/ttml2/issues/950
Nigel: [attempts to summarise issue] This is in the review
scope for the CfC.
Glenn: [scribe misses a bit] The CSS of set and animate are
defined as the SSS without
... inheritance or fallback, as documented more thoroughly. It
is very dense logic to follow.
... The upshot is there is no need to exclude set or animate
from the filter set to which
... CSS computation applies. If we did not have it then set and
animate would have no
... CSS applied on them at all but there are other parts of the
spec that want to have that.
... The current wording avoids any substantive issue, the CSS
is equal to the SSS basically.
Nigel: Pierre, does that logic resolve it for you?
Pierre: I have not studied it further.
Glenn: If we pull out set from that list then we would also
pull out animate. At least three
... rules with special semantics for set and animate would have
to be backed out as well.
... It would be very tricky making those changes now for
limited utility. I am willing to
... leave this issue open and give further consideration. I
don't think we can address it in
... TTML2 1st Edition in any case. I don't see a bug here.
Nigel: I think at this stage there is no change proposed and it
will be difficult to make one.
... In order to make the transition request our realistic
options are to defer it or close it.
Glenn: I would prefer to defer it to TTML.next.
Pierre: I think the group needs to decide whether to close it
or not.
... I don't know if I would object to closing it.
Nigel: We need a default action to take here. If it is not
closed and no change is agreed
... by the end of the CfC then I will defer it, so we can move
on with the transition request.
SUMMARY: Issue review to continue; to defer if not resolved by
the end of the CR3 CfC.
Meeting Close
Nigel: We've run out of time for our remaining agenda topics.
We meet again same time next week.
Pierre: I did my CSS action.
Nigel: Please add a comment to the action and then we can close
it.
Pierre: I will do that.
... There's nothing else today for IMSC.
Nigel: Thank you everyone! See you next week [adjourns meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [23]scribe.perl version
1.152 ([24]CVS log)
$Date: 2018/08/02 16:58:03 $
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[24] 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, 2 August 2018 16:59:46 UTC