- 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>
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