- From: Thierry MICHEL <tmichel@w3.org>
- Date: Mon, 19 Sep 2016 23:30:03 +0200
- To: David Ronca <dronca@netflix.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, Public TTWG List <public-tt@w3.org>
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>> 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>> 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>
>
> 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>
>
> 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>
>
> [15] 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/>
> ... 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/>
>
> 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>
>
> [17] 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>
>
> [18] 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>
>
> [19] 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>
>
> [20] 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>
>
> [21] 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>
> ... [23]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>
> [23] 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>]
>
> [24] 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>
> 673
>
> [25] 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>
> ... We have consensus in TTLM2 to solve this?
>
> [26] 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> Add
> tts:background{Clip,Extent,Origin}
>
> [27] 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>
> n
>
> [28] 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>
>
> [29] 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>
>
> [30] 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>
> ... I added a comment about the ambiguity here.
>
> [31] 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>
>
> [32] 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>
>
> [33] 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>]
>
> [34] 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>]
>
> [35] 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>]
>
> [36] 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> 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>
>
> 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>]
> [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>]
> [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>]
> [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>]
>
> [38] 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>
> [40] 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>
>
> 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>
> [44] 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>
>
> BC2 C1 Broadcast Centre, Media Village, 201 Wood Lane, London
> W12 7TP
>
>
>
Received on Monday, 19 September 2016 21:30:14 UTC