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

Re: Minutes from today's TTWG meeting

From: David Ronca <dronca@netflix.com>
Date: Mon, 19 Sep 2016 15:14:38 -0700
Message-ID: <CAMjV-FhmnDw9af-0-rMHWEz_0H_5EdfEWnRET+BJ10FKhUgVMg@mail.gmail.com>
To: Thierry MICHEL <tmichel@w3.org>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Public TTWG List <public-tt@w3.org>
Thierry,

Thanks for the clarification.

David

On Mon, Sep 19, 2016 at 2:30 PM, Thierry MICHEL <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>> 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-24
>> 7973
>>         <https://github.com/w3c/ttml1/issues/209#issuecomment-247973>
>>            673
>>
>>              [25] https://github.com/w3c/ttml1/i
>> ssues/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-bac
>> kground/#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/ttm
>> l2/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.
>
>
Received on Monday, 19 September 2016 22:15:20 UTC

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