Timed Text Working Group Teleconference

<scribe> scribe: nigel

This meeting

nigel: I think we're mainly covering TTML stuff today. Any other business to cover?

group: no other business

TTML1 & TTML2 issues, actions, PRs, editorial actions etc

action-472?

<trackbot> action-472 -- Nigel Megitt to Make sure there is a ttml2 issue for considering adjustment of inline region semantics -- due 2016-06-16 -- PENDINGREVIEW

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

nigel: I did this, by adding https://github.com/w3c/ttml2/issues/168

close action-472

<trackbot> Closed action-472.

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 2015-11-05 -- OPEN

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

glenn: Can we reword this somehow - I think it's low priority.

nigel: Are all the ARIB ruby extension features mapped to something in TTML2?

glenn: I know on the ARIB set they had support for a marquee functionality which I have
... not had a chance to investigate its semantics. That would be the only one.
... My hope is that we could map that to set or animate without any additional features.

nigel: I think that's a dependency then.

glenn: That's the only feature in the ARIB extensions that I have not accounted for explicitly.
... I have also not checked if the ARIB spec has added any new features. Probably a year and a half since I reviewed in Japanese.

nigel: I think they did an English translation too.

glenn: I did not use that.

nigel: In that case the dependency is on https://github.com/w3c/ttml2/issues/119

action-443: [Meeting 2016-07-14] There is a dependency on https://github.com/w3c/ttml2/issues/119 before commencing this.

<trackbot> Notes added to action-443 Prepare a document showing mapping arib ruby extension features to ttml2 for use as a liaison document to arib..

nigel: I've changed the due date on this action to 26th August.
... Let's move to the recent issues on github

glenn: There's an open PR: https://github.com/w3c/ttml2/pull/167

nigel: I made one comment on this re the use of the term absolute profile designator.

glenn: That's a good point - I'll try to fix this.
... Does the Repository Manager run any other checks than the IPR one?

nigel: I don't believe so - it might be useful to use a Continuous Integration tool to check
... that each commit results in a successful build of the HTML. Would that be of interest?

glenn: I'd consider it, however I have to go through the generate ED process each time I edit anyway
... so it's not really needed right now.

nigel: Thanks for that PR. I encourage everyone else to have a look and review it.

glenn: By the way, with the PR I intend only to modify the XML source and not the HTML
... version, so that means that if anyone wants to review then they need to run the tool
... to generate the HTML themselves. The reason I don't want to do it in the branch is
... that then I would have to manually merge the XML only. I don't want to regenerate the HTML
... each time because it makes a lot of minor modifications in the file that are not visible
... such as ID generations and timestamps. If we have multiple commits it would likely
... make automatic merging complicated.

nigel: This suggests an elegant solution that we may not have time or inclination to pursue right now
... would be to generate the HTML only in the gh-pages branch.
... For this kind of change I think most folk could review just the XML change. I was
... able to check out the branch, run ant (see https://github.com/w3c/ttml2/blob/gh-pages/spec/README.md) to make the HTML, and review that locally.

glenn: https://github.com/w3c/ttml2/issues/164
... In TTML1 (not SE) we did not use Root Temporal Extent, but External Time Interval
... and it was defined by the external processing context. I'm reviewing notes to understand
... why we changed it. That review will have an impact on what we recommend.
... There are some problems with circular definitions in the current text, in how the body
... element references the root temporal interval, and the root temporal interval references
... the body definition. Maybe the suggestion to redo some of the terminology will be appropriate.

nigel: Yes, it certainly is complex!

glenn: Maybe the reason for differences in interpretation is because we have different
... understandings of what is meant by the term. For example in my mental model the
... idea of a media offset seemed to make sense, and in Nigel's it made less sense.

nigel: Indeed, it is extremely problematic!

glenn: We need to resolve that pretty soon.

pal: Nigel, can you summarise what you mean by media offset and what the problems are?

nigel: It's a value that is used to add or subtract from media time expressions in the
... documents to arrive at some other timeline. My problem with it is that it creates an
... ambiguity with other ways of solving this problem that exist, such as in ISOBMFF.

glenn: It's similar to the referenceBegin that's in N.2 https://www.w3.org/TR/ttml1/#time-expression-semantics-media

pal: I don't understand why we need this. If you want to offset why not just modify all the times in the document?

nigel: By the way, you could just modify the effective value of referenceBegin just by
... adding a begin attribute to the body element.

glenn: You can also put times on style and region elements, which are not descendants
... of body, so that wouldn't be complete.

nigel: I'd like to mention the Safe Crop Area proposal. https://lists.w3.org/Archives/Public/public-tt/2016Jun/0003.html
... [describes the problem statement and proposed solution from the attached PDF document]

glenn: I wonder if we could achieve this using a convention on the region, such as an
... attribute that designates a region as specifying a safe crop area. It would be a little
... simpler because there are already a lot of tools and parsers that already process regions.

nigel: That could be made to work: this is not about where to position relative to the
... root container region though, but about which parts of the root container region must
... be shown. Also you would have to go a long way down parsing the document to find
... this information if present, which would not be ideal.

glenn: I see, yes, you're probably right about that.
... In terms of which namespace to put this in, my rule of thumb is that if a piece
... of information is used formally by the processor in some way then it should be in the
... parameter namespace rather than in metadata.

nigel: I agree.
... This proposal defines some processor behaviour so I would put it into the parameter namespace.

glenn: We already have one parameter, pixel aspect ratio, which has never really been used,
... and one might ask if there are any semantics for what a processor should do with that.
... Up until now people have wondered if it is metadata.

nigel: I think it is a parameter since extent and pixel aspect ratio tell you the shape of the
... root container region, i.e. the display aspect ratio.

glenn: That's true, but now we have display aspect ratio there's over-constraint, so we
... need to define what gives if they don't agree.

nigel: Agreed - I thought we had some text on order of precedence.

glenn: We may do. The text needs to be changed to say Display Aspect Ratio in place of Storage Aspect Ratio.

nigel: There's an issue I believe. https://github.com/w3c/ttml2/issues/30
... Any other comments on SCA?

glenn: We should also factor in Mike's comments with the SMPTE documents.

nigel: Thanks for the reminder. My reading of those is that the documents Mike referenced
... explain the background for how this problem situation can occur but are orthogonal
... to the SCA proposal - the SCA proposal does not duplicate the active format descriptor
... semantics but provides for dealing with some of the scenarios it can result in.
... Returning to https://github.com/w3c/ttml2/issues/166 (duplicate designators)
... is there any semantic ambiguity introduced by having duplicates?

glenn: Interesting. If you have any(X Y X), and on the first attempt to resolve X you get
... an access error, and proceed to Y and get "not available" too then you would proceed
... to "X" again which now may be available. Because there's a sequential access operation
... there you might end up with different semantics. From a cleanliness perspective, we
... also don't allow attributes on XML elements with duplicated information even though
... you could argue that they're semantically equivalent. I prefer not to allow duplicates
... unless I can think of some kind of rational interpretation of it. That was my conclusion.
... Further, we've already implemented that semantic in TTV (not yet checked in).

nigel: Well you may want to respond to my comment asking this on the github issue.

glenn: Ok

nigel: Thanks all, we're out of issues to discuss for today, so I'll adjourn. [adourns meeting]

s