{minutes} TTWG Meeting 2016-07-14

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

{minutes} TTWG Meeting 2016-07-14

nigelmegitt
Thanks all for attending today's meeting. Minutes are available in HTML format at https://www.w3.org/2016/07/14-tt-minutes.html 

In text format:

   [1]W3C

      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

14 Jul 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/07/14-tt-irc

Attendees

   Present
          Glenn, Harold, Nigel, Pierre

   Regrets
          Mike, Andreas, Frans, Thierry

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This meeting
         2. [5]TTML1 & TTML2 issues, actions, PRs, editorial
            actions etc
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

   <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>
   [8]http://www.w3.org/AudioVideo/TT/tracker/actions/472

      [8] http://www.w3.org/AudioVideo/TT/tracker/actions/472

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

      [9] 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>
   [10]http://www.w3.org/AudioVideo/TT/tracker/actions/443

     [10] 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
   [11]https://github.com/w3c/ttml2/issues/119

     [11] https://github.com/w3c/ttml2/issues/119

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

     [12] https://github.com/w3c/ttml2/issues/119

   <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:
   [13]https://github.com/w3c/ttml2/pull/167

     [13] 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
   [14]https://github.com/w3c/ttml2/blob/gh-pages/spec/README.md)
   to make the HTML, and review that locally.

     [14] https://github.com/w3c/ttml2/blob/gh-pages/spec/README.md)

   glenn: [15]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.

     [15] https://github.com/w3c/ttml2/issues/164

   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
   [16]https://www.w3.org/TR/ttml1/#time-expression-semantics-medi
   a

     [16] 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.
   [17]https://lists.w3.org/Archives/Public/public-tt/2016Jun/0003
   .html
   ... [describes the problem statement and proposed solution from
   the attached PDF document]

     [17] https://lists.w3.org/Archives/Public/public-tt/2016Jun/0003.html

   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.
   [18]https://github.com/w3c/ttml2/issues/30
   ... Any other comments on SCA?

     [18] https://github.com/w3c/ttml2/issues/30

   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 [19]https://github.com/w3c/ttml2/issues/166
   (duplicate designators)
   ... is there any semantic ambiguity introduced by having
   duplicates?

     [19] https://github.com/w3c/ttml2/issues/166

   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

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [20]scribe.perl version
    1.144 ([21]CVS log)
    $Date: 2016/07/14 15:13:16 $

     [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [21] http://dev.w3.org/cvsweb/2002/scribe/