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

Re: Minutes from today's TTWG meeting

From: Thierry MICHEL <tmichel@w3.org>
Date: Tue, 20 Sep 2016 10:57:02 +0200
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Public TTWG List <public-tt@w3.org>, Nigel Megitt <nigel.megitt@bbc.co.uk>, David Ronca <dronca@netflix.com>
Message-ID: <340ae7b1-dc27-2508-d9be-98e0a753944c@w3.org>


Le 20/09/2016 à 00:07, Silvia Pfeiffer a écrit :
> Yes, agreed.
>
> Wide review had been shown and feedback been received.


I am not aware of this.

We indeed received comments/issues on the WebVTT spec. Some of these 
comments have been discussed by the CG.
When and where was the wide review shown ? and feedback received from 
commenters on the group resolution.
Is there a disposition of comments you could point to ?

Best,

Thierry.


I think it's with
> the WG to make the next move.
>
> Best Regards,
> Silvia.
>
>
> On 20 Sep 2016 7:30 AM, "Thierry MICHEL" <tmichel@w3.org
> <mailto:tmichel@w3.org>> wrote:
>
>     Sylvia, David,
>
>     To clarify the W3C Process ...
>
>     To *enter CR*,  the TTWG must show that there is a wide review.
>     About a year ago, different groups (I18N, WAI, CCS, etc.) have
>     raised their issues on the WD. Each comment needs to be adressed
>     (some have been by the CG) get consensus and resolution from the
>     TTWG, and get agreement from the commenters.
>     So currently the TTWG can't request CR publication of WebVVT.
>
>     Once this task is done, the TTWG may request CR publication to the
>     Director.
>
>     Then, to *exit CR*, it requires to have 2 implementations of every
>     feature in the specification.
>
>     Best,
>
>     Thierry.
>
>
>
>     Le 19/09/2016 à 22:50, David Ronca a écrit :
>
>         CR requires 2 implementations of every feature in the specification,
>         correct?
>
>         D
>
>         On Mon, Sep 19, 2016 at 1:30 PM, Silvia Pfeiffer
>         <silviapfeiffer1@gmail.com <mailto:silviapfeiffer1@gmail.com>
>         <mailto:silviapfeiffer1@gmail.com
>         <mailto:silviapfeiffer1@gmail.com>>> wrote:
>
>             There's nothing stopping the group to decide to move WebVTT
>         to CR
>             right now. Why not just get it done?
>
>             Best Regards,
>             Silvia.
>
>
>             On 20 Sep 2016 3:33 AM, "Nigel Megitt"
>         <nigel.megitt@bbc.co.uk <mailto:nigel.megitt@bbc.co.uk>
>             <mailto:nigel.megitt@bbc.co.uk
>         <mailto:nigel.megitt@bbc.co.uk>>> wrote:
>
>                 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
>         <https://www.w3.org/2016/09/19-tt-minutes.html>
>                 <https://www.w3.org/2016/09/19-tt-minutes.html
>         <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
>         <http://www.w3.org/2016/09/19-tt-irc>
>                 <http://www.w3.org/2016/09/19-tt-irc
>         <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
>         <https://www.w3.org/wiki/TimedText/tpac2016#Schedule>
>                 <https://www.w3.org/wiki/TimedText/tpac2016#Schedule
>         <https://www.w3.org/wiki/TimedText/tpac2016#Schedule>>
>
>                      [15]
>         https://www.w3.org/wiki/TimedText/tpac2016#Schedule
>         <https://www.w3.org/wiki/TimedText/tpac2016#Schedule>
>                 <https://www.w3.org/wiki/TimedText/tpac2016#Schedule
>         <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/
>         <http://bbc.github.io/subtitle-guidelines/>
>                 <http://bbc.github.io/subtitle-guidelines/
>         <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/
>         <http://bbc.github.io/subtitle-guidelines/>
>                 <http://bbc.github.io/subtitle-guidelines/
>         <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
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/475>
>                 <http://www.w3.org/AudioVideo/TT/tracker/actions/475
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/475>>
>
>                      [17]
>         http://www.w3.org/AudioVideo/TT/tracker/actions/475
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/475>
>                 <http://www.w3.org/AudioVideo/TT/tracker/actions/475
>         <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
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/473>
>                 <http://www.w3.org/AudioVideo/TT/tracker/actions/473
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/473>>
>
>                      [18]
>         http://www.w3.org/AudioVideo/TT/tracker/actions/473
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/473>
>                 <http://www.w3.org/AudioVideo/TT/tracker/actions/473
>         <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
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/396>
>                 <http://www.w3.org/AudioVideo/TT/tracker/actions/396
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/396>>
>
>                      [19]
>         http://www.w3.org/AudioVideo/TT/tracker/actions/396
>         <http://www.w3.org/AudioVideo/TT/tracker/actions/396>
>                 <http://www.w3.org/AudioVideo/TT/tracker/actions/396
>         <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
>         <https://github.com/w3c/ttml1/issues/209>
>                 <https://github.com/w3c/ttml1/issues/209
>         <https://github.com/w3c/ttml1/issues/209>>
>
>                      [20] https://github.com/w3c/ttml1/issues/209
>         <https://github.com/w3c/ttml1/issues/209>
>                 <https://github.com/w3c/ttml1/issues/209
>         <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
>         <http://bbc.github.io/subtitle-guidelines/#Background-size>
>
>         <http://bbc.github.io/subtitle-guidelines/#Background-size
>         <http://bbc.github.io/subtitle-guidelines/#Background-size>>
>
>                      [21]
>         http://bbc.github.io/subtitle-guidelines/#Background-size
>         <http://bbc.github.io/subtitle-guidelines/#Background-size>
>
>         <http://bbc.github.io/subtitle-guidelines/#Background-size
>         <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
>         <https://github.com/w3c/ttml1/issues/212>
>                 <https://github.com/w3c/ttml1/issues/212
>         <https://github.com/w3c/ttml1/issues/212>>
>                    ... [23]https://github.com/w3c/ttml1/issues/209
>         <https://github.com/w3c/ttml1/issues/209>
>                 <https://github.com/w3c/ttml1/issues/209
>         <https://github.com/w3c/ttml1/issues/209>>
>
>                      [22] https://github.com/w3c/ttml1/issues/212
>         <https://github.com/w3c/ttml1/issues/212>
>                 <https://github.com/w3c/ttml1/issues/212
>         <https://github.com/w3c/ttml1/issues/212>>
>                      [23] https://github.com/w3c/ttml1/issues/209
>         <https://github.com/w3c/ttml1/issues/209>
>                 <https://github.com/w3c/ttml1/issues/209
>         <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
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action01>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action01
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action01>>]
>
>                      [24]
>         http://www.w3.org/2016/09/19-tt-minutes.html#action01
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action01>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action01
>         <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
>         <https://github.com/w3c/ttml1/issues/209#issuecomment-247973>
>
>         <https://github.com/w3c/ttml1/issues/209#issuecomment-247973
>         <https://github.com/w3c/ttml1/issues/209#issuecomment-247973>>
>                    673
>
>                      [25]
>         https://github.com/w3c/ttml1/issues/209#issuecomment-247973673
>         <https://github.com/w3c/ttml1/issues/209#issuecomment-247973673>
>
>         <https://github.com/w3c/ttml1/issues/209#issuecomment-247973673
>         <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
>         <https://github.com/w3c/ttml2/issues/150>
>                 <https://github.com/w3c/ttml2/issues/150
>         <https://github.com/w3c/ttml2/issues/150>>
>                    ... We have consensus in TTLM2 to solve this?
>
>                      [26] https://github.com/w3c/ttml2/issues/150
>         <https://github.com/w3c/ttml2/issues/150>
>                 <https://github.com/w3c/ttml2/issues/150
>         <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
>         <https://github.com/w3c/ttml2/pull/177>
>                 <https://github.com/w3c/ttml2/pull/177
>         <https://github.com/w3c/ttml2/pull/177>> Add
>                    tts:background{Clip,Extent,Origin}
>
>                      [27] https://github.com/w3c/ttml2/pull/177
>         <https://github.com/w3c/ttml2/pull/177>
>                 <https://github.com/w3c/ttml2/pull/177
>         <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
>         <https://www.w3.org/TR/css3-background/#the-background-origi>
>
>         <https://www.w3.org/TR/css3-background/#the-background-origi
>         <https://www.w3.org/TR/css3-background/#the-background-origi>>
>                    n
>
>                      [28]
>         https://www.w3.org/TR/css3-background/#the-background-origin
>         <https://www.w3.org/TR/css3-background/#the-background-origin>
>
>         <https://www.w3.org/TR/css3-background/#the-background-origin
>         <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
>         <https://github.com/w3c/ttml2/pull/179>
>                 <https://github.com/w3c/ttml2/pull/179
>         <https://github.com/w3c/ttml2/pull/179>>
>
>                      [29] https://github.com/w3c/ttml2/pull/179
>         <https://github.com/w3c/ttml2/pull/179>
>                 <https://github.com/w3c/ttml2/pull/179
>         <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
>         <https://github.com/w3c/ttml2/issues/176>
>                 <https://github.com/w3c/ttml2/issues/176
>         <https://github.com/w3c/ttml2/issues/176>>
>
>                      [30] https://github.com/w3c/ttml2/issues/176
>         <https://github.com/w3c/ttml2/issues/176>
>                 <https://github.com/w3c/ttml2/issues/176
>         <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
>         <https://github.com/w3c/ttml2/pull/180>
>                 <https://github.com/w3c/ttml2/pull/180
>         <https://github.com/w3c/ttml2/pull/180>>
>                    ... I added a comment about the ambiguity here.
>
>                      [31] https://github.com/w3c/ttml2/pull/180
>         <https://github.com/w3c/ttml2/pull/180>
>                 <https://github.com/w3c/ttml2/pull/180
>         <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
>         <https://github.com/w3c/ttml2/pull/182>
>                 <https://github.com/w3c/ttml2/pull/182
>         <https://github.com/w3c/ttml2/pull/182>>
>
>                      [32] https://github.com/w3c/ttml2/pull/182
>         <https://github.com/w3c/ttml2/pull/182>
>                 <https://github.com/w3c/ttml2/pull/182
>         <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
>         <https://github.com/w3c/ttml2/pull/183>
>                 <https://github.com/w3c/ttml2/pull/183
>         <https://github.com/w3c/ttml2/pull/183>>
>
>                      [33] https://github.com/w3c/ttml2/pull/183
>         <https://github.com/w3c/ttml2/pull/183>
>                 <https://github.com/w3c/ttml2/pull/183
>         <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
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action02>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action02
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action02>>]
>
>                      [34]
>         http://www.w3.org/2016/09/19-tt-minutes.html#action02
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action02>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action02
>         <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
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action03>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action03
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action03>>]
>
>                      [35]
>         http://www.w3.org/2016/09/19-tt-minutes.html#action03
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action03>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action03
>         <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
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action04>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action04
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action04>>]
>
>                      [36]
>         http://www.w3.org/2016/09/19-tt-minutes.html#action04
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action04>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action04
>         <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
>         <https://www.w3.org/wiki/TimedText/Publications>
>                 <https://www.w3.org/wiki/TimedText/Publications
>         <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
>         <https://www.w3.org/wiki/TimedText/Publications>
>                 <https://www.w3.org/wiki/TimedText/Publications
>         <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
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action04>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action04
>         <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
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action01>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action01
>         <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
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action03>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action03
>         <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
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action02>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action02
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action02>>]
>
>                      [38]
>         http://www.w3.org/2016/09/19-tt-minutes.html#action04
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action04>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action04
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action04>>
>                      [39]
>         http://www.w3.org/2016/09/19-tt-minutes.html#action01
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action01>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action01
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action01>>
>                      [40]
>         http://www.w3.org/2016/09/19-tt-minutes.html#action03
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action03>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action03
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action03>>
>                      [41]
>         http://www.w3.org/2016/09/19-tt-minutes.html#action02
>         <http://www.w3.org/2016/09/19-tt-minutes.html#action02>
>                 <http://www.w3.org/2016/09/19-tt-minutes.html#action02
>         <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
>         <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm>
>
>         <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
>         <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm>>
>                      [44] http://dev.w3.org/cvsweb/2002/scribe/
>         <http://dev.w3.org/cvsweb/2002/scribe/>
>                 <http://dev.w3.org/cvsweb/2002/scribe/
>         <http://dev.w3.org/cvsweb/2002/scribe/>>
>
>
>
>                 *--*
>
>                 *
>                 *
>
>                 *Nigel Megitt*
>
>                 Executive Product Manager, BBC Design & Engineering
>
>                 Telephone : +44 (0)3030807996
>         <tel:%2B44%20%280%293030807996> <tel:%2B44%20%280%293030807996>
>
>                 BC2 C1 Broadcast Centre, Media Village, 201 Wood Lane,
>         London
>                 W12 7TP
>
>
>
Received on Tuesday, 20 September 2016 08:57:18 UTC

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