Timed Text Working Group Teleconference -- 21 Aug 2014

<trackbot> Date: 21 August 2014

This meeting

<scribe> scribeNick: nigel

group: no AOBs to raise

mike: regrets for me for Sep 4 meeting

nigel: Let's set aside 1 hour for our 4th September meeting

Geneva F2F meeting

RESOLUTION: We will proceed with the Geneva F2F meeting as planned.

pal: Based on the attendees I suggest we take 2-3 hours on day 2 morning to resolve any issues on IMSC 1 in prep for LC.

nigel: We have more folk interested in VTT attending on day 1 than on day 2 so that makes sense to me.

pal: I may have to duck out on 2nd day afternoon for some SMPTE stuff.

mike: I plan to try to be there both days. On day 2 at 1700 local time there's a meeting I need to be at but we should have finished by then.

nigel: Anything else to squeeze into the agenda as well as the TTML <--> WebVTT and IMSC 1 work?

group: nothing to add.

nigel: We need to think about the structure of the TTML <--> WebVTT part - I've added some thoughts, but please could all consider this and make any proposals first on the reflector, and then we can
... make them more concrete on the wiki page.

frans_EBU: We're okay to use the EBU canteen on an ad hoc basis - it won't be a served meal.

nigel: So the only cost for attendance is food at EBU, travel and accommodation - there's no other attendance fee.

Action Items

action-319?

<trackbot> action-319 -- Nigel Megitt to Draft liaisons to relevant organisations for imsc 1 timeline -- due 2014-08-21 -- PENDINGREVIEW

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

mike: Both SMPTE and DECE messages were transmitted. Response will probably be after the Geneva meeting.

frans_EBU: I can confirm I received the EBU message and will forward it today.

close action-319

<trackbot> Closed action-319.

action-323?

<trackbot> action-323 -- Nigel Megitt to Update issue-263 to target product ttml2 and open a new one on sdp-us. -- due 2014-08-21 -- PENDINGREVIEW

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

nigel: I completed this.

close action-323

<trackbot> Closed action-323.

action-320?

<trackbot> action-320 -- Glenn Adams to Review https://www.w3.org/wiki/ttml/codecsregistry w.r.t. recent ttml2 changes in profile definition mechanisms -- due 2014-08-21 -- OPEN

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

action-322?

<trackbot> action-322 -- Jerry Smith to Indicate preference for updating sdp-us for ttml2 -- due 2014-08-21 -- OPEN

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

jdsmith: Still working on that one. Hopefully will do so in the next few days.

action-324?

<trackbot> action-324 -- Glenn Adams to Draft a note for imsc 1 progressivelydecodable to make concrete what authors should take into account -- due 2014-08-21 -- OPEN

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

glenn: My email earlier was related to this.

pal: We agreed that within <head> it is not required to dereference forward references while parsing?

glenn: That's correct.
... The dereferencing process only occurs during the synchronic flow processing process as currently defined, generally done after the whole document has been processed.
... It could be done as an optimisation during processing of the <body> but elements spread out throughout the whole document may select into the same region;
... If they're ordered temporally then you would be able to perform the synchronic processing once you get to a time you know is later than the time of the elements
... currently being considered for inclusion in the synchronic document.
... So the only consideration is times.
... My message earlier today related to the styles portion. There doesn't seem to be an ordering dependency there.

pal: If you order the style elements in order in <head> you don't have to wait until the end of <head> to compute your final style properties.

glenn: You never do that until you process the content elements, and that doesn't occur until you perform the synchronic processing step.

pal: So if style id="a" references style id="b" then I need to see both, for a parsing simplicity aspect.

glenn: That's an optimisation but not predicated by anything in the spec. It doesn't matter if they're ordered or not; the optimisation may not be possible if they're not ordered.

pal: The purpose of the flag is to indicate that the optimisation is possible.

glenn: In that case it should be named "pre-optimised" or something.

pal: yes, it's a head optimisation thing.

glenn: It's a small optimisation.

pal: I agree with this assessment. It's called progressivelyDecodable in CFF-TT but if there's a consensus on a different name we could consider that.

glenn: We should keep the name but have a note that points out what I said about styles.

pal: I'm happy to have that note. Is that all of the note or would there be other stuff?

glenn: That's all I'd comment on.

pal: You can move the action to me then. The note will indicate that the ordering of style in head is not necessary for progressive presentation but is an optimisation of the head element.

glenn: There are only 2 types of forward referencing: 1. Chained styles with xml:id; 2. Temporal ordering of elements. Then I'd explain that dereferencing style elements is technically only required after <head> is fully parsed.
... In the case of a non-linear ordering it might prevent an optimisation prior to completing parsing of the head element.

nigel: I've reassigned that action to pierre.

pal: Just to confirm, the only xml:id referencing that impacts ordering is the style one - is that your conclusion?

glenn: Yes, in TTML1. Region is the other thing that makes references, but only from body elements to region elements in the head, so the definition always precedes the usage.
... TTML2 will be a little more complicated due to out of line animation plus potential link elements.

mike: The assumption in DECE has always been that it's after the parsing of head that we need to worry about most.

Issues

issue-334?

<trackbot> issue-334 -- Misuse of style property characteristics with ttp:progressivelyDecodable -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/334

pal: this needs review by Glenn.

glenn: sounds good, we can close this.

close issue-334

<trackbot> Closed issue-334.

glenn: Is progressivelyDecodable a parameter or a metadata attribute?

pal: It's ittp:

glenn: It's sort of borderline between parameter and metadata. It's potentially usable by a processor so I can accept it's a parameter.

mike: Agree - it changes the decoding approach for the processor.

Issue-303?

<trackbot> Issue-303 -- Permit HTML-style <a> elements to contain href links -- open

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/303

nigel: This has only been discussed in relation to the WAI/PF Media Accessibility Requirements, which in the Enhanced Captions requirements state that a link mechanism should be included.

glenn: I'm working on a more generic mechanism for expressing links and ruby rather than opening it up for everything.
... I'm thinking about adding an attribute to <span> which may work a bit like the class attribute, with a string of one or more tokens, that adds semantics onto span
... such as 'this is a ruby span', 'this is an anchor/link span' etc. It turns out that Apple has added support for ruby in TTML using a ruby token to span
... It seems to me that the same approach could be applied to link. Just thinking about that.

Courtney: I want to clarify: we have a proposal for doing it that way for the iTunes Timed Text Format, derived from TTML. We did that
... because the ruby tag isn't in TTML. There are benefits to using it as a ruby tag - we'd have consistency with other specs.
... If we could add the ruby tag into TTML2 then I think Apple would use that instead.

glenn: This could be a useful side-discussion at the F2F. We already have a relatively complex process for translating
... from TTML into HTML so it wouldn't be difficult to translate from a marked up span to the equivalent HTML.
... From a specification and schema perspective it's easier not to define new element types, but I'm willing to consider both approaches.
... I actually like the way you did it - it integrates pretty well and has other benefits.

Courtney: Okay, it would be good to get a decision one way or the other.

nigel: I suggest this should be on the agenda for TPAC

glenn: Yes it's an issue to resolve before LC at least.

issue-310?

<trackbot> issue-310 -- Forward reference rule doesn't take into account child elements -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/310

pal: I've addressed your last comment on the reflector.

close issue-310

<trackbot> Closed issue-310.

issue-335?

<trackbot> issue-335 -- In order to handle offsets between start time in TTML docs and start time in video, allow negative times to be used in fragment begin times. -- raised

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/335

reopen issue-335

<trackbot> Re-opened issue-335.

nigel: The reflector discussion seemed to end up that by adding a document temporal offset we can make whole document adjustments most easily.

Courtney: This may be specific to our workflow.

glenn: When we drafted the timing section I drafted a referenceBegin parameter, but at that time we didn't have a strong driving use case.
... Now that we have this use from Apple for negative times it would resolve that. It might also be used to make it simpler for SMPTE-TT documents that
... start at 10:00:00 to change the tokens to zero based times.

nigel: As I understand it transformations on times are not permitted on smpte times with discontinuous markerMode - would that change that?

glenn: I'd have to have a look at that more closely.

issue-336?

<trackbot> issue-336 -- Syntax definition missing from ittp:aspectRatio -- raised

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/336

reopen issue-336

<trackbot> Re-opened issue-336.

pal: That's something I noticed - we need to make a change to ttp:aspectRatio along the lines of what we had to do for progressivelyDecodable.

issue-337?

<trackbot> issue-337 -- Update SDP-US for TTML2 -- raised

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/337

reopen issue-337

<trackbot> Re-opened issue-337.

IMSC 1 issues

pal: A number of the remaining open issues are related to the change proposal on profiles. The proposal is to refactor IMSC to add another profile, but
... that's contingent on some not-yet-completed submissions. So we can't really make progress on any of these.
... I need to wait for all the requests to be in by Sep 5 before I can make an editorial proposal. It's not clear how e.g. #cellResolution will interact with other feature requests.

issue-327?

<trackbot> issue-327 -- IMSC should meet W3C QA Framework Spec guidelines -- open

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/327

pal: My plan is to complete the bulk of changes and then do an editorial pass on the whole document, so I expect to register that issue at the last moment.
... Unless you know of specific normative impact then it's only editorial.

Change Proposals

group: no specific CPs to discuss.

nigel: Meeting adjourned - thanks everyone, reminder there's no meeting next week.

- DRAFT -

Timed Text Working Group Teleconference

21 Aug 2014

Attendees

Contents