See also: IRC log
<scribe> scribe: nigel
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]
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.
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> 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.
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.
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> 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.
github: 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.
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.
github: 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.
github: 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.
github: 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.
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]