Timed Text Working Group Teleconference

16 Mar 2017

See also: IRC log


Dae, Glenn, Nigel, Pierre, Thierry, Rohit, Mike


<scribe> scribe: nigel

This Meeting

Nigel: For today, we will discuss WR publication of the IMSC update.
... Then we have TTML issues, with some "focus" issues that have already had some
... discussion on the reflector.
... I'd like to do some meeting planning too, in terms of duration and start times, and also
... focus topics for upcoming TTML discussions.
... Is there any other business for today? Or any particular points to cover that may not be on the agenda?

group: [tumbleweed]

April meetings

Nigel: I'm on vacation for the 6th April, happy for the meeting to proceed if someone
... wants to volunteer to chair, scribe etc.
... I would like to propose we plan for 2 hour meetings on the remaining April dates
... given our likely progress. Any views?

Dae: I agree.

Nigel: In that case I will default to 10am Boston start time, 2 hour meetings in April.
... For future TTML focus topics I will return to that in the TTML agenda item.


Nigel: First, thank you Pierre for providing an updated version of the WD for WR for our review.


Nigel: I raised an issue about security and privacy that we don't need to do now but should do soon.


Nigel: There were two requests from Glenn, firstly to change "minor revision" to "revision",
... secondly to make a note about the possible change of name/version in the future.
... There was also some discussion about adding a reference to a change list in some form.
... At the moment the Scope summarises the changes but what is needed is a little more detail.
... One option that other groups use is to link to an HTML diff.
... Specifically I believe the change list is between this WD and the IMSC 1 Rec, not between
... this WD and the previous WD.

Thierry: The goal for mentioning those changes is to focus the wide review on the new
... features only, so therefore you should have the differences between the WR WD and the previous Rec.

Nigel: Firstly then, any problems with removing the word "minor"?

group: No problems.

Pierre: That's straightforward to do, I can do that easily.

Nigel: We've had some discussion about the addition of warning text about a possible version change on the reflector,
... my personal view is it is not needed - there are a number of bad things folk might do but
... I don't think any warning we put there will prevent them from doing those things.
... Having said that I wouldn't have a strong objection to it.
... Any other views?

Pierre: The likelihood that we will make the change is low so the addition is unwarranted.

Glenn: I view this as similar to marking features as risk. My position is we should add the note.

Mike: I think this matters to those on the phone call, and others including those in W3C probably do not care.
... I would lean towards leaving this alone and not adding the note, and hope we do not need
... to discuss it again.

Nigel: Glenn will you object to a proposal to publish this WD for WR without the additional
... warning text?

Glenn: No, as long as we have minuted this and the decision.

Nigel: In that case I will (as Chair) call this in favour of publishing with minimal changes, i.e.
... without the warning message, in the cause of expediency.
... The third issue is about referencing a change set.

Pierre: The idea of providing the reader with an unambiguous diff is really important.
... Viewers can do that themselves with the W3C diff tool.

<pal> http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2Fttml-imsc1%2F&doc2=https%3A%2F%2Fwww.w3.org%2FTR%2Fttml-imsc1.0.1%2F

Pierre: We could list the substantive changes, which would exclude the editorial changes.

Thierry: For simplicity I would recommend using the diff tool. This can be done with a link
... in the spec, or I can save the results in a file that we can then link to.
... Let's make it simple, put a link to a file in the same directory, and I will generate the
... diff file and upload it to the publishing directory.

Pierre: Okay then I will not create a link to the W3C HTML diff service, instead I will assume
... there will be a diff file included alongside and that will be a diff against the Rec.
... And separately we have to create a list of substantive changes?

Thierry: No, you don't need to do that until we transition to CR.
... This is just to focus the wide review on the changes only.

Pierre: §6.3.2 of the Process talks about substantive changes since the previous WD.

Nigel: We made a change to the way the Active Area is calculated.

Pierre: So I have to create that file, which will be straightforward.

Thierry: Then just list it in the appendix.

Pierre: I will do that.

Nigel: Ok that sounds like a plan, the 4th and final thing is the Security and Privacy section.
... My question is: do we need this now, or can we add this at, say, CR?

Thierry: It would be better to have it now, because we can ask the Security guys to review
... that during Horizontal Review. It could save us some problems.

Nigel: Actually we must ask for that review, and they will ask us to fill in a form, and that
... will ask us if there is a section present, and we will say no, and they will say to create it then.
... Thinking practically, what do we need to put into the section? Just the points that
... I made in issue 219? Are there any other points?

group: [No other comments]

Nigel: In that case I don't mind drafting a pull request for this to allow us to review and
... include, and move a bit faster overall. I wouldn't mind Pierre doing to either (or anyone else).

Pierre: [concerns about adding an extra 2 week review delay before publishing WR]

Thierry: We could publish without it, and then add it in 2 weeks and update the WR.
... I don't expect any feedback on this other than from the security people.
... That would allow us to save a bit of time.

Pierre: I'm happy with that.

Nigel: Ok that works for me, to go ahead without that section, rapidly work on that section,
... and then publish when we have agreed an update.
... If people are willing to give positive comments on the pull request sooner we could get it
... in by positive consensus.
... I could draft something by end of play today for review and hopefully completion by end of play tomorrow.

Thierry: Would that be okay for everyone? Then we could include it next week.
... I would rather people would positively agree before, but if an issue is spotted then we
... could then make a subsequent update to the WR.

Nigel: OK let's try that and see if we can make it work.
... Those are all the points to discuss, now I'd to move to a proposal to publish.
... This would be a "mutatis mutandis" proposal.

PROPOSAL: After applying the changes agreed in principle in this meeting we will publish this draft of IMSC as a WD for WR.

Nigel: If we publish this next week when will be the closing date for the review period?
... Sunday 7th May would be a little over 6 weeks.

Pierre: There will be external organisations who may review, and some of those groups do
... not meet regularly, so we need to give them the opportunity to reach consensus.
... I'll use Sunday 7th May.

RESOLUTION: After applying the changes agreed in principle in this meeting we will publish this draft of IMSC as a WD for WR.

Nigel: Thanks, that's all on IMSC, let's take 3 minutes and come back and spend the next hour on TTML.

Thierry: I have to leave now.


Nigel: I'd like to go through the focus topics, agree next week's focus topics, then go through any other
... issues anyone wants to discuss. Will that work for everyone?

group: [assent by silence]

Nigel: First one is Inline Space


Nigel: Are we at a point where we can agree that if the use case is micro-positioning of
... glyphs then that data is in fonts and we do not need to support negative inline space?

Pierre: My data point is that this has proven useful in digital cinema over many years.
... If we are planning to filter feature support based on Lambda Cap then that would make
... things a lot simpler.

Glenn: Even though there may be a problem to solve we do not need to solve it in the same
... way. The same problem as fillLineGap exists here in that micropositioning can only be
... achieved if there is knowledge of the font used at rendering time. We cannot require a
... sufficiently closed environment where that is known. So my position would be not to add this,
... especially since other solutions exist such as use of images.

Nigel: Can we make a group disposition here that we will not support negative inline
... space for the purpose of glyph micro-positioning since other mechanisms exist?
... I am thinking ahead to the response to the original requester.

Pierre: I will not oppose that.

Nigel: Ok that sounds like a decision as I described. I will add a note to the issue.
... I have taken off the "Editor considers closed" label and closed the issue.
... The next issue is #239 3D and images


Nigel: We discussed this a little last week but did not close it off because we wanted to make
... sure all the right people were involved in the decision.

Mike: I withdrew my suggestion, as was clear in the issue. I do not think this is needed.

Nigel: The only open question is if we want named left and right parameters for use in
... the @condition mechanism.

Pierre: Why? What use case would this address?

Glenn: The named parameters would allow for standardised approaches. There is no demanding
... requirement for this to be in TTML2. It could be added in the future. In the meantime
... people could add extensions if they want them. There's no provision in media queries
... for stereoscopic display targeting anyway.

Nigel: Let's draw the axe down on this and do nothing, and close the issue. There's no
... requirement for it and we have plenty of other work to do.
... I will add a note to the issue and close it.
... Done
... Next issue is 96: Specify date as well as hours, minutes and seconds in time expressions


Nigel: The summary of this is that there is a problem but we have no spec text to address it yet.
... I don't know exactly what the solution should be or if we should leave it for the future.
... One idea would be to permit ISO8601 format datetime values, for example.

Glenn: My take on this was that we would leave it for the future. ISO8601 processing is
... a little complex and can require knowledge of external information.
... This would certainly have a testing impact. I did not want to suggest a syntax.
... I don't mind if someone else wants to draft something.

Nigel: I don't think there's an answer for this in SMIL.
... Is the reason nobody else has a comment on this that they do not use clock times?

Pierre: Yes, that's my reason.

Glenn: SMIL does actually offer an ISO8601 based syntax as an alternative for begin, end and dur I guess...

<glenn> https://www.w3.org/TR/smil/smil-timing.html#Timing-WallclockSyncValueSyntax

Nigel: Thanks, that would make sense as a solution in TTML when ttp:timeBase="clock"
... I don't think it would make sense in other timebases nor would it support a "days"
... component in general time expressions.
... I don't mind taking the action to propose that syntax.

Glenn: If the proposal is to adopt the SMIL syntax then I don't mind taking it from there.
... What's the attitude of the group - do we want it or not? I am ambivalent towards this.

Nigel: The group also seems to be ambivalent but there is a strong use case in live
... scenarios, either for capture of text or for live authoring.

Glenn: I think the phrase here is "without objection"

Pierre: Why not use UTC?

Nigel: UTC doesn't offer a date either, and in fact the hours component is locked off so cannot
... be used to express date when ttp:timeBase="clock".

Pierre: Alright.

Nigel: I've added a comment, and will change the labels.

Glenn: Just to mention that syntactically this makes it easy to integrate because the whole
... clock value including date is wrapped in a "wallclock()" wrapper. It is syntactically easy
... to integrate in the current syntax.

Nigel: Thank you!
... The next issue is 160 use of offset-time expression in smpte mode


Nigel: I think the problem here is that there is no quantisation rule in case a time expression
... does not evaluate to a frame value.

Pierre: Shouldn't we simply restrict the permitted time expressions so they do not have
... this problem?

Glenn: We have deprecated this in part in TTML2 but this is a corner case.

Pierre: Can we not say that it was unspecified before, it is deprecated now, and we are
... leaving it unspecified.

Glenn: That would be fine with me.

Nigel: Where is the deprecation?

Glenn: It is at §12.3.1 at the end of that section.


Nigel: I see. Are there any exceptions where even with the deprecation invalid timecode
... frame values could arise? Looks like the answer is no from the equations in I.3.

Glenn: As far as I am aware the deprecation covers all of the cases.

Nigel: Ok is everyone happy to do nothing on this?

Group: [no objections]

Nigel: Great, I will add a note to the issue and close it.
... Done!
... Thanks, those were all the focus topics for this week.
... Looking at next week, what would people like to focus on?

Pierre: https://github.com/w3c/ttml2/issues/240 emphasis-position vs CSS text-emphasis-position + Mongolian
... It sounds like we are nearly ready to get to an agreement on this.

Nigel: That's on the list.

Pierre: Related to that is issue #254.
... We should be able to close both together.

Nigel: Okay I'll add that to the list and let r12a know we plan to discuss this on next week's call.

Dae: Can we talk about the IMSC mapping/fallback/transform issue?

Nigel: Yes, thank you for putting that draft together in the week as you promised, we will
... have that on the agenda for next week.
... Ok we need more for the list than that - if anyone has any other suggestions over the
... next few days please email me.
... In the meantime, we had no AOB, so I will close the meeting. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

  1. After applying the changes agreed in principle in this meeting we will publish this draft of IMSC as a WD for WR.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/03/16 16:24:49 $