W3C home > Mailing lists > Public > public-tt@w3.org > September 2016

Minutes from today's TTWG meeting

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Mon, 19 Sep 2016 17:32:07 +0000
To: Timed Text Working Group <public-tt@w3.org>
Message-ID: <5941EAB8802D6745A7D363D7B37BD1F773F85F33@bgb01xud1012>
Thanks all for a very productive first day of our Lisbon TPAC face to face meeting. Minutes can be found in html format at https://www.w3.org/2016/09/19-tt-minutes.html

We made 1 resolution:

RESOLUTION: If we do not move WebVTT to CR in this Charter period then we will not include it in any new Charter.

The review period for this resolution under our Decision Process ends on Monday 3rd October.

Minutes in text format:


   [1]W3C

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

                Timed Text Working Group Teleconference

19 Sep 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/09/19-tt-irc

Attendees

   Present
          Rohit, Nigel, Glenn, Thierry, Dae, Andreas, David,
          Pierre

   Regrets
   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]Agenda bash
         2. [5]Plan for Joint Meeting with Web & TV IG
         3. [6]WebVTT stuff
         4. [7]Tagging
         5. [8]TTML1 Errata
         6. [9]TTML2 Pull Requests
         7. [10]IMSC 2
         8. [11]Agenda bash
         9. [12]TTML2 implementation work
     * [13]Summary of Action Items
     * [14]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

Agenda bash

   group: [discusses topics on meeting page
   [15]https://www.w3.org/wiki/TimedText/tpac2016#Schedule

     [15] https://www.w3.org/wiki/TimedText/tpac2016#Schedule

   <glenn> +Present Glenn

   nigel: Seems like the topics list is pretty close to the order
   we want to cover stuff in.

Plan for Joint Meeting with Web & TV IG

   nigel: We are meeting the Web & TV IG at 11, so need to provide
   an update etc.
   ... Discusses proposal for Web & TV IG consisting of update on
   our work in TTML,
   ... audio description requirements, issue of relationship
   between encoded video, media player
   ... and timed text presentation; live contribution and BBC
   subtitle guidelines. (last two points from Nigel with a
   different hat on!)

   andreas: I have some slides to discuss on TextTrackCue
   interface support for different formats in HTML5.
   ... I would also point to the unconference session on this on
   Wednesday. They may also
   ... want to log this as work that needs doing by a Web & TV IG
   task force.

   nigel: Good idea, let's do that ahead of my stuff on AD, live
   contribution etc.

   andreas: [Previews slides] including missing MIME type on track
   element in HTML5

   nigel: Thanks, let's do that after the TTWG update and if
   there's time to hand back to me for the other parts then let's
   do that.

WebVTT stuff

   david: Number one priority is to find a new Chair to cover this
   topic - I've indicated already to
   ... plh etc that I don't have the time to devote to this.

   glenn: What's the status of implementation work?

   david: At Apple it's bug fixing, keeping up with customers.

   glenn: On the Chrome and webkit list I don't see much activity.
   I am not following mozilla or Edge.
   ... What's the status in other groups e.g. MPEG referencing
   WebVTT?

   david: The Chair does need to make progress on moving it to Rec
   so it can be normatively referenced.
   ... There is implementation work excluding region support in
   many implementations.

   andreas: I think there have been updates to the specification
   that have not been reflected in
   ... implementations so this is a problem.

   nigel: I've noticed that too - Simon made some really good
   changes around 10-11 months ago,
   ... which i suspect have not been implemented. I'm not sure
   about the status of editing to
   ... address the readability review feedback.

   david: Apple's implementations predate those changes.

   andreas: It's hard to know if those changes will ever make it
   into implementations.

   nigel: From a BBC perspective there are features that are
   essential for accessibility that look
   ... like they would have to be put at risk for CR due to lack
   of implementation, so that would
   ... be a "red flag" for me.
   ... For example the BBC's editorial guidelines at
   [16]http://bbc.github.io/subtitle-guidelines/
   ... cannot I believe be met by most implementations of WebVTT
   right now.

     [16] http://bbc.github.io/subtitle-guidelines/

   action-475?

   <trackbot> action-475 -- Nigel Megitt to Contact the chair of
   the web & tv ig to ask about schedule and joint meeting time.
   -- due 2016-07-28 -- OPEN

   <trackbot>
   [17]http://www.w3.org/AudioVideo/TT/tracker/actions/475

     [17] http://www.w3.org/AudioVideo/TT/tracker/actions/475

   nigel: oops I meant:

   action-473?

   <trackbot> action-473 -- Thierry Michel to Contact co-chairs
   and essential parties on how to move forward on vtt; need an
   action plan -- due 2016-06-30 -- OPEN

   <trackbot>
   [18]http://www.w3.org/AudioVideo/TT/tracker/actions/473

     [18] http://www.w3.org/AudioVideo/TT/tracker/actions/473

   nigel: Thierry did this, but I don't believe we have an action
   plan.

   david: We need a suitable volunteer to go through the review
   comments and respond.

   thierry: The Community Group has looked into the review
   feedback - about 30 comments
   ... have been discussed: that's the current status. Now those
   comments need to be approved
   ... by the TTWG (and discussed) and then we should send those
   responses to the commenters.
   ... At some point we need to coordinate between the CG and the
   WG to progress those.
   ... This has not changed for more than a year, probably because
   some people involved have
   ... left and Simon does not participate actively in the WG. We
   are experiencing joint work with
   ... a CG and a WG and we need to invent a process to deal with
   this.

   nigel: This works both ways - the WG also has not scheduled any
   effort to work on this.

   andreas: I'm not really convinced that the CG exists as a
   traditionally defined group.

   nigel: Shall we close the action? The "contact the chairs" part
   is done, we're missing an action plan.

   david: Leave it open.

   action-473: Discussed in TTWG F2F 2016-09-19 - need a volunteer
   to progress this, possibly a new Chair.

   <trackbot> Notes added to action-473 Contact co-chairs and
   essential parties on how to move forward on vtt; need an action
   plan.

   action-396?

   <trackbot> action-396 -- David Singer to Produce evidence of
   request for wide review for webvtt, for the archive -- due
   2015-04-17 -- OPEN

   <trackbot>
   [19]http://www.w3.org/AudioVideo/TT/tracker/actions/396

     [19] http://www.w3.org/AudioVideo/TT/tracker/actions/396

   david: I have not yet done this.

   action-396: TTWG F2F meeting 2016-09-19: David has not been
   able to do this yet.

   <trackbot> Notes added to action-396 Produce evidence of
   request for wide review for webvtt, for the archive.

   nigel: TO be controversial/challenging, WebVTT has been on our
   Charter since 2013 and we
   ... have made very little progress. Should we drop it?

   david: If we don't complete it in this Charter period [end
   March 2018] then we should not
   ... recharter it - I propose that as a resolution.

   PROPOSAL: If we do not make progress on moving WebVTT to
   Recommendation in this Charter period we do not intend to
   include it on any rechartering.

   thierry: That's a final step - I think we should be aiming to
   move to CR well before that.

   david: I agree.

   glenn: We could publish it as a WG Note, to make it easier for
   external people to reference.

   nigel: This is a lot easier.

   thierry: That would probably be a final step to that work.

   nigel: In fact publishing a Note is a process requirement if we
   stop working on it.

   thierry: We would do that if we removed it from the Charter.

   glenn: It would be helpful to have a document that does not
   have the word "Draft" in it.

   thierry: I'm happy to help with the wide review; that's one
   thing. The second thing is the CR.
   ... We could stay in CR for a couple of years and monitor
   implementation work, or we could
   ... remove non-implemented features. Right now there are a lot
   of features that are not
   ... implemented. That's something we could do in parallel.
   Maybe it is not useful to have
   ... comments on features that we are likely to drop.

   nigel: I want to signal that if we have to drop features that
   are essential for accessibility then
   ... I will have to object to it progressing.

   thierry: There's also a lack of specification text on
   integrating CSS. We could maybe save time
   ... by not addressing issues that we know are unlikely to be
   implemented in the next two years.

   group: discussion about who is interested in contributing to
   implementation work etc and therefore progressing responses to
   comments.

   RESOLUTION: If we do not move WebVTT to CR in this Charter
   period then we will not include it in any new Charter.

   andreas: We could mention the TTML to WebVTT mapping document
   in the Web & TV IG meeting.
   ... We published it last year and are awaiting implementation
   comments. We are waiting for a
   ... stable reference for WebVTT in order to proceed.

   thierry: You would expect to see at least a CR document?

   andreas: CR would clearly indicate a stable set of features you
   can map against.

Tagging

   david: DASH and the MP4 file format have a way to tag the kind
   of role of a track, using a URI
   ... to identify the vocabulary used, and then a term from that
   vocabulary. I need a URI to
   ... refer to the @kind vocabulary in the HTML5 specification,
   and there isn't one.

   pierre: There is one but it is not complete, specified in DASH.

   david: It is not specified in the HTML document itself.

   pierre: That's correct. As long as we can reference the one in
   DASH that can be used.

   david: Agreed there is a DASH vocabulary.

   pierre: So the request to add one to HTML is not required for
   MPEG CMAF because the DASH one can be used.

   david: I got agreement from WHATWG and the Web Platform WG for
   about:html-kind as the URI
   ... that refers to the @kind vocabulary in the HTML
   specification.
   ... And I have registered that with IANA.
   ... I'm waiting for that URI to appear in a revision of the Web
   Platform docs. When it is then
   ... I will update the IANA form.

   nigel: It's good to have that but I would note that in my view
   the kind vocabulary is terrible.

   glenn: There are some semantics associated, such as prevention
   of display of metadata tracks by the UA.

   david: I would agree that the HTML vocabulary is both under-
   and over-specified simultaneously! (in different ways)

   nigel: In my view it is insufficiently rich to describe the
   purpose and intent of the track data.

   pierre: It would be great if as making the HTML vocabulary more
   official we could also fix it.

   david: I support that.
   ... CMAF does prefer DASH at the moment - it says to use the
   DASH term if it supports what you want to do.

   nigel: I also note that we have not addressed how to extract
   something equivalent to kind
   ... within a timed text document so that it can be extracted
   and used to embed into a host HTML page.
   ... We did address language recently, but not kind.

   david: Some people want to manage external manifest files, but
   I'm in favour of self describing documents.
   ... I'm also aware of ongoing discussions about tags for easy
   to read captions (mandated by FCC) and karaoke.

   pierre: There is a very specific definition of those two terms
   in karaoke.

   glenn: In TTML2 we have a named metadata item for easy reader.
   There's nothing on karaoke per se.
   ... nothing that uses that term in TTML2.

   nigel: [adjourns for a break] - let's meet in Auditorium IV at
   1100 for our update to Web & TV IG.

   <nigel_> nigel: Joint meeting - see #webtv

TTML1 Errata

   nigel: Are there any other errata other than for backgrounds on
   spans and lines?

   pierre: The only thing I'd mention is that the computed style
   resolution for % is very well defined
   ... but the computed style for em is not so clear when you say
   e.g. tts:fontSize="2em" but
   ... that is with respect to the current font size but that is
   not well defined in TTML1. I assume
   ... it is relative to the parent element's font size but it
   does not say that clearly.

   glenn: I would consult TTML1 and then go back and reference
   XSL-FO which would take me
   ... to CSS2. Without having done a recent review of that I
   don't know off the top of my head
   ... but I'm pretty sure you're right - it would have to make
   use of the computed font size of
   ... the parent element.

   pierre: Notice that we already have issue #206 on the ttml1
   repo which is a bug about
   ... specifying em units for fontSize on region.

   nigel: That sounds very similar.

   glenn: Right now there are 23 open issues on TTML1 so I would
   expect that there are some
   ... errata to be written for those and they probably also need
   to be fixed in TTML 2 also.

   pierre: I can go ahead and create an issue for this.

   glenn: Go ahead - also refer to #206 - it may be related but
   more general.
   ... I think I propose that it should be in relation to 1c.

   pierre: That was my first thought, but looking at XSL-FO I
   think it is probably more like %.

   nigel: Okay, so the one on the agenda is:
   [20]https://github.com/w3c/ttml1/issues/209

     [20] https://github.com/w3c/ttml1/issues/209

   andreas: I think there has not been much progress since we last
   discussed it. We said we need
   ... more investigation to find a good solution. I want to point
   to something related.
   ... This problem about gaps between lines has been addressed by
   the HbbTV 2.0.1 spec
   ... which a lot of televisions will implement. At the moment
   that is not really interoperable
   ... and compatible with IMSC 1 so we should pay attention to
   it.
   ... References spec text from HbbTV 2.0.1 that, specific to
   EBU-TT-D 1.0 defines that
   ... where the lineHeight is "normal" or <125% the background of
   each generated inline area
   ... shall be rendered such that there are no gaps between the
   rendered backgrounds of
   ... adjacent lines.

   glenn: We have a quasi default of doing what CSS does, which is
   different from what this suggests.
   ... This mandates behaviour that is at variance with the XSL-FO
   and CSS behaviour.

   andreas: Yes.

   glenn: By the way issue #209 on the TTML spec has a length
   discussion on this.
   ... The bottom line in my reading is that the height of an
   inline area in CSS is implementation defined.
   ... Different implementations have fine tuned themselves to be
   consistent with each other, outside of any spec.

   nigel: You can see an editorial requirement example of this at
   [21]http://bbc.github.io/subtitle-guidelines/#Background-size

     [21] http://bbc.github.io/subtitle-guidelines/#Background-size

   glenn: I agree that we need to nail this down - also see issue
   #212 in TTML1.

   nigel: [22]https://github.com/w3c/ttml1/issues/212
   ... [23]https://github.com/w3c/ttml1/issues/209

     [22] https://github.com/w3c/ttml1/issues/212
     [23] https://github.com/w3c/ttml1/issues/209

   pierre: A browser based CSS implementation would display a gap?

   glenn: Correct

   andreas: There are scripting techniques for getting around
   this.

   pierre: If we feel this is a common requirement for
   accessibility then it needs to be addressed in the CSS WG

   glenn: I've had a detailed offline discussion with Bert Bos
   about this and he pointed out that
   ... one of the advanced level 4 modules might at some point be
   able to deal with this.
   ... There are a whole bunch of assumptions in CSS on inline
   non-replaceable areas, for example
   ... you cannot specify the content height manually. The height
   property explicitly does not
   ... apply. That was the first problem we ran into, because we
   wanted the height of the content
   ... box to extend to the line area. Somewhere I proposed a mode
   for the style engine to use
   ... different semantics for the height of content areas. The
   question is can you have a profile
   ... that defaults the parameter to a particular value.

   nigel: The pressing need here is to issue some statement on
   this for TTML1.

   piere: I recall that some people use a style where they do
   actually want the gap.

   andreas: yes, for example if you have the lineheight at 200%
   you don't want such a big background area.

   pierre: In CSS can you always add padding to every line?

   glenn: You can but the problem is you cannot determine at
   authoring time what value to add.
   ... At first order we should document more carefully what the
   current situation is in TTML1.
   ... That may allow people to come up with no-gap semantics. We
   could define the default
   ... semantics to be the no-gap scenario but if we do that we
   need to allow the author to define
   ... the other behaviour. If we change the default now what
   would that break?

   nigel: I understand that the content rectangle is not well
   defined?

   glenn: It is not, but all the browser implementations do it
   roughly the same way.

   nigel: Could we add an informative note via an erratum to say
   that the content rectangle is
   ... not well defined but is commonly implemented so that it
   does not go to the line height?

   pierre: That's not what I'm hearing. I think CSS needs to
   address this.

   glenn: I'm worried that we cannot easily go back and
   retroactively define the content height
   ... to never show a gap.

   pierre: It would be easier to do that if it were not that some
   folk like the gap.

   glenn: In TTML2 we can add a new mode that drives that, but in
   TTML1 what can we do?

   andreas: This requirement for no gaps came from accessibility
   guidelines to get proper presentation.
   ... The minimum we could say is that some specifications could
   define this.

   pierre: If someone is overriding that rendering it needs to be
   flagged.

   andreas: That will not change, I think this is more of an
   interoperability problem.
   ... There is an initial step e.g. for an IMSC 1.1, and then a
   long term TTML2 solution.
   ... For now we should say something about this in TTML1.

   pierre: +1

   andreas: I would also hope for a liaison to respond to this.

   glenn: We can note that the algorithm for content height is not
   concretely defined and that
   ... browsers do behave the same with current CSS
   implementations and will introduce a gap.
   ... If we do want a new TTML1 feature we could write a short
   specification introducing a
   ... ttsx namespace style that is interpreted in a particular
   way.

   andreas: Ideally if there is a proper parameter to control this
   it should be defined in this group.

   nigel: +1

   glenn: That would be an official extension to TTML1, which we
   could say maps to a particular
   ... syntax and semantic in TTML2.
   ... That might be an approach.

   pierre: If there is an urgent need to address real problems we
   should address it in IMSC 1.1.

   glenn: I've heard 3 things: 1. Clarify TTML1 with an errata -
   we can do that non-controversially.
   ... 2. We can define new mechanisms in TTML2 - we can do that
   no problem.
   ... 3. More controversially, define a new extension style for
   TTML1. That creates another fork
   ... in the implementation space.

   andreas: The target when this was discussed was an IMSC 1.1
   version. If that is possible we
   ... should do that.

   pierre: Absolutely. The question is if there is an urgent need
   to resolve an industry problem now.
   ... The worst thing would be to make a change that does not
   solve the problem.

   andreas: HbbTV has solved this for now - it would be
   interesting to know if this breaks
   ... current implementations.

   pierre: it would be good to have a formal communication with
   HbbTV about this issue.
   ... It is essential that HbbTV is encouraged to communicate
   their requirements to this group and we should be welcoming of
   this, even if we make the initial communication.

   andreas: We should also be clear that it is needed for
   interoperability to establish this communication channel.

   nigel: Notes that independent of HbbTV the BBC raised this
   issue on TTML2 and andreas opened the equivalent on TTML1.
   ... I want to come back to what we can do here.

   andreas: There's the formal comms with HbbTV, an errata for
   TTML1, and a discussion about
   ... how to fix for TTML2. If there is no formal requirement for
   this then it will not happen in IMSC 1.

   pierre: BBC has raised this for TTML2, but the timescale for
   that is very different than for TTML1.
   ... To make a change on TTML1 requires a higher threshold, so
   if there is a group such as
   ... HbbTV that needs this in the short term then we should do
   it.

   <scribe> ACTION: nigel Draft a liaison to HbbTV requesting
   further information and proposing an option e.g. to extend IMSC
   1 to allow signalling of background height on span, and request
   timelines etc. [recorded in
   [24]http://www.w3.org/2016/09/19-tt-minutes.html#action01]

     [24] http://www.w3.org/2016/09/19-tt-minutes.html#action01]

   <trackbot> Created ACTION-478 - Draft a liaison to hbbtv
   requesting further information and proposing an option e.g. to
   extend imsc 1 to allow signalling of background height on span,
   and request timelines etc. [on Nigel Megitt - due 2016-09-26].

   nigel: Okay, that works; I would also still like to see the
   erratum on TTML1 to provide the context
   ... for any update to IMSC 1 to allow signalling this
   behaviour.

   glenn: I have added a comment on the issue at
   [25]https://github.com/w3c/ttml1/issues/209#issuecomment-247973
   673

     [25] https://github.com/w3c/ttml1/issues/209#issuecomment-247973673

   nigel: Thank you!

   glenn: Of course that doesn't explain what to do about it, but
   that's for [26]https://github.com/w3c/ttml2/issues/150
   ... We have consensus in TTLM2 to solve this?

     [26] https://github.com/w3c/ttml2/issues/150

   nigel: Yes please!

   glenn: I have a bpd content proposal where I define 7 possible
   values.

   nigel: That may be more than we need - let's review.
   ... Thanks for the good discussion everyone, let's adjourn for
   lunch and return at 1400.

TTML2 Pull Requests

   nigel: First up, [27]https://github.com/w3c/ttml2/pull/177 Add
   tts:background{Clip,Extent,Origin}

     [27] https://github.com/w3c/ttml2/pull/177

   glenn: This is for image rendering support - I missed a couple
   of items from CSS: there is
   ... an editorial note to add them.
   ... I ended up using backgroundExtent rather than
   backgroundSize for consistency.

   nigel: Just a note on reviewing the PRs - they don't include
   the built HTML so it's hard to
   ... review or diff. I'd like a CI tool to build the HTML
   automatically so we can review it.

   glenn: I could do the build and check in the built HTML but
   then on pulling I would have to
   ... remove it and build it again for gh-pages.
   ... I'll go ahead and make a change to make these easier to
   review.

   <glenn>
   [28]https://www.w3.org/TR/css3-background/#the-background-origi
   n

     [28] https://www.w3.org/TR/css3-background/#the-background-origin

   nigel: So now we have backgroundOrigin as well as
   backgroundPosition?

   glenn: We may want to rename these!

   nigel: (notes that this looks analogous to origin and position
   but is not)

   glenn: backgroundOrigin defines where the background is drawn
   relative to the content.
   ... This is as defined in CSS3 backgrounds and borders - it's
   the same semantic.
   ... I took off the -box suffix that's on CSS3.

   nigel: I sense that there are some changes needed here to clear
   up the names and make them
   ... less potentially confusing. Also I'd encourage review of
   this in the context of IMSC 2
   ... if we want to support image placement in more detail.

   pierre: This does not express how you would use SMPTE
   background image in IMSC 1.

   glenn: That's actually mapped to the image element.

   pierre: yes.

   glenn: However we did define background image also in TTML2 and
   these attributes
   ... I believe fully define the semantics for background images.
   ... In the case of a foreground image these don't come up
   because they define the content
   ... rectangle. There's never a box in which to position it -
   that only applies when the image
   ... is used for the background. Also bear in mind that
   background images may be repeated
   ... in x and y directions, which can never happen with
   foreground images.
   ... For foreground image size you would use bpd and ipd rather
   than backgroundExtent.
   ... I need to think if it would ever be applicable to have the
   same semantic as backgroundExtent
   ... on a foreground image. I want to see if CSS allows that
   property on the image element
   ... in HTML and what does it mean.

   nigel: Just considering the use cases for this - one that comes
   to mind is the use of a
   ... graduated fill background image that is animated to move
   along behind foreground text
   ... for karaoke usage. Do these semantics support that?

   glenn: Yes I think you could animate the x and y positions,
   either discretely or continuous.

   nigel: The conclusions for the time being are 1) that more
   thinking is needed for the names
   ... and 2) whether backgroundExtent can apply to foreground
   images.
   ... For the hard of thinking, some example images etc would
   really help, since the terminology
   ... has a lot of repetition that makes it hard to understand
   the differences.
   ... I've added some notes to the issue.
   ... Moving on to Add support for rounded borders by introducing
   <border-radii> compone...
   ... [29]https://github.com/w3c/ttml2/pull/179

     [29] https://github.com/w3c/ttml2/pull/179

   nigel_and_glenn: [discussion of single value processor
   semantics for border radii without consensus emerging]

   glenn: The more interesting case is the one raised in the issue
   [30]https://github.com/w3c/ttml2/issues/176

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

   nigel: explains images in issue

   glenn: I would suggest an optional token for this and a default
   behaviour in case nothing is specified.
   ... We also have to set up some context for when it might apply
   - it would not apply when
   ... all the line areas are the same length - you are proposing
   a process for merging the
   ... background areas.

   nigel: Yes

   glenn: Would you allow me to merge this PR and address your
   issue as a later iteration?

   nigel: Yes, that allows progress.

   glenn: I agree with the issue - I might consult others in CSS
   land for their opinions too.
   ... It may even be in background and borders 4, I need to check
   ... How to specify merged background areas with radii when
   there is no corner is harder
   ... to specify - I'm sure it's possible but it requires a bit
   of thought.

   nigel: Agreed!
   ... Okay, next one is Add missing two component expression to
   <position> value syntax.
   [31]https://github.com/w3c/ttml2/pull/180
   ... I added a comment about the ambiguity here.

     [31] https://github.com/w3c/ttml2/pull/180

   glenn: The ambiguity is resolved by the two value to four value
   mapping tables.
   ... The last entry is ambiguous I agree since it does not
   distinguish the lengths

   nigel: Even if this is normative and clear I would prefer at
   least note to point people at the
   ... order preference.

   glenn: I'll see what I can do while I'm also dealing with the
   last line in the table.

   nigel: Let's take a break - back here at 1545
   ... Next is Remove cea{608,708} prefix from named items.
   [32]https://github.com/w3c/ttml2/pull/182

     [32] https://github.com/w3c/ttml2/pull/182

   glenn: I had the same question in my mind as Nigel, whether or
   not any of the deprefixed
   ... names had any similarity to the non-prefixed name. The
   programName and programType
   ... seem to be likely, the others not.
   ... The ones that had cea prefixes need to be syntactically
   compatible with SMPTE-TT.
   ... I can not simply remove the reference to 608 or 708 from
   the definition of them without
   ... sacrificing syntactic specificity.

   nigel: And there's an editorial task to add the source
   definitions?

   glenn: That's right.
   ... I'm pretty sure that programName is just a string and no
   more restricted. The originalProgrammeTitle
   ... is probably the same semantic.
   ... We also need to check with Mike Dolan since he was involved
   in defining these in
   ... SMPTE-TT. I think we should be able to merge programName
   and originalProgramTitle
   ... probably. We have to choose which token to end up with - I
   don't have a strong preference.
   ... My preference is to add a prefix back, but just make it cea
   or cta (remove the 608 or 708)
   ... and we could add it for EBU also.

   nigel: An observation here is that building the named items
   into the TTML2 spec gives us a
   ... potential problem in that it makes it harder to update the
   list later. A common pattern
   ... is to reference an external list or classification scheme
   which can be updated independently.
   ... Since none of these named items normatively affects
   processing this should be okay.
   ... This is a bit like the role registry approach in TTML1.

   glenn: In TTML1 we had a requirement to prefer Dublin Core, and
   after much debate we took
   ... a minimalist approach and hardly defined anything. Then
   SMPTE-TT came along and defined
   ... a whole bunch of metadata items for 608 and 708 that were
   thought to be important.
   ... Since one of the nominal driving factors for TTML2 is to
   support all the extensions in
   ... SMPTE-TT we ended up adding these in.

   andreas: I think the most practical solution is to reference a
   document that we maintain that
   ... defines our unqualified namespace items and informatively
   links to other sources of
   ... namespace qualified items in other organisations'
   namespaces.

   glenn: That sounds like a plan.

   nigel: Same here.

   glenn: I think we should leave in usesForced and
   alternativeText

   nigel: Even those we do not need to be in the specification

   glenn: I think we want to refer to them elsewhere in the spec
   so I'd like to keep those two
   ... unqualified names in the spec.

   andreas: Ok, if they depend on these.

   glenn: Others that we have not defined yet we can bind to a
   namespace and offer a template
   ... for the future to define new named items.
   ... That would simplify this work quite a bit.
   ... I'll add a note to the issue with that plan.
   ... I didn't abbreviate alt text so I had it as alternateText -
   what's the view?

   pierre: Keep it as close as possible to IMSC 1.

   nigel: yes, happy with altText.

   glenn: ok

   nigel: We have essentially covered Add alternateText named
   metadata item (#107). [33]https://github.com/w3c/ttml2/pull/183

     [33] https://github.com/w3c/ttml2/pull/183

IMSC 2

   pierre: We are beginning to get industry feedback from IMSC 1
   implementation.

   nigel: There seem to be some preconceptions in the wild about
   what IMSC 2 will be. I'd like
   ... us to collate requirements.

   pierre: I would happily collate requirements for IMSC 2.

   glenn: I think there will be a continuing requirement for
   images to deal with internationalisation
   ... cases that not all clients will be able to support.

   <scribe> ACTION: pal Refactor the IMSC repository in
   preparation for future versions of IMSC. [recorded in
   [34]http://www.w3.org/2016/09/19-tt-minutes.html#action02]

     [34] http://www.w3.org/2016/09/19-tt-minutes.html#action02]

   <trackbot> Created ACTION-479 - Refactor the imsc repository in
   preparation for future versions of imsc. [on Pierre-Anthony
   Lemieux - due 2016-09-26].

   glenn: Having them in one repository helps with issue tracking
   but you should use labels of
   ... some kind to distinguish between the different versions.

   pal: At the root will be a roadmap document for all the
   versions of IMSC.
   ... As soon as I get requirements for IMSC 2 I will start a
   requirements document too.

   nigel: It's not from BBC but Ruby seems obvious.

   pierre: Yes I hear that a lot, also HDR and tate chu yuko.
   Disparity is another one.

   nigel: Also Wide Color Gamut?

   pierre: Yes. Also background area between lines.

   nigel: I would add the safe crop area stuff too.

   andreas: As well as asking for requirements it would be good to
   ask for the use case and the
   ... problem that needs to be solved, in some detail.

   pierre: So yes, HDR, all east asian layout.

   rohit: Any mention of the condition attribute?

   pierre: No not yet. I've heard people wanting to do responsive
   design, but I'm not sure we're there yet.

   nigel: What about continuous animation?

   pierre: Not yet.

   nigel: Seems strange to me based on historical BBC research to
   have disparity but not continuous animation.

   andreas: We should check what east asian organisations need to
   do.

   dae: I'd like to know if there are any parts of TTML2 that folk
   think might need to change. Ruby for example?

   pierre: I'd like to be really specific about all the Ruby
   features in a pedantic way.

   glenn: All the TTML2 layout features were driven from existing
   content in lambda cap. it is
   ... easy to say what was not driven from lambda cap.
   ... It is easy to enumerate all the different Ruby features -
   look at TTML2 from
   ... 10.2.30 tts:ruby to 10.2.37 tts:rubyPreserve also
   10.2.40 tts:textCombine
   ... 10.2.41 tts:textEmphasis and 10.2.43 tts:textOrientation.
   ... All those were directly driven by lambda cap. There are a
   couple that were not:
   ... rubyOverflow, rubyOverhand and rubyOverhangClass.

   rohit: Also rubyReserve?

   glenn: Yes. Overflow and overhang came out of the Japanese
   requirements as well as how
   ... to handle some cases that were not obvious.

   pierre: Thanks!

   nigel: Do we have feature designators for these yet?

   glenn: There's an editorial note in E.1 for adding those.

   group: [discussion of structure of specification, areas of
   TTML2 that may be relatively more 'risky', how to make progress
   etc.]

   dae: Can we revisit the initial construct in TTML2 tomorrow?

Agenda bash

   group: plans ahead for tomorrow, updates agenda.

TTML2 implementation work

   glenn: Skynav's TTT set of tools could be viewed as 1-3
   implementations. It's a layered
   ... system - the validation layer at the bottom could be
   considered a transformation implementation.
   ... TTX above that has one module that translates into an ISD
   sequence. For example it can
   ... take IMSC1 or SMPTE-TT documents and turn them into TTML2
   ISDs. Then the next
   ... layer is TTPE that implements formatting semantics.

   rohit: At Netflix we are building a TTML2 oriented pipeline.
   The idea is to take TTML2 source
   ... documents, convert them into a canonical form (probably
   TTML2 ISD) and then use them
   ... to generate output formats including WebVTT and rendered
   subtitles.
   ... Depending on the test vector set for TTML2 Netflix may be
   able to meet 40-50% of the
   ... tests for implementation.

   glenn: I'd also like to add: in terms of presentation semantics
   implementation in TTPE for
   ... TTML2 features, the only new features it does not yet
   support are the use of referenced
   ... external fonts, audio and disparity. Everything else that's
   new in TTML2 it supports already
   ... from a presentation semantic. There might be some fine
   points to some of the features
   ... that we are still tweaking. We have test content for all of
   those features that we are using
   ... to generate presentable output in either images or SVG. So
   we are way ahead on implementation
   ... of presentation and we have test content for most all of
   it. Our schedule for finishing
   ... implementation work on TTML2 is scheduled to be finished
   early March 2017.

   thierry: The horizontal review groups request review
   opportunity as soon as possible.

   nigel: In fact I should trigger that process straight away.
   ... Wide review is even wider than that.

   thierry: We should start to initiate that to make sure there is
   enough time.

   glenn: I'd like to have a version ready for a new WD by early
   October.

   thierry: Remember that we can limit the scope of review only to
   the additional features in
   ... TTML2 that are new relative to TTML1.

   pierre: Remember also for wide review you have to factor in
   time to respond to comments.
   ... For the east Asian text layout there's an action to contact
   ARIB specifically.

   nigel: We will also need horizontal review. As a minimum I
   should contact the horizontal review groups and request time on
   their schedule for a new document early November.

   <scribe> ACTION: nigel Request schedule time for horizontal
   review of TTML2 [recorded in
   [35]http://www.w3.org/2016/09/19-tt-minutes.html#action03]

     [35] http://www.w3.org/2016/09/19-tt-minutes.html#action03]

   <trackbot> Created ACTION-480 - Request schedule time for
   horizontal review of ttml2 [on Nigel Megitt - due 2016-09-26].

   glenn: Why don't I give you a list of new features to start
   reviewing?

   nigel: Good idea.

   <scribe> ACTION: gadams Provide nigel with a list of new
   features in TTML2 to begin reviewing [recorded in
   [36]http://www.w3.org/2016/09/19-tt-minutes.html#action04]

     [36] http://www.w3.org/2016/09/19-tt-minutes.html#action04]

   <trackbot> Created ACTION-481 - Provide nigel with a list of
   new features in ttml2 to begin reviewing [on Glenn Adams - due
   2016-09-26].

   glenn: How would it be if we have a solid working draft for
   wide review by Nov 1?

   nigel: Sounds good to me.

   glenn: And how about moving to CR by the end of the year?

   nigel: It's ambitious but we can try.
   ... Looking at the picture on
   [37]https://www.w3.org/wiki/TimedText/Publications it shows
   ... a FPWD of IMSC 2 back in June, but I think from today we
   have decided to collate
   ... industry requirements and then maybe base it on the TTML2
   CR perhaps?

     [37] https://www.w3.org/wiki/TimedText/Publications

   pierre: We should aim to make IMSC 2 based solely on industry
   requirements but we can
   ... certainly set a new date - I'm comfortable with that,
   partly as a challenge to folk who
   ... want IMSC 2 - we need to get going on it.

   nigel: Agreed. Shall we say IMSC 2 FPWD by Dec 1?

   pierre: Sounds great to me, maybe even earlier.

   nigel: Ok let's leave it at that for now and if we can make it
   earlier, great.

   dae: Can an implementation satisfy both TTML2 and IMSC 2?

   nigel: Yes.
   ... Ok we're out of time for today, thanks all. Time to adjourn
   for tomorrow.

   andreas: Can we make sure we cover IMSC 1 implementation work
   tomorrow?

   nigel: yes let's do that.
   ... [adjourns meeting]

Summary of Action Items

   [NEW] ACTION: gadams Provide nigel with a list of new features
   in TTML2 to begin reviewing [recorded in
   [38]http://www.w3.org/2016/09/19-tt-minutes.html#action04]
   [NEW] ACTION: nigel Draft a liaison to HbbTV requesting further
   information and proposing an option e.g. to extend IMSC 1 to
   allow signalling of background height on span, and request
   timelines etc. [recorded in
   [39]http://www.w3.org/2016/09/19-tt-minutes.html#action01]
   [NEW] ACTION: nigel Request schedule time for horizontal review
   of TTML2 [recorded in
   [40]http://www.w3.org/2016/09/19-tt-minutes.html#action03]
   [NEW] ACTION: pal Refactor the IMSC repository in preparation
   for future versions of IMSC. [recorded in
   [41]http://www.w3.org/2016/09/19-tt-minutes.html#action02]

     [38] http://www.w3.org/2016/09/19-tt-minutes.html#action04
     [39] http://www.w3.org/2016/09/19-tt-minutes.html#action01
     [40] http://www.w3.org/2016/09/19-tt-minutes.html#action03
     [41] http://www.w3.org/2016/09/19-tt-minutes.html#action02

Summary of Resolutions

    1. [42]If we do not move WebVTT to CR in this Charter period
       then we will not include it in any new Charter.

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [43]scribe.perl version
    1.144 ([44]CVS log)
    $Date: 2016/09/19 17:25:20 $

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



--

Nigel Megitt
Executive Product Manager, BBC Design & Engineering
Telephone : +44 (0)3030807996
BC2 C1 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP
Received on Monday, 19 September 2016 17:32:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:44:01 UTC