Timed Text Working Group Teleconference

13 Jan 2017

See also: IRC log


Pierre, Andreas, Glenn, Thierry, Dae, Nigel


<scribe> scribe: nigel


Pierre: Returning to the process for publishing an updated version of IMSC...
... are there likely to be implementations for the line gap closing issue?

group: [conversation about if there's a way to go straight to PER or go via the traditional WD -> CR -> PR process.]

nigel: If we are adding any new features then the thing that could impose the longest duration
... on the publication process might be the patent policy, and even if features are completely
... optional it would be valuable to have them be covered by this.

Andreas: For some external organisations to reference the update it may need to be a Recommendation.

Glenn: How would industry react to introducing new optional features in a new version of the spec, given that the current spec only has required features?

Nigel: There are two devils to choose between: having some processors that behave less completely than others, or having identified processors that actually cannot process new documents.
... The view from yesterday is that the second option is less bad.

Pierre: Yes, specifically for the two features we are considering, line gap and active area signalling.

Nigel: Here's a wiki page on how quickly we could get to an updated Rec:

-> https://www.w3.org/community/w3process/wiki/Rectracktimeline

group: [discussion of options for a name for the new spec]

nigel: Other groups have used 1.01 or Level 1 etc

Pierre: It's important for industry perception that we have a single new document that does not give the impression that existing IMSC1 processors are no longer valid somehow.

Glenn: It would be easier to publish the new features in a new Rec track document or WG Note.

Andreas: It would be better for industry to keep the current view of the existing profiles.

Glenn: Some of my clients strongly argue against proliferation of profiles.
... Introducing new features without a newly identified process is antithetical to past practice.

Nigel: It's worth us pursuing if we can correctly go through the wide review, implementation, patent policy etc and have an outcome that is backward compatible with the previous version but still accessible via the same short name. For example a 1.0.1 version.

Glenn: I feel this goes against history and precedence and am concerned about unintended consequences.

Thierry: How are you going to justify that you're publishing a second FPWD of the same short name?

Nigel: Can we go straight back to CR?

-> https://www.w3.org/2015/Process-20150901/#rec-edited

Pierre: I think the fact that we are not changing conformance because we're only introducing optional conformance means I think we have a strong case.

Andreas: We made a substantive change in conformance between TTML1 and TTML1SE.

Glenn: We did, but did not introduce any new features.

Nigel: For me the only question is can we follow last sentence of process §6.7.2 while using the same short name.

Pierre: I propose to put together a short presentation explaining why we want to do this.
... I will send it to the group.

Thierry: How long will it take to put a new WD together?

Pierre: We're just working on last details so end of next week.

Thierry: It would be useful to have an ED to show to the Director - that would probably help.

Pierre: I think we could do this, have no outstanding issues, show the liaisons, and make the case.

Nigel: We would need to be careful not to overwrite the exising /TR/ttml-imsc1/ link so it no longer points to the Rec,
... for instance by using something like /TR/2017/FPWD-ttml-imsc1-[date]/

Pierre: Can we look at a pull request?

-> https://github.com/w3c/imsc/pull/199

-> Recommend begin+dur in addition to begin+end #199

Pierre: For the Unicode liaison, there's no action for us at this time.
... Their plan as I understand it is to correct their exemplars in the light of the submission
... and in the context of IMSC2 we will adapt the annex based on the outcome of their edits.

Nigel: As Chair, looking at the agenda, I think we should come back to the IMSC 2 scope question in a later meeting.

Group Actions etc

Nigel: First up, will we have a F2F meeting at TPAC 2017 in California?
... 6-10 Nov in Burlingame.

group: [approval]

Glenn: I propose that we reserve 4 days since 2 day meetings never seem long enough.
... If we have gone to Rec by May according to our timeline then we would not need 4 days.


<trackbot> action-480 -- Thierry Michel to Request schedule time for horizontal review of ttml2 -- due 2016-09-26 -- PENDINGREVIEW

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/480

Thierry: I did ask all the groups.
... They are starting to review it, but we should tell them when we have a 'final' document.

close action-480

<trackbot> Closed action-480.

nigel: I did respond to a request from i18n (Addison) if it would be okay to delay by a couple of weeks, which I said would likely not cause us any problems.

Thierry: Will the next WD of TTML2 be the final WD?

Glenn: That's a good goal; there are probably around 100 issues I need to resolve.

Thierry: Will new features be allowed?

Nigel: I would look at them on a case by case basis but generally take a hard line for anything new in TTML2 at this point.

Pierre: It's reasonable to tell the world what the deadline for new features is.


<trackbot> action-491 -- Nigel Megitt to Generate detailed (timed) agenda for f2f to allow people to prepare in advance -- due 2016-12-22 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/491

close action-491

<trackbot> Closed action-491.


<glenn> https://www.w3.org/wiki/TimedText/Publications

Nigel: In terms of roadmap, we still have work to do to generate a WD for Wide Review,
... so we're behind what's currently on that publications page link by some months.

Glenn: The quickest we could get to a WD including updated spec text would be the end of February, addressing all open issues, at least to the point where there's something in the spec.
... If we start a wide review in early March, then we need a review period. 60 days?

Thierry: 30 days?

Nigel: I would be conservative and choose 60 days.

Andreas: +1

Thierry: Can we focus the request for wide review on the new features in TTML2?

Glenn: We can point to the annex of changes, but anyone can comment on anything they want.
... Wide Review would then be completed in early May, and we need to respond to comments.

Nigel: I would give that 6 weeks at least.

Pierre: Responding to dispositions can take some time because it involves the reviewers too.

Andreas: Or 8 weeks.

Glenn: I would say 8 weeks/2 months too.

Thierry: We can start addressing comments early if there are comments.

Glenn: We're up to end of June, beginning of July for CR.

Dae: There should be implementations by then I think.

Glenn: What's the shortest CR period?

Nigel: 1 month, as long as there are implementations.

-> https://www.w3.org/2015/Process-20150901/#last-call

Nigel: The process tells us the CR should be longer than 4 weeks for complex documents, which I would argue does apply to TTML2.

Glenn: We need to create test suites too.

Nigel: They need to be in the exit criteria, so they should be there before CR.

Glenn: We can define the test suite during CR.

Nigel: I think 8 weeks for CR is reasonable.
... That means we won't exit CR before September, or it could be later if we want to wait for
... more implementations.

Glenn: At the end of the first CR we have to see where we are and if we need to make any
... substantive changes to fix technical errors then we would need a new CR. Also we have
... to decide which features to mark as at risk when we publish each CR.

nigel: Then PR is at least 28 days.

Dae: So if everything goes perfectly according to this plan then it could be a Rec by the end of September?

Thierry: At best.

Nigel: One risk is that the CR would be during summer holiday period.

Pierre: Another is that we should plan for a second CR, because the risk of this being needed is significant.
... I would add another month for that.

Glenn: In our previous plan we had 4 months for CR1 and 2 months for CR2.

Nigel: The timeline we've outlined is quite aggressive for TTML2.

Glenn: We have examples for most of the TTML2 features and I'm sure we'll be augmenting them over time to make them a fuller set.
... I expect at least 3 implementations reported, one from Skynav and 2 from Netflix.

Dae: We'll have 2. Not necessarily each having all features.

Nigel: I'm expecting BBC to have at least one implementation of the audio description work.

Glenn: We will need to define what counts as an implementation - just syntactic parsing or both that and presentation semantics.

Nigel: We have to have independent implementations.

Glenn: "independent" is not formalised in W3C.

Thierry: It's not sharing the same code.

Glenn: That's one possible interpretation. It's up to us to define it.

Pierre: So what deadline for new features should we impose on ourselves?

Glenn: I would say mid February to get it into the Wide Review draft. 15th Feb.

Andreas: I'm a bit sceptical about this, I think realistically we are likely to have the open issues closed and a WD for Wide Review at end of March.

Glenn: I agree it's more likely, but I would retain 15 Feb as a deadline for new features.

PROPOSAL: We will impose a cut-off for new TTML2 features of Wednesday 15 Feb 2017.

RESOLUTION: We will impose a cut-off for new TTML2 features of Wednesday 15 Feb 2017.

Nigel: I'll highlight that in a minutes email.

Glenn: Then the question is, solidifying this timeline, do we want to give ourselves to the end of March for the Wide Review WD?

Nigel: Let's say 15th March for all issues to be discussed and agreed, or deferred, and then
... 30th March for the final editorial version of the WD for Wide Review.

Andreas: +1

Glenn: OK

Nigel: Please could you create an updated picture Pierre?

Pierre: Yes

<scribe> ACTION: pal Update timeline picture to reflect new TTML2 publication timeline [recorded in http://www.w3.org/2017/01/13-tt-minutes.html#action01]

<trackbot> Created ACTION-493 - Update timeline picture to reflect new ttml2 publication timeline [on Pierre-Anthony Lemieux - due 2017-01-20].

Action-493: WD for Wide Review 30th March, Wide Review 8 weeks, Comment Resolution 8 weeks then CR1 for min 8 weeks, then CR2 for 4 weeks, then PR for 4 weeks, then Rec.

<trackbot> Notes added to Action-493 Update timeline picture to reflect new ttml2 publication timeline.


<trackbot> action-493 -- Pierre-Anthony Lemieux to Update timeline picture to reflect new ttml2 publication timeline -- due 2017-01-20 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/493

Pierre: The next question is when should the FPWD of IMSC2 be?

Nigel: I think we should be preparing it during the TTML2 WD for Wide Review period.

Pierre: Yes, though we need clear requirements and may be busy with IMSC 1 v.next
... End of July for a FPWD is not too unrealistic.

Nigel: By the way the deadline for new features is scoped to the WD for Wide Review.

Andreas: The requirements capture for IMSC 2 may generate new features for TTML2.

Pierre: That's a good point. Comments in by end of May is reasonable, which could be drivers for new features in TTML2.

Dae: Would a F2F help deliver this aggressive timescale?

Glenn: It may be useful to have one to help dispose of the comments, perhaps in May/June.

Dae: It would give us a chance to review any IMSC 2 requirements or feedback too.

action-493: Pierre has posted the updated picture at https://www.w3.org/wiki/TimedText/Publications

<trackbot> Notes added to action-493 Update timeline picture to reflect new ttml2 publication timeline.

close action-493

<trackbot> Closed action-493.

group: No schedule that works for a summer F2F to be useful; informal meetings are a possibility for those who can make them.

TTML2 Issues

Pierre: We said we would come back to a couple of TTML1 issues.

Dae: 193 and 194.

-> https://github.com/w3c/ttml1/issues/194 Ambiguous definition for determination of descendant region identifier. #194

Glenn: There was a question here about what the requirement should be.
... One question is does what is in TTML1 have an unambiguous behaviour regardless of whether it is intended or not.

nigel: [lunch]

TTML Issues continued

-> https://github.com/w3c/ttml1/issues/193 Inconsistent implicit duration of singleton span in sequential container. #193

Nigel: I've added a note to the issue. We need to resolve this for TTML2 as well.

Glenn: I need to investigate more, I'm not prepared to close today.

Nigel: I really would not mind marking this as Wontfix and leaving the existing behaviour in place unchanged.
... It's a corner case that does not seem to cause any significant issues.

Glenn: I agree it's a corner case.

TTML2 issues and WD review

Nigel: Firstly, where there are TTML1 issues that we've discussed and agreed is everyone happy for me to mark the TTML2 equivalents as Discussed and Agreed offline?

Andreas: Yes

Glenn: [nods]

Pierre: Absolutely.

<scribe> ACTION: nigel Mark the TTML2 issues as Discussed and Agreed where we've discussed and agreed their equivalent TTML1 issues. [recorded in http://www.w3.org/2017/01/13-tt-minutes.html#action02]

<trackbot> Created ACTION-494 - Mark the ttml2 issues as discussed and agreed where we've discussed and agreed their equivalent ttml1 issues. [on Nigel Megitt - due 2017-01-20].

Nigel: Now what should we focus on?

Glenn: I'd like to look at the updated WD

Andreas: I'd like to look at the spatial positioning annex in the TTML2 WD and the new text on tts:lineHeight

Pierre: I'd like to look at the PAR/SAR/DAR recently added text.

Nigel: Here's a link to the diff between this WD and the previous:

-> http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2016%2FWD-ttml2-20161117%2F&doc2=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-ttml2-20170106%2F#root-container-region-semantics

-> https://www.w3.org/TR/ttml2/#root-container-region-semantics

Glenn: I'd like to go through this draft material and get input on it.
... Pierre has already suggested some improvements; I'm not fixed in my thinking on this yet - I'm open to changes.

Pierre: My comments were about the algorithm. A bigger point is I don't think it makes sense
... to define pixelAspectRatio if the document does not use pixel dimensions.
... Similarly what do pixel measurements mean if there is no tts:extent on the root element?

Glenn: In TTML1 it was assumed that there were pixels present regardless of whether tts:extent was specified. Also we did not have to worry about images.

Nigel: The definition of PAR jumps into physical units whereas SAR and DAR are logical.
... If you're going to do maths on them in the algorithm below they better be in the same units.
... In my view all the pixels in TTML are logical.

Pierre: It's possible to define an internally consistent logical coordinate space using pixels regardless of the physical device pixels.
... You can do that either by explicitly specifying tt:tt/tts:extent or by providing it in the document processing context.
... You can handle images in this context as a separate activity.

Glenn: §6.2.7 in TTML1 is the only place where PAR is defined.

Nigel: There's nothing there that refers to physical device pixels.

Glenn: Right. The question is how to define these terms more fully.

Pierre: I would define PAR only in terms of DAR and SAR and not mention anything about logical or physical pixels.

Nigel: I would like to separate the handling of image sample pixels from logical TTML pixels, which again are independent of any subsampling or supersampling to generate device pixels.

Glenn: We can define PAR is a ratio of DAR and SAR, then the question is whether to tie that
... to any physicality or logicality. In the document coordinate space we are going to say it
... has a resolution that divides the document coordinate space into pixels.

Pierre: You don't need pixels though, so you don't have to specify these.

Glenn: I want to though.

Pierre: For example imscjs defines all dimensions canonically related to a root container region that extends in each dimension from 0 to 1,
... without mentioning pixels at all.

Glenn: What do you do when you have a pixel-sized image?

Pierre: In IMSC1 for example the image must be the same size as the region so you don't
... care what the pixels in the image are - you're always going to scale it.

Glenn: Let's say I'm an author and I have a PNG image with a phys chunk and I want the
... rendering engine to display it in however many logical pixels so that the physical size
... matches the actual size in the phys chunk.

Nigel: If I want a particular size I would specify that in logical coordinates, or if not then I
... would solely specify a position. I don't know why you'd use native size in a TTML context.

Pierre: You would also need to take into account scaling the root container region.

Nigel: So we have one issue to handle, the definition of PAR.

Glenn: What do those here think should happen if no aspect ratio is specified?

Nigel: If no aspect ratio is specified then I think DAR may be provided by the processing context.

Pierre: That's what IMSC1 does - it says the DAR is the DAR of the related media object.
... In TTML2 I think we can leave it undefined.
... "undefined" has to be a possible value.

Nigel: I think SAR="undefined" makes sense and implies that pixel based measures are meaningless.

Pierre: You could always require that the processing context defines the DAR if it is omitted.

Glenn: If no aspect ratio is specified and if there is a related media object with a DAR then use that.

Pierre: There may be scenarios where there is a related media object but the processing context does not want to fill it with the Root Container Region.

Glenn: Then we should document that in No Aspect Ratio then the document processing context is expected to provide a DAR, and then fall through to One Aspect Ratio.

Nigel: The DAR is the most important thing because it will determine how many characters will fit on a line.

Pierre: +1

Glenn: Then I'll remove the default value of PAR.
... Now look at H.1.2 One Aspect Ratio. If one aspect ratio is defined...

Pierre: If no SAR is specified then leave it and PAR unspecified/undefined.

Glenn: OK let's run with, if only DAR is specified then SAR and PAR are left as "undefined".
... Now what if there's no DAR? That's like in TTML1 having tts:extent and no ttp:pixelAspectRatio.

Nigel: Even with "no aspect ratio provided" we just insisted that the document processing
... context provide a DAR, so I think we can insist on this.
... The implication of no DAR is that you'll never write anything to a display.

Pierre: That's right, then you can't display anything visually.

Glenn: Okay I think I get that.
... Now what if only PAR is specified?
... I guess you would also require that the processing context provide a DAR?

Nigel: Yes

Glenn: OK then let's go to 2 aspect ratios.

Nigel: This looks simple enough but what if there is a provided DAR and it does not match
... SAR x PAR? That is like the case with ittp:aspectRatio, in which the root container region has a different shape to the related media object, and alignment rules are specified.
... Maybe we need two distinct concepts of the contextual DAR and the document DAR.
... In the first two cases they are identical but in the third one they could be different.

Glenn: That could use the new term "contains".

Nigel: "Contain" as a semantic for SAR doesn't make any sense on a root container region - it does not provide you with a numerical pixel coordinate system that you can reference.

Glenn: "contain" came from CSS images and background positioning rectangle.

Nigel: That works in the context of images with an internal SAR in pixels but it doesn't make sense here.

Glenn: I had proposed using "contain" as a value for tt:tt/tts:extent to try to match IMSC1's
... ittp:aspectRatio.

Nigel: I've understood ttp:displayAspectRatio to be the equivalent to ittp:aspectRatio.

Pierre: Yes that is right. I think application specifications should be left to indicate how to use ttp:displayAspectRatio to map the root container to the related media object or any display.

Glenn: In TTML2 if you have a DAR but the external context's DAR is different what would you do?

Pierre: I don't recommend specifying that in TTML2 - it's for application specifications.

Glenn: I was trying to map all IMSC1 features - I thought that was required for TTML2.

Nigel: Maybe we just need to make IMSC2 contain all IMSC1 semantics whilst still being a profile of TTML2, so some details can be left to the IMSC2 profile?

Glenn: If it's not part of TTML2 then IMSC2 would not be a true profile.

Nigel: In that case maybe we need a specified behaviour defined as a feature in TTML2 so that it can be referenced from IMSC2 without necessarily requiring that all profiles have the same behaviour.
... I propose a feature designator that defines that the relationship between ttp:displayAspectRatio and the processing context provided DAR is a "contains" relationship a la IMSC 1 ittp:aspectRatio.
... If we have to make IMSC2 a strict profile then it can mandate support of that feature.

Glenn: I think I have enough data to try to resolve things online now, and can modify this according to what we've discussed.
... I'll try to make an iteration and see if we can make an iteration on this.

Group working model

Andreas: I'd like to focus telcos on specific topics, one or two, and know in advance which ones so that we can prepare for them.
... I'd also like to ask for confirmation of what we will do on TTML1 with line gap - Dae asked
... if we can close it, which is fine by me. I want to check we don't do what the last comment on the issue says.

Dae: Yes its issue #209: I propose not to address the issue and leave it as is.
... It would be really helpful to push the weekly telcos back by as long as possible.

Pierre: I'll have to check.

Nigel: That would be one hour later, 11 o'clock Boston time.

Andreas: It's fine for me.

Nigel: I prefer the current time but could move it back by an hour.

Glenn: It wouldn't cause me any trouble.

Pierre: If we make it one hour later then I won't be able to do two hours.

Nigel: I would have that problem too.

Andreas: If we need that then we should start earlier exceptionally.

Nigel: Okay I'll look at that.

group: Discusses final comment (currently) on #209, agrees not to change the current agreement to add an informative note by errata.

TTML2 issues

-> https://github.com/w3c/ttml2/issues/53 Inline space. #53

Nigel: We said we needed to come back to this.

Glenn: We need to separate ipd and bpd from inline block semantics.

Nigel: I'd support that.
... I updated the issue.

-> https://github.com/w3c/ttml2/issues/119 Add support for marquee style semantics #119

Nigel: I propose to defer this.

Glenn: I support moving margin support into TTML>2.

group: agrees

Nigel: Done on the issue.

-> https://github.com/w3c/ttml2/issues/146 Inline block semantics impacts text wrapping #146

group: discussion of ipd and inline block, and what ipd might mean. It could be that margin is a better fit for the requirement than ipd.

Meeting Closure

Nigel: Thank you everyone for a productive two days. I'll send the minutes out and for next
... week will try to pick one or two specific issues to discuss, if nobody chooses one for me.
... [Adjourns meeting]

Summary of Action Items

[NEW] ACTION: nigel Mark the TTML2 issues as Discussed and Agreed where we've discussed and agreed their equivalent TTML1 issues. [recorded in http://www.w3.org/2017/01/13-tt-minutes.html#action02]
[NEW] ACTION: pal Update timeline picture to reflect new TTML2 publication timeline [recorded in http://www.w3.org/2017/01/13-tt-minutes.html#action01]

Summary of Resolutions

  1. We will impose a cut-off for new TTML2 features of Wednesday 15 Feb 2017.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/01/13 17:12:20 $