W3C

Timed Text Working Group Teleconference

05 Apr 2018

See also: IRC log

Attendees

Present
Pierre, Nigel, Philippe, Thierry, Glenn
Regrets
Andreas, Cyril
Chair
Nigel
Scribe
nigel

Contents


<scribe> scribe: nigel

<cyril> regrets from me

This meeting

Nigel: Today we have TTWG Charter, TTML1 3rd Ed CR, a couple of issues on TTML2,
... request to transition IMSC 1.1 to CR, and I think Dave Singer sent something to say he
... wanted to record the resolution to publish WebVTT as CR today.
... Anything else for the agenda?

Thierry: The different version of IMSC 1.0.1 CR + PR plus IMSC 1.1 FPWD were fixed in place
... to have the correct W3C Document licence.

Nigel: Thank you!

<tmichel> [1] IMSC 1.0.1 CR https://www.w3.org/TR/2017/CR-ttml-imsc1.0.1-20170713/

<tmichel> [2] IMSC 1.0.1 PR https://www.w3.org/TR/2018/PR-ttml-imsc1.0.1-20180227/

<tmichel> [2] IMSC 1.1 FPWD https://www.w3.org/TR/2017/WD-ttml-imsc1.1-20171017/

Pierre: There's a pull request on respec.js to fix that bug waiting for your approval Philippe.

group: [nothing else for the agenda]

TTWG Charter

Nigel: I just received an email from Coralie notifying AC and Chairs that the TTWG charter
... has been extended by 2 months until 31 May 2018.

TTML1 3rd edition CR

Nigel: I think the SOTD has been updated.

Pierre: The CR branch is ready to go modulo an update to the publication date.

<tmichel> https://rawgit.com/w3c/ttml1/TTML1-3ED-CR1-build/index.html

Pierre: You can use the head of that branch or I can generate it for whoever needs it.

Nigel: What do we do next to close this off? We made the transition request already, and
... have made the change to the SOTD.

Philippe: You want to proceed to CR before the tests have been written?

Nigel: Yes

Philippe: Then you should reply to the last email to say exactly that.

Nigel: I will do that.
... If he says "yes" then when would the exit date be?

Philippe: If he says yes, you've passed the review period so the document could be published
... on Tuesday.

Thierry: Looking at the SOTD we have added that we need two implementations and have
... linked to the implementation report. Should we emphasise focus only on testing what
... we have added in that edition? The statement seems unclear to me, maybe that the
... implementation will address only the changes made in this edition report.

Pierre: The changes are already listed.

Thierry: I want to emphasise that the focus is restricted.
... Add something like the implementation report will be restricted only to the changes
... introduced in the 3rd edition.

Pierre: Sure, I can write that up.
... I'll do that as soon as possible.

Nigel: If we publish on Tuesday then when is the earliest exit date?

Thierry: We should have at least a month, so May 15th, say.

Philippe: May 29 for the PR, if you send the transition request on May 22. So deadline for

<plh> https://w3c.github.io/spec-releases/milestones/?cr=2018-04-17

Philippe: comments would be May 15.

Nigel: Great, so May 15 is the date to put in the SOTD, thank you.
... Pierre, when you tell me that's fixed in the SOTD then I'll respond re the transition request.

IMSC 1.1

Nigel: We already made a resolution to request transition to CR:

Resolution to request transition to CR

Nigel: That resolution requires us to have resolved the issues open at that time.
... Have they been resolved?

Pierre: All the issues outstanding at that point have been closed and resolved.
... There are 3 issues outstanding on IMSC 1.1. Two are purely editorial and can be safely
... deferred to post-CR, and are related, making a table easier to read.
... There's another issue I found yesterday, and I suspect there will be more. The question
... is do we publish a new WD today or a CR today? I think publishing a CR is a much
... clearer indication of the state of the document so I'd rather go with that and a second CR.
... I'd still recommend proceeding with a CR1.

Nigel: Can we fix the issue in the next week or so?

Pierre: Probably. It's implementation experience.

Nigel: How substantive is it?

Pierre: Pretty minor, but substantive.

tts:position should be allowed on region only imsc#366

Pierre: I don't expect the scope of IMSC 1.1 to change, or major features to be added or removed.

Nigel: Seems like the thing to do is to move to CR on the basis of the resolution we already made.
... Any other views?

Glenn: No objection.

Nigel: In that case I'm going to declare that we have consensus to request transition.
... Thierry, please could you prepare the transition request?

Thierry: Okay.

Nigel: Anything else on IMSC?

Pierre: No, but I'm waiting for respec to be fixed so I can update the document licence.

TTML2

Nigel: We have 3 issues and pull requests marked as Agenda.

Remove @condition from animation, head, layout, resources, and styling elements. ttml2#704

github: https://github.com/w3c/ttml2/issues/704

Nigel: The question here is if there is any use case or requirement for conditionalising the
... tt element itself? I think Glenn and I agree that it is not needed. I just wanted to check if
... there are any other views.

Glenn: Note that condition is still permitted on the body element, so some of the possible
... use cases for conditionalising tt are still possible using that..

Nigel: Just to check, if we put condition on body does that imply that there can be more than
... one body element, and that one must be selected prior to validation? How would that work with an XSD validator?

Glenn: No, there would only be one, and it could merely be excluded or included.

Nigel: Oh I see, harsh, but that works!

Glenn: Can I mark this as discussed and agreed?

Nigel: I think so, yes.

SUMMARY: WG agrees to implement this issue, noting that body element can still be conditionally excluded.

Nigel: I will approve the pull request then.

Animate @calcMode value displace{,d} should read paced. ttml2#699

github: https://github.com/w3c/ttml2/issues/699

Glenn: Apparently we had a discrepancy between the schema and the spec in regard to the
... "paced" value of the calcmode. There was incorrect and incomplete schema support that
... wasn't mentioned in the spec. There was never any discussion or proposal to exclude it
... so my conclusion was that it was not intended to be excluded and it needs to be fixed
... in the schema and added to the spec.
... If it turns out there are insufficient implementations then we could remove it.
... I plan to add a pull request to make the animation features more functionally oriented
... than syntactically oriented. We need one targeting paced and spline modes. That leaves
... two other modes, linear and discrete. Linear is the default, discrete turns it into the same
... as set semantics with multiple entries.
... If you're going to support animate at all you should definitely support linear mode, and
... there's no harm in requiring support for discrete at all since we already have it via set.
... My thinking is that the default feature identifier should translate to mandatory support
... for linear and discrete, however the other two, paced and spline add a fair amount of
... additional complexity and attributes so I think they should have their own feature designators.
... Key times is required by both, and key splines by spline mode only. I plan to open another
... pull request to orient along those latter two.

Nigel: You said non-discussion implied not excluding, but you could just as well say that
... non-discussion meant non-inclusion.

Glenn: It looks like an accidental exclusion not an intentional one.

Nigel: I think we only reviewed the spec in front of us. But let's not dwell on it.
... Anyhow does anyone have any views about introducing paced? It seems like good functionality to me.

group: [no further views]

Glenn: Does anyone object to adding the feature designators for paced and spline?

Nigel: Seems like a good idea to me.

group: [no objections]

Glenn: I've already implemented validation.

RESOLUTION: Add paced calcmode and feature designators for paced and spline calcmodes.

Prioritise loaded fonts when selecting font. ttml2#675

github: https://github.com/w3c/ttml2/issues/675

Glenn: I would be happy to add normative language that documents the semantics that I
... think we want to enforce, which is that the entirety of a font resource, downloaded or not,
... must be available at presentation time to be used or hold that it exists for the purpose of use,
... in terms of evaluating a list of font families that are specified by the author in the fontFamily
... property. Right now XSL and TTML say nothing about what should be done by an
... implementation in terms of loading either locally or remotely available fonts and use
... during the presentation but there is a presentation I think by the authors and implementers
... that if you are going to use a font then it had better be available, or you should move on
... down the list. Right now that behaviour is implementation defined because it is not defined
... in XSL and not really in CSS either.
... The CSS language may have some relevance to incremental redisplay or relayout in browsers.

Nigel: I think that's bypassing the issue though, what happens if the font becomes available
... part way through the presentation?

Glenn: That's implementation dependent.
... Right now there's no backup from the spec. If eventually every implementation uses
... lazy loading, then maybe we could say something in the future about it, but I still think
... it is in the domain of implementation choices and goes down into the details we should
... not be talking about in my opinion. There are a lot of other ways to optimise implementation
... without spec support, for example rendering text to pixels prior to its use.

Nigel: Okay, any other views about this? I think it could impact CSS based renderers like imsc.js.

Pierre: I haven't looked at this at all. Today imsc.js just copied tts:fontFamily to the CSS
... style and lets the CSS implementation do whatever it does. I don't see that changing.
... I've not run into this issue and noone has complained about it so far. My inclination would
... be to leave it as an implementation detail until somebody runs into a problem.
... One option would be to do nothing now but if it comes up then come back to this issue.

Glenn: We can always close it and mark as ttml.next for posterity.

SUMMARY: Take no action for now, mark as ttml.next and close.

github-bot, end topic

IMSC vNext Requirements

Pierre: There's one pull request awaiting your review...

Nigel: Okay I'll look at it.
... Thank you!

Pierre: Similarly #16

Nigel: Ah yes, you're answer https://github.com/w3c/imsc-vnext-reqs/pull/16#discussion_r179027816 seems reasonable.

Pierre: Okay I'll make a clarification change.
... I went back and looked at the Netflix submission on Japanese required features.
... It said only rubyReserve="auto" was required. It seems that this was never really implemented
... in the requirements, so I've asked Cyril to review it. The impact is that at some point
... down the line for IMSC 1.1 we may want to constrain that feature. I don't see that as a
... major issue.

Nigel: There are two ways it could go: either nobody uses the other values, so there's no
... problem applying the constraint, or other values are used, in which case we should not
... impose the additional constraint.

Pierre: To Cyril's point, the risk is that in order to support rubyReserve="auto" you already
... have to support two of the underlying key words.
... Anyway I'm waiting for Cyril's opinion on that.

Nigel: Is that all on IMSC vNext reqs?

IMSC v1.0.1 Rec obsoleting IMSC v1?

Pierre: We have to decide as a group if when v1.0.1 becomes a Rec we obsolete IMSC 1.
... It makes it easier for the W3 team to implement the obsoletion if it is part of the Rec
... transition.
... My recommendation is, because IMSC 1.0.1 is completely compatible with IMSC 1 by design
... and clarifies some IMSC 1 ambiguities then we should obsolete IMSC 1.

PROPOSAL: When publishing IMSC 1.0.1 Rec, mark IMSC 1 as Obsolete

Glenn: Question: I think Superceded is an option as well as Obsoleted. Which do you plan to use?

Thierry: Superceded is replacement of a spec by another, so that's probably the one we should use.
... Obsolete is a spec you don't want people to implement any more.

Nigel: Sounds like Superceded is for us here.

Pierre: Yes I like that better.

PROPOSAL: When publishing IMSC 1.0.1 Rec, mark IMSC 1 as Superseded

Glenn: I think that's what was meant in the first place.

Pierre: I'm reading the Process document...
... I don't think we want anyone to implement IMSC 1 at this point. I think I'd always say
... always use IMSC 1.0.1

Glenn: That means it's superseded. Obsolete means we don't have a substitute for it.

Nigel: The Process says "A Superseded Recommendation is a specification that has been replaced by a newer version that the W3C recommends for new adoption. "

W3C Recommendation description in the Process

RESOLUTION: When publishing IMSC 1.0.1 Rec, mark IMSC 1 as Superseded

Nigel: The WBS for IMSC 1.0.1 has closed, with no votes against. When can we expect a
... transition to Rec to be requested by the Director?

Thierry: I will have to check.

WebVTT

Pierre: Can you share with the WG for the record, as Chair, what the plan is for CR transition? The folks at Movielabs want to know.

Nigel: I'm going to duck that - the Chairing responsibilities split that we have agreed is that
... Dave Singer looks after WebVTT and I look after the TTML-based work, so I can't and don't want
... to speak for him.

Thierry: Are you referring to the pull request about the relation between the CG and the WG?

Pierre: Yes.

Thierry: That statement has been there for years, I have not changed it.

Pierre: I don't dispute that, I'm paying attention now because it's getting to CR.

Nigel: My expectation was that Dave would join today to record the resolution to transition to CR.

Thierry: I guess the deadline for publication has been extended along with the Charter, so
... there's a little bit more time.
... The Charter is under review by W3M and then will go to AC. There's a bit of time there.
... The Charter incorporating or not incorporating WebVTT should be the final version
... submitted to the AC.

Nigel: Ah, I see, that makes sense. If hypothetically we thought that WebVTT is not going
... to be in the next Charter then publishing as a CR would seem perverse, since there would
... be no route out of CR.

Meeting close

Nigel: Next week, I'm on vacation, so unable to Chair. If someone wants to Chair (including
... a Chair of course) then please go ahead.

Pierre: Regrets from me too.

Nigel: Andreas has also sent his regrets.
... Given 3 absentees I think we should cancel next week's meeting, so our next call
... will be on 19th April.
... We haven't much time to decide on a f2f - the proposal is to meet in advance of the IRT
... subtitle symposium on 22nd and 23rd May.

Pierre: I would be reluctant to attend.

Glenn: I also would not be able to attend.

Nigel: Okay then it doesn't make any sense to go ahead with that.

Pierre: I'll be in Berlin w/c July 9, so if we want a F2F in Europe that could be a possibility.
... The weekend before or week after maybe.
... Week of June 18 I'd be in Toronto, if that would help.

Nigel: Half way could work, if we had a host.

Pierre: I'm just throwing ideas in.
... Hopefully we won't need to meet in person though, I'm hopeful we can deal with this
... electronically.

Nigel: Me too.

Pierre: If we want to target July I need to book travel in the next three weeks.

Nigel: Okay let's come back to this in 2 weeks and see if we can confirm.
... By the way for TPAC I've filled in the survey as any two consecutive days, avoiding
... clash with M+E IG, and requesting joint meeting with CSS WG.
... Thanks everyone, next meeting in 2 weeks. [Adjourns meeting]

Summary of Action Items

Summary of Resolutions

  1. Add paced calcmode and feature designators for paced and spline calcmodes.
  2. When publishing IMSC 1.0.1 Rec, mark IMSC 1 as Superseded
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/04/05 15:43:23 $