TTML Minutes for 15/11/13

Minutes for 15/11/13 can be found at:



                               - DRAFT -

                Timed Text Working Group Teleconference

15 Nov 2013

   See also: [2]IRC log



          (BBC), (Opera), Giuseppe, Glenn, Ishida, Israel,
          Kepeng_Li, Mark, Nigel, Olivier, Pascale,
          Pierre_Anthony, Richard, Sylvia, Thereaux, Thierry,




     * [3]Topics
         1. [4]Introductions
         2. [5]state of TTML1 Animation
         3. [6]Inline Regions
         4. [7]Readability and IMSC redux
         5. [8]WebVTT
         6. [9]testing
         7. [10]Converging WebVTT and TTML
         8. [11]TTWG Roadmap
         9. [12]Converging WebVTT and TTML
        10. [13]wrap-up
     * [14]Summary of Action Items

   <trackbot> Date: 15 November 2013

   <glenn> we should have the phone situation fixed shortly


   <nigel> Nigel Megitt, BBC

   <nigel> Glenn Adams Cox

   <igarashi> Tatsuya Igarashi SONY

   <pal> Pierre-Anthony Lemieux, supported by MovieLabs

   <tmichel> Thierry Michel W3C

   <mijordan> I get the message that the conference is restricted.

   <olivier> scribenick: olivier

   <mijordan> I'm in.




   <mijordan> Michael Jordan, Adobe

   glenn: presents slides on state of TTML1 Animation

state of TTML1 Animation

   glenn: now moving to things we want to have in TTML2


   pal: want to question third assumption - about continuous

   glenn: let's move on, will address later

   nigel: the issues we are trying to tackle are on the agenda, we
   can address them in time

   <glenn> –  h8p://

   <glenn> [16]


   <nigel> [17]


   glenn: still presenting from

   013-TTMLAnimations.pdf, now on slide 10
   ... change proposal -

   ... any question on element targeting?
   ... most of the issues will be discussed in the next section
   ... issue of target element was raised by Sean



   <nigel> [20]


   pal: who filed this issue and cared about this?
   ... re - [21]

   ... have action item to follow up with Mike Dolan on this
   ... feedback was - it doesn't seem to be an urgent requirement


   mijordan: concern in not having something like this
   ... having a shorthand way to define this like CSS does
   ... could be a better way and reduce complexity

   glenn: agree

   pal: one of the proposals is to allow sequence of set commands
   ... previous slides had suggestions on how to address that
   ... without need for continuous animation

   mijordan: is the transition between css animation and our
   syntax going to be a problem then?

   <pal> @giuseppep yes, it was filed in 2008

   glenn: this problem has come up so many times in the past
   ... seems a no-brainer to me
   ... implementations are already there
   ... we just need to integrate it so it's reasonably useful
   ... if you want to do smooth animation of opacity
   ... you'd end up with a lot of set elements

   mijordan: dealing with discrete steps is more processor
   intensive and painful

   glenn: implementations are starting to use GPU for such
   ... back to slide set




   glenn: looking at current TTML2 draft
   ... does look quite complicated, there are a lot of attributes
   ... people's comments has been "do we need all this complexity"
   ... went through CSS animations
   ... with @@
   ... we looked at what was supported by CSS animations
   ... and which were syntactic sugar
   ... conclusion was we could remove about 8 of these attributes,
   for different reasons
   ... reducing parsing complexity, down to something similar to
   what set has
   ... lists attributes which are different from set
   ... 5 attributes would be added
   ... back to slode set. Now: continuous animation (2)
   ... accumulate and additive
   ... not currently supported by css animation. propose to defer
   ... need to introduce multi-valued style property expression
   ... next - repeatcount and repeatdur, both in SVG. propose only
   supporting repeatcount



   glenn: shows examples of different calcmodes
   ... paced mode not necessary, can be expressed as linear
   ... what next
   ... want to get buy-in to simplify by removing 8 attributes
   ... and not yet try to deal with the issue of supporting
   multiple contexts for out of line animations
   ... other issue was brought up by pal

   link to the issue?

   <nigel> I don't think it's logged as an issue

   glenn: right now we only have inline-form of set
   ... two options
   ... 1 have out of line animate or set element point to target
   ... 2. have target element point at the animate or set element
   ... latter more consistent with the way we currently do

   pal: that was not part of your proposal

   glenn: no proposal in writing

   pal: [looking for issue]

   <nigel> issue-227?

   <trackbot> issue-227 -- <p> fade-up and –down -- closed



   pal: it's issue-227 -


   glenn: we closed it because thought it was a duplicate of

   pal: can take action item to sort it out
   ... to reopen the issue and add details

   glenn: suggest adding new issue

   <glenn> proposed issue title: permit reuse of animation
   constructs by allowing multiple content elements to reference
   same out-of-line animation declaration

   <glenn> ... this reuses the same semantics as TTML uses for
   style/layout, where content elements point at style/layout, and
   not other way around

   nigel: there was a proposal in presentation
   ... to acheive same functionality by @@

   pal: happy with issue text/title suggestion

   <glenn> raise issue: Permit reuse of animation construct(s) by
   allowing multiple content elements to reference same
   out-of-line animation declaration

   <nigel> ACTION: pal to raise this issue [recorded in

   <trackbot> Created ACTION-239 - Raise this issue [on
   Pierre-Anthony Lemieux - due 2013-11-22].

   nigel: time check

   glenn: have already recorded editorial notes in the draft
   ... propose to implement those changes

   nigel: any objections?

   pal: none

   resolution reached

Inline Regions

   <nigel> issue-176?

   <trackbot> issue-176 -- Adding support for extent and origin
   attributes on block elements -- open



   glenn: already in ttml2 draft
   ... section 7.1.4 div
   ... added layout.class in content for div

   nigel: will that inherit any style attribute from anywhere?
   ... initial values are well defined
   ... inheritance is an open issue


   <trackbot> issue-277 -- Adding style inheritance for regions.
   -- open



   glenn: strong preference?
   ... inherit from layout element or root element?
   ... we could have several layout elements

   nigel: you imply that you could @@

   [scribe missed discussion]

   glenn: maybe we should defer, as not directly related to agenda
   ... agenda is about use of shorthand properties


   <trackbot> issue-176 -- Adding support for extent and origin
   attributes on block elements -- open



   <nigel> nigel: asks if referencing style from layout or tt:tt
   would override initial values.

   <nigel> glenn: no it wouldn't.

   pal: did you capture why it would not be a good idea to do the
   same with attributes

   glenn: discussed this in teleconferences, should be in minutes

   pal: I'm aware of at least 1 software package that has been
   using shorthand on <p>s

   mijordan: awaiting response from this software vendor

   pal: there is a significant catalogue of content generated by
   this software

   glenn: think point is moot. effect is the same.
   ... we have great deal of semantics in document about how
   regions work
   ... if we wanted to describe this use, we'd have to redefine
   how region work
   ... this simplifies specification

   pal: this is going to break a lot of files

   glenn: no - am going to add the shorthand that this company is

   mijordan: hadn't noticed that either

   glenn: we have already decided to basically fork the shorthand


   pal: let's capture exactly what you said, make that a proposal
   ... and we can move on

   glenn: already agreed
   ... wantedto make sure people were clear on this
   ... that it won't break existing uses
   ... albeit proprietary and illegal
   ... I already have action to implement this
   ... don't think anything more is needed


   <trackbot> action-215 -- Glenn Adams to Specify special
   semantics for tts:{extent, origin} on content elements to map
   to new inline region feature -- due 2013-10-10 -- OPEN



   glenn: don't think we need new resolution

   pal: at least someone should respond to michael

   glenn: think I already have

   pal: should be recorded in the issue

   <glenn> ISSUE-176: Note that Action-215 will adopt support for
   tts:{extent,origin} directly on <p> as a shorthand for
   specifying an inline region.

   <trackbot> Notes added to ISSUE-176 Adding support for extent
   and origin attributes on block elements.

   nigel: review agenda -


   pal: can we close action-205?

   <nigel> issue-205?

   <trackbot> issue-205 -- TTML probably shouldn't have adopted
   xml:id instead of id. -- open



   <nigel> action-205?

   <trackbot> action-205 -- Michael Jordan to Forward this
   solution to relevant implementers for their input -- due
   2013-09-26 -- OPEN



   pal: suggestion to close 205

   glenn: close as OBE

   nigel: your suggestion is equivalent to what was implemented?

   glenn: yes, that's the intent

Readability and IMSC redux


   <trackbot> ISSUE-286 -- Extend the background area behind
   rendered text to improve readability -- open



   nigel: discussed a little on Monday
   ... about extending background around rendered text




   nigel: subtle difference betweenn what this does and what this
   ... demo
   ... demo resizing the viewport




   nigel: when shrinking, new line appears but without the extra

   glenn: shows ublic/public-tt/2013Nov/0031.html

   nigel: promising
   ... if we can translate that into TTML syntax
   ... we will have achieved requirement
   ... going back to padding issue
   ... this padding would affect layout, whereas request from EBU
   was that it should not
   ... think this is minor issue

   glenn: depends if you want to stick to what can be mapped with
   ... questionable and risky path
   ... if browsers are just going to use CSS to render TTML
   ... two ways
   ... 1. define real padding and align properties and define how
   they map to CSS
   ... 2. or use properties that are already there, on content
   ... however we didn't add anything to do the cloning of padding
   ... similar for row align

   nigel: with EBU hat on, would be nice if there was
   ... but with TTWG hat on, is there any preference?

   glenn: it requires more editing and syntax
   ... if instead of creating new row padding you use existing,
   burden of editing and testing is lower

   nigel: but then so would the other option

   mijordan: simple solution
   ... can be solved by using inline-block span element

   glenn: in CSS?

   mijordan: we don't have a way of defining margin on either side
   ... but a span as inline-block would just work

   <pal> (nice minutes, btw.)

   glenn: two issues to disentangle
   ... issue of whether or not we should expose lower level
   ... and let authors use them to do what they want
   ... or we could define a proprety that is like EBU-TT, such as
   ... and affected using a shorthand or a higeher-level
   expression which we map to CSS properties

   pal: the same discussion has happened or will happen with image
   and background image support
   ... you were thinking more of CSS style
   ... should we be consistent there?

   glenn: in TTML1 we have not introduced any style properties
   ... extent and origin were the closest we came
   ... tried to avoid defining new properties
   ... if they are effectively shorthand for some subset of CSS or
   XSL-FO, it doesn't seem quite as bad as introducing completely
   new properties
   ... not adopting a fixed position on this at this point

   pal: one data point is - some folks have already taken a
   specific approach
   ... we probably want to reulse what others have done
   ... unless there is a good reason not to do that
   ... am personally happy to have editor go back and look at
   those three and suggest consistent approach

   nigel: we can do something sufficiently close to requirement
   with HTML and CSS
   ... now we need to translate it in TTML

   glenn: my effort to come up with CSS examples was a first
   ... useful
   ... we'd have to work around fact that diff browsers implement
   flex differently
   ... if people want to propose, they should provide css/html
   that demonstrates it is feasible

   mijordan: good way to deal with it

   nigel: we have demonstrated we can do it
   ... now need to think about how
   ... issue remains open

   glenn: action on me to propose and draft spec for some solution

   pal: suggest have list of action-tpac-2013 for folks not here

   nigel: [break]

   <nigel> trackbot, start meeting

   <trackbot> Meeting: Timed Text Working Group Teleconference

   <trackbot> Date: 15 November 2013

   <dsinger_> zaki, who is here?

   <nigel> scribeNick: nigel

   <scribe> chair: dsinger

   nigel: welcome Silvia and David to TTWG!

   dsinger: it's a pleasure to be here
   ... introduces topics from agenda


   silvia: introduces herself. Editor of the spec, taken over from
   Ian Hickson



   +Present, cyril, plh

   silvia: the spec and editor's draft are currently identical
   ... THere's no WhatWG version now.

   page: WebVTT Features

   silvia: Why WebVTT?
   ... We wanted something in track element in HTML5 to provide
   timeline cues.
   ... For audio descriptions, chapters, subtitles, other timed
   ... CEA 608/708 Features all met.

   nigel: WSTTeletext?

   silvia: at the beginning we looked at a lot, but haven't
   verified against teletext

   plh: how does the concept of chapter relate to MPEG4?

   silvia: it's like DVD chapters

   plh: what do you expose to users?

   silvia: depends on what tracks you put in

   dsinger: we expect the author to resolve conflicts

   silvia: we must satisfy legal requirements
   ... captions and subtitles implemented more than other user
   interface elements for that reason.
   ... we have menus for captions and subtitles to select desired
   ... We wanted to allow the web page developer to override
   formatting in the caption with CSS
   ... Anything that's rendered on the webpage should be
   overridable by CSS

   <dsinger_> we've certainly had (in the past) pop-up menus on
   the controller showing chapter names (e.g. for DVD) but I don't
   know the state or the plan for <track> chapter lists

   silvia: We have some extensions that should at some point be
   brought back into HTML


   dsinger: lots of work has been to meet FCC requirements and
   bugs have been filed and resolved.

   plh: asks re bugs

   silvia: about to get there
   ... FCC reqs lead us to introducing regions. Browsers didn't
   all agree, but now seem to be implementing.
   ... req is for roll-up and padding, and to allow changes in
   background colour.

   nigel: why was a new format needed for text track cues?

   silvia: it could have been done in js but that didn't meet
   usability requirements. when analysing existing formats the
   browsers didn't like any of them including TTML.
   ... it's not a bad position, with WebVTT being good for
   distribution and TTML more widely applicable.

   israel: which browsers?

   silvia: all of them. I did try to get them to use TTML but it
   wasn't acceptable.

   israel: we have an implementation that supports SDP.

   silvia: apologies yes MS IE does support.

   plh: IE team was uncomfortable with it for some time before
   implementing it

   dsinger: both formats are useful and offer functionality to the

   silvia: re MS, different parts of the org had different

   page - bugs

   silvia: 46 bugs now. summaries by category
   ... we want to complete functionality change issues before
   handover to WG. And have clear IPR position.
   ... so want to close off some issues before handover.
   ... 3 blockers

   <dsinger_> we wanted to be clear of the features agreed and
   have them reflected in the spec., so that the IPR situation was
   as clear as possible. having stuff agreed in the CG but not
   represented in the document would have led to a slightly blurry

   silvia: want to close off the syntax change, bugs/underspecced
   and flesh-out text issues before handover. The first 3 are
   blockers, the next 34 can be dealt with in the WG
   ... We can go to rec without the 8 new feature requests
   ... the last 1 is an editor's bug

   dsinger: are these categories in the tracker?

   silvia: no, I should probably add some categories or
   classifications or keywords

   <scribe> ACTION: silvia to add keywords to bugs in tracker
   [recorded in

   <trackbot> Error finding 'silvia'. You can review and register
   nicknames at


   note for minutes that silvia has action to add keywords to bugs
   in tracker

   nigel: there's some admin to do in combining the groups!

   next slide: demos

   silvia: CPC has done some work - nb firefox doesn't support

   <nigel_> next slide: tools

   <nigel_> silvia: extensions in js - pull up my repository to

   <nigel_> next slide: implementations

   <nigel_> silvia: there's a track element in HTML5 that uses
   WebVTT as one of the file formats to get cues into the browser.
   Supported in all browsers (firefox nightly not release)

   <nigel_> ... IE doesn't support regions yet

   <nigel_> ... Chrome has implemented regions behind the flag

   <nigel_> ... Safari has it too, as they were based on same
   rendering engine

   <nigel_> ... Opera also

   <nigel_> ... Opera was first to implement full WebVTT spec.
   Implementor is now part of the blink community.

   <nigel_> glenn: the region support is not yet in the shipping
   version of chrome - will be in the new version of Chrome32
   supported by runtime flags.

   <nigel_> ... currently behind a compile time flag

   <nigel_> silvia: Firefox is working on it. Developer meetup at
   the weekend: all of the browsers except IE will be discussing
   state of VTT implementation. At foms workshop in SF

   <nigel_> glenn: link in IRC?

   <silvia> [40]


   <nigel_> next slide: REC track

   <nigel_> silvia: Process. How to make WebVTT a ratified
   standard? Been talking about it in W3C. Come to an agreement to
   bring into TTWG as part of the re-charter.

   <nigel_> dsinger: The transition process. The CG process is not
   the same as the WG process. In CGs members only give royalty
   free grants on their own contributions.

   <nigel_> ... There's a Final Spec Agreement process to allow
   the chair to extend the IPR commitment to the whole document.
   To do that transition it's well advised if not mandatory to
   have a clear IPR position

   <nigel_> ... before bringing into the WG.

   <nigel_> ... I have approval from Apple to sign. I'm eager to
   start the process and confident that others will follow suit.

   <nigel_> silvia: and I need to complete those issues!

   <nigel_> dsinger: that will then become a public draft. We can
   then move into normal Rec track issues.

   <nigel_> ... We need to think about mapping from TTML to VTT
   and the reverse. Sean Hayes came up with a good point that we
   should discuss common semantic models.

   <israelh> q

   <nigel_> glenn: re the FSA you're going to use that to go to
   the Rec track. Then the question arises re continuing
   development. My understanding is that folks would mostly like
   to continue

   <nigel_> ... in the CG. Does that mean that every transfer from
   CG to WG has to have its own FSA?

   <nigel_> dsinger: that's what I would do. An outstanding
   question is how we maintain the CG and WG docs, it's hard work
   for the editor.

   <nigel_> all: why do both?

   <nigel_> dsinger: use CG for experimental bits only

   <nigel_> silvia: there are many CG members who are not W3C
   members so we can't force them into the TTWG

   <nigel_> ... I'd prefer them in the WG and have the discussions

   <nigel_> israel: I understand that the CG purpose is to migrate
   into the WG eventually. That doesn't prevent creation of other
   CGs that are in parallel or build on this.

   <nigel_> ... to have both seems redundant process-wise.

   <nigel_> giuseppep: isn't it going to create more frgmentation?

   <nigel_> pal: the goal of the WG is to be the single place

   <nigel_> silvia: the CG has the same goal

   <nigel_> wide objections to the idea that they can do the same

   <nigel_> israel: is it fair to say we should get a view from

   <nigel_> dsinger: yes

   <nigel_> cyril: the work of the two teams should be clearly
   distinguished e.g. call the CG 'extensions'

   <nigel_> pal: the setup of the groups defines what they can
   achieve re international standards

   <nigel_> dsinger: we can have a CG for experimental discussions
   and even generate reports into the WG. I doubt we will need 2
   specifications in the future.

   <nigel_> ... we'll have an active community. We should only
   discuss forking specs when that situation arises.

   <nigel_> israel: hasn't this happened before with WhatWG?

   <nigel_> silvia: there's a big misunderstanding here. Any CG
   developments will be extension specs - it's not that both will
   work on the same spec. That would be a nightmare for me to

   <nigel_> ... This is why we're doing a FSA so that by that time
   it's feature complete and any new discussions will create new

   <nigel_> ... we've done extension specs before e.g. regions.

   <nigel_> silvia: we can also take views from implementors.

   <nigel_> dsinger: in the process of doing this it's a first for
   W3C to go from CG to WG. Let's set a good example.

   <israelh> israelh

   <nigel_> nigel: how will you resolve requirements inputs from
   both the CG and mapping from TTML?

   <nigel_> silvia: the people interested in each format (VTT and
   TTML) overlap but are separate. I'd like to keep the ...

   <nigel_> dsinger: TTWG keeps its discussions in public.

   <nigel_> silvia: I've heard that people don't want to pollute
   the TTWG mailing list with VTT issues. Both lists are public
   and can be referenced.

   <nigel_> dsinger: there may be a best practice email header

   <nigel_> glenn: one reason for bringing the two groups together
   is to increase shared understanding. To that extent two mailing
   lists may be a barrier. On the other hand it's an evolutionary

   <nigel_> ... We can move forward one step at a time. Nobody on
   TTWG has said they don't want to see VTT. Actually neither
   group has a lot of traffic compared to some.

   <nigel_> glenn: because TTWG is public anyone can join the list
   without being a group member.

   <nigel_> dsinger: I'm sure I'll be talking with nigel about
   feature mismatches and if they are likely to be shared or not,
   and suggest actions to share info.

   <nigel_> silvia: in HTML WG they created spec-related mailing
   lists for task forces. We can consider the CG a task force.

   <nigel_> heads nod

   <dsinger_> I expect the chairs to be steering conversations to
   the appropriate mailing list - e.g. far-off features to the CG,
   bugs in the text to the WG

   <nigel_> israelh: I'd like to explore the inter-transformation
   between TTML and WebVTT and the mappings. Enthusiastic about
   this work.

   <nigel_> ... the more we can see how these come together the
   easier it is to justify spending internally

   <nigel_> nigel: we have great expertise in the two groups which
   we should make the most of for the sake of users and the


   <nigel_> silvia: we have no tests at the moment - there's a lot
   of work to do on the rec track here.

   <nigel_> glenn: opera has lots of tests that are available.

   <nigel_> silvia: there are lots available they're just not part
   of the W3C suite.

   <nigel_> dsinger: it would be good to have a test lead.

   <nigel_> glenn: cyril seems like a good candidate.

   <nigel_> israelh: re the review of status you mentioned
   regulatory mappings. Can you give a summary of how closely
   they're met?

   <nigel_> dsinger: we should pull up the bug/wiki page.

   <nigel_> ... we went through the text of the FCC ruling which
   was very specific about some features based on 608. We tried
   5-10 designs to meet roll-up and regions but they didn't meet
   the word of the

   <nigel_> ... regulations. We ended up just meeting them very

   <nigel_> israelh: we were doing that too with TTML, so it would
   be good to get feedback on how user controls to overwrite
   specifications map to the regulations




   <nigel_> silvia: There's more than one spec in the CG. I have a
   608 to WebVTT spec (link above)

   <nigel_> silvia: We walked through all the issues and collected
   them into the spec.

   <nigel_> ack

   <nigel_> nigel: did you consider performance as part of the 608
   regulatory work?

   <nigel_> silvia: WebVTT is simple enough that the performance
   should be fine.

   <nigel_> ... But nobody has ever done any measurements.

   <silvia> … we've only taken subparts of the HTML/CSS feature

   <nigel_> dsinger: We should review the regulatory compliance
   again especially wrt user controls

   <nigel_> israelh: another interesting topic is, from the apps
   world, once the user configures the settings should there be an
   API to query them?

   <nigel_> silvia: the Indie UI people are looking at this.

   <nigel_> dsinger: you can react to a visual acuity problem for

   <nigel_> nigel: timecheck

   <dsinger_> I should also mention the MPEG work for packing TTML
   and VTT into 'MP4' files: ISO/IEC 14496-30 Information
   technology — Coding of audio-visual objects — Part 30: Timed
   text and other visual overlays in ISO base media file format

   <nigel_> group thanks cyril for making that happen

   <nigel_> group breaks for lunch

   trackbot, start meeting

   <trackbot> Meeting: Timed Text Working Group Teleconference

   <trackbot> Date: 15 November 2013

   <silvia> scribe: silvia

Converging WebVTT and TTML

   nigel: what are sensible deliverables in the area of

   … feeds into the roadmap discussion at 2pm

   … we could start with a quick summary of the underlying models

   dsinger: was raised by Sean

   … could ask silvia to give a quick overview of the WebVTTmodel

   … then glenn with a model for TTML

   pal: I'd like to understand what the question is that we're
   trying to answer

   nigel: we're trying to work out the best deliverables for the
   WG given the co-existence of TTML and WebVTT

   dsinger: I think Sean wanted a semantic conversion to make sure
   we get commonality in behaviour

   … if there are needless differences, we can iron them out

   mark: the Web & TV interest group had a task force that was
   tasked with that

   there's a link on the agenda



   nigel: might be the best starting point

   plh: hi - I cannot be in this room from 2 onwards

   [room discussed to maybe jump straight to the charter]

   nigel: let's reorder the two topics

TTWG Roadmap

   <dsinger> we now move to Charter Revision

   <dsinger> see


   plh: status was that we were ok with it but nigel had some
   comments that were not expressed

   dsinger: let's just go through it

   … plh - go ahead section by section

   nigel: goal is to get to have this charter ready by the end of
   this session so we can move ahead with taking it to the AC?

   plh: after submission to AC, there will be feedback from AC
   that needs to be addressed

   dsinger: isn't the WG the first one that has to provide input?

   plh: it was there 8 months ago
   ... initial chairs section is proposed to be adapted to contain
   Nigel and David

   … nigel hasn't said "yes" yet

   nigel: 4 things are important to me

   … can I do it?

   … have I met the people that I will be working with?

   … is the group happy for me to do it?

   … fourth … was a joke....

   plh: I think he's capable of doing so

   nigel: I am also a co-chair of the EBU subtitles group

   … sometimes I will need to bring EBU input to the group

   … we just need to be clear what hat I am wearing

   … at any point in time

   glenn: let's replace the questionmarks with nigel

   plh: Mark Sadecki will help with resolving a11y issues

   … Thierry will continue to be the dedicated team contact

   … plh is the official team contact and will make time as much
   as necessary

   nigel: @@ will bring ITU a11y relationship into it, too

   <plh> s/@@@/Kawamori/

   glenn: let's correct the name of the TTML spec

   dsinger: can we remove the word "streamable" from the scope
   paragraph, since we are dealing with streamable and
   non-streamable content

   nigel: we need to make sure it's streamable, because otherwise
   it's not useful

   mark: this is scope, so let's not rule it out

   [group decides to take out this word]

   plh: 1.6 - the html mapping is part of the TTML2 spec

   glenn: we may take it out … can we change the charter later?

   plh: the way it's worded now, yes. it's on the rec track now

   glenn: I've already drafted a ttml1 API spec and am working on
   a ttml2 API spec for JS API

   … we could fold these into the TTML spec or publish separately

   … should be included in the scope though

   cyril: is this part of what we main by HTML mapping?

   plh: yes

   dsinger: includes CSS?

   plh: includes a mapping to CSS, but not CSS itself

   cyril: what does it mean to describe a document as HTML5

   … I understand what synchronic document means, i.e. a mapping

   glenn: in TTML2 we will have 2 mappings, one XSL-FO and a
   HTML-CSS mapping

   plh: but we didn't define styling in TTML1

   glenn: we use XSL-FO as our didactic framework for explaining
   what mapping means

   … what brought this up is that WebVTT maps to HTML and CSS

   … we're now doing the same for TTML

   cyril: let's add the word "document" then (describe TTML
   documents as HTML documents or HTML representation in 1.6)

   glenn: insert after HTML5 a "document fragment"

   … then it's correct

   cyril: what is in 1.4 ?

   plh: yes, that's TTML2

   glenn: we're only working on TTML2 right now

   plh: can we change 1.4 then?

   dsinger: just remove the word ""

   … it's also used in 2.1

   glenn: 1.5 replace TTML1.0 with TTML1

   cyril: is it on purpose that the metadata part was removed from
   section 2 ?

   silvia: you don't do rendering of metadata

   plh: let's add metadata in

   … it wasn't missed on purpose

   dsinger: rename in 2.1 into something more nicely

   cyril: can we make it explicit that WebVTT is mapped to HTML

   dsinger: what is missing for both is "the use of these formats
   in a HTML context"

   plh: will put it at the top before these paragraphs

   cyril: should we include guidelines when to use either format?

   … I'm looking at this from the viewpoint of a person outside
   the W3C

   glenn: we don't do this for xhtml / html either

   cyril: that one's obvious: one's xml and the other is not

   [general giggles in the room] - thanks cyril!

   dsinger: should point 3 rather say that we will develop a

   glenn: it's a bit academic - nobody has asked for this yet

   dsinger: since webvtt is being rendered and the industry
   produced ttml, it's a real-world issue

   plh: it will be part of building the html mappings

   glenn: point 4 - do we need to list maintenance specs?

   … then we need to also list all the old specs

   plh: is there interest in doing point 4?

   glenn: we can update a note anytime without asking the AC?

   plh: I'll clarify that it is US only

   … as a note

   cyril: the last deliverable doesn't have a description of the

   plh: it refers to the last item in the deliverables section - I
   need to clarify both

   nigel: on point 5, what is meant by "and subset" ?

   per: that attempted to say that the profile published by this
   group should be a superset of the input document

   … objective would be to end up with a superset of what is

   nigel: that's dangerous since it implies that we have to adopt
   everything of the document

   dsinger: let's remove it and leave it for the WG to decide

   cyril: point 6, refers to "live production", but milestone says
   "live update note" in 2.2. milestones

   plh: will fix the milestones

   dsinger: should we mention a testsuite?

   glenn: 1.7 and 2.3 mention it

   plh: testsuites are part of process

   silvia: do we want to publish the WebVTT to CEA608/708 mapping,

   nigel: not necessary for TTML since SMPTE has such a spec

   silvia: should it be a note or on REC trac?

   plh: prefer a note

   dsinger: let's add that we will publish a note at the end of
   point 2
   ... to check that the deliverables list is accurate

   glenn: end date of charter is 11 months past the end of the
   last deliverable

   nigel: there are quite some synchronized timescales that may
   create a lot of effort

   … are they realistic?

   scribe: peakiness of effort

   silvia: suggestion to have nigel & plh liaise to change the

   pal: the docs are all edited by different people

   … all of these docs have drafts, so let's give ourselves some
   challenging milestones

   dsinger: but the group as a whole has to look at the topics

   silvia: we need a first column for FPWD on all of them

   … in particular, WebVTT prefer FPWD in January

   plh: what should the other dates be?

   dsinger: reviews WebVTT milestones

   silvia: I am mostly concerned about the testsuite

   israelh: I don't know what we're missing in IE for WebVTT

   dsinger: I don't think we have all browsers interoperably
   support WebVTT by June next year

   plh: the new process is not yet available to us

   … once the new process comes out, it is what drives us

   dsinger: once the new process has been adopted, we have to
   change the charter

   plh: only need to change the milestones

   dsinger: september for PR for vtt

   pal: TTML2 and its profile - I'd look to Glenn for advice

   … extremely aggressive

   plh: safari implements webvtt?

   dsinger: yes, it's in webkit

   nigel: have we sorted out the timescales?

   dsinger: let's have the FPWD before xmas

   … for webvtt

   <plh> CR for WebVTT in September

   … section 3

   pal: do we have a normative reference to HTML? no

   dsinger: are we missing dependencies


   nigel: can we get the TAG to review the scope of the

   plh: you can't force the TAG to do this

   dsinger: as a chair you can ask them for input

   nigel: I wish to

   Thierry: why is SVG a liaison and not a dependency?

   dsinger: we don't need the SVG group to make any changes

   cyril: we need to make specs based on the web animations spec

   pal: since the spec is still draft, I'd call it a dependency

   glenn: I discussed with the SVG chair

   dsinger: we're adopting something that's specified in the
   future, so let's make it a dependency

   plh: you will need a review from the groups listed under

   cyril: it would be good for SVG WG to review the animation

   glenn: we're adopting what is exactly specified in SVG 1.1

   … so it's not a dependency, just a liaison

   [group mumble: ok]

   plh: there is an issue with TextTracks CG

   dsinger: they explore and we adopt

   plh: where will the discussion happen?

   dsinger: exploratory stuff in the CG, stuff on the REC track is
   in the WG

   pal: the key aspect is there will be only one home for the
   spec, which is this group

   … discussions related to the WebVTT group will take place on
   the TTWG list

   plh: will need to think this through

   dsinger: extension specs can be created in CG

   plh: I have more generally an issue to figure out how CG and WG
   work together

   nigel: there is a risk that communications get split

   … and decisions get made in one group that the other group
   doesn't agree with

   <mark_vickers> mark_vickers_vickers has joined #tt

   pal: there is nothing that this group can do from stopping
   other people to do something that we don't like

   plh: if I'm bringing a new feature to the spec, I don't want to
   be told to go speak with the CG

   nigel: if a feature gets raised as part of developing the
   mapping between ttml and vtt, we don't want to have to push
   this to cg

   dsinger: things we need to do to complete our deliverables
   obviously need to be done here

   cyril: new extension proposals for vtt would be good to be
   passed by the CG as well

   dsinger: we absolutely need to manage our communication

   nigel: is it a liaison with the TextTrack CG?

   … it's much tighter than that

   … are they a dependency?

   pal: I think that people have a concern with the VTT spec, they
   should come to this group

   nigel: we don't have a dependency though

   dsinger: how about i18n

   nigel: that's a liaison with i18n

   plh: what about asia's presence in TTWG

   dsinger: would be good to add i18n

   glenn: we have requests for ruby in TTML

   pal: if we're missing a group, we can still liaise with them
   later, right?

   dsinger: let's add i18n to liaison

   <nigel> add dvb-tm

   nigel: let's add the DVB-™ to external gropus

   <plh> zdvb-TM

   <plh> DVB-TM

   mark_vickers: should we add the FCC?

   dsinger: no, we just execute what they write

   plh: what about ITU?
   ... is there a group that's relevant?

   pal: yes, I'm still unclear what they do

   … a group about TimedText

   … FG AVA

   <pal> ITU FG AVA




   dsinger: let's send them a liaison

   pal: I don't have a liaison in mind

   … possibly in future

   plh: an effective way for this is if they have a person sitting
   on both sides

   … mpeg, SMPTE, EBU we are covered

   … DECE we are covered

   scribe: DVBTM?

   nigel: colleague of mine, so we're ok

   Moving to section 4 … ok

   section 5....

   we'll update the web page once the charter is approved

   plh: probably DEC/JAN

   dsinger: should we add the wiki?

   plh: too much detail

   section 6...

   Thierry: should we add the vtt mailing list?

   dsinger: no, matters related to our deliverables go here

   plh: conventions for mailing list should be mentioned

   pal: how about the bug tracker?

   glenn: some groups like HTML use issues when bugs become larger
   issues that need to be handled differently

   pal: I prefer bugzilla for tracking bugs over the issue tracker

   nigel: this is not part of the charter discussion

   section 6, 7, 8 are boilerplate, so ok

   cyril: what's the license?

   plh: W3C document license

   … I don't want to use anything else?

   silvia: I think we need an open license on the vtt spec

   plh: the open document license is currently experimental in
   HTML and not approved by TAG for other specs

   dsinger: need to get it to the attention to AC & AB for CG to
   WG transition

   nigel: what about new specs?

   <dsinger> ACTION: dsinger to consider the problem of the
   license change from CG to WG, with the AC and AB and staff
   [recorded in

   <trackbot> Created ACTION-240 - Consider the problem of the
   license change from cg to wg, with the ac and ab and staff [on
   David Singer - due 2013-11-22].

   silvia: new specs created in WG will go under W3C document

   plh: a different license will delay the charter

   <silvia1> dsinger: if there is discussion in the CG about it,
   that can be brought to the AC/AB

   <silvia1> ACTION: plh to edit charter by next tuesday [recorded
   in [46]]

   <trackbot> Created ACTION-241 - Edit charter by next tuesday
   [on Philippe Le Hégaret - due 2013-11-22].

   <silvia1> plh: ac review of charter is 4 weeks

Converging WebVTT and TTML

   <silvia1> nigel: input from Web & TV IG

   <silvia1> pal: was a group effort



   <silvia1> … was in response to reacting to two related efforts
   in W3C

   <silvia1> … Web & TV IG had a taskforce

   <silvia1> … recommendation is to combine the two under one roof

   <silvia1> … that's done, so that's great

   <silvia1> … maximize consistency between the two specs

   <silvia1> … three strategies to achieving this:

   <silvia1> … * define fully specified mappings

   <silvia1> … * pick one and run with it

   <silvia1> … * have multiple specs and deal with it

   <silvia1> … group didn't express a preference

   <silvia1> … also desire to reduce the number of TTML profiles

   <silvia1> … to simplify the life of developers and implementers

   <silvia1> … finally encourage the TTWG to engage with user and
   other groups with similar interest

   <silvia1> cyril: there are 3 profiles in TTML

   <silvia1> nigel: possibly more, depending on how you count them

   <silvia1> pal: w3c only defined 1 profile (simple delivery)

   <silvia1> … other groups defined more profiles

   <silvia1> nigel: all the profiles are subsets

   <silvia1> cyril: then there are 2 profiles: the full profile
   and the SDP

   <silvia1> glenn: let's not discuss this here

   <silvia1> … we're introducing content profiles for the first
   time in TTML2

   <silvia1> pal: it was a reaction to the market place

   <silvia1> … to the wide range of profiles in use in practice

   <silvia1> … as an encouragement for the group to take this into

   <silvia1> dsinger: was the Web & TV IG expecting a reaction to

   <silvia1> … they name the groups that they want us to interact

   <silvia1> nigel: can we assume that the charter has them

   <silvia1> dsinger: can the Web & TV IG propose any others to

   <silvia1> mark_vickers: please send a request to IG

   <silvia1> action on mark_vickers to ask IG to provide input in
   external groups list in new charter

   <trackbot> Error finding 'on'. You can review and register
   nicknames at


   <silvia1> action mark_vickers to ask IG to provide input in
   external groups list in new charter

   <trackbot> Error finding 'mark_vickers'. You can review and
   register nicknames at


   <silvia1> action mark_vickers to ask IG to provide input in
   external groups list in new charter

   <trackbot> Error finding 'mark_vickers'. You can review and
   register nicknames at


   <silvia1> action nigel to action mark_vickers to ask IG to
   provide input in external groups list in new charter

   <trackbot> Created ACTION-242 - Action mark_vickers to ask ig
   to provide input in external groups list in new charter [on
   Nigel Megitt - due 2013-11-22].

   <silvia1> dsinger: we've decided to do 3.2 from the IG document

   <silvia1> mark_vickers: I need a means to mechanically
   translate vtt and ttml into each other

   <silvia1> … there isn't a definition right now

   <silvia1> dsinger: there may be some things we can't translate,
   so we can't aim for completeness, but for consistency

   <silvia1> pal: there may be other options for content owners
   that have huge collections of TTML files that need to render
   their content

   <silvia1> dsinger: I want there to be a consistent conversion,
   and if features get dropped, then that needs to be clear

   <silvia1> … you can always deliver your TTML in other ways

   <silvia1> mark_vickers: we don't want people at the end of the
   pipeline that need captions to miss out

   <silvia1> … I'm in the middle of that pipeline of formats that
   are both developed by the W3C

   <silvia1> … let's find a way to solve this as a practical thing

   <silvia1> israelh: what is the state machine to make this

   <silvia1> nigel: this problem space has been solved by the EBU
   to restrain how things get represented in EBU so that
   conversions can be done lossless

   <silvia1> … can we constrain the problem to make it solvable

   <silvia1> silvia: let's not discuss this problem here, because
   we have an explicit new charter deliverable for creating a
   mapping between webvtt and ttml

   <silvia1> … we are discussing an artificial problem that we
   don't even know we will have

   <silvia1> israelh: are we making it part of the deliverable to
   prescribe when the conversion is to be applied?

   <silvia1> dsinger: it will be what we make it

   <silvia1> nigel: if we start with mapping ttml to html+css then
   we have a common language that we both speak

   <silvia1> dsinger: we could have a face-to-face to explain to
   each other how to do different things

   <silvia1> mark_vickers: should there be a milestone in the
   charter for such a deliverable?

   <silvia1> dsinger: it's already a deliverable, but without a

   <silvia1> nigel: happy with that

   <silvia1> silvia: is it a note or on the REC track?

   <silvia1> dsinger: a date would be good to have in there to
   make us feel bad about it

   <silvia1> … if we get to REC on TTML2 and VTT and don't have a
   mapping, then it's bad, because we can't make changes any more

   <silvia1> plh: editing the charter

   <silvia1> … proposed to be a note in october 2014

   <silvia1> … going back over the dates in the milestones table

   <silvia1> glenn: PR in December would be better

   <silvia1> .. and March on TTML2 for REC

   <silvia1> plh: ok, table updated

   <silvia1> silvia: what is "change proposal 5"?

   <silvia1> dsinger: thanks for the input of the IG

   <nigel> [51]


   <silvia1> glenn: this is the mapping of TTML2 to HTML5

   <silvia1> … it's on the charter

   <silvia1> … no need to discuss further

   <silvia1> nigel: plan of action

   <silvia1> … we have a new charter drafted

   <silvia1> dsinger: the group is too small - can we get more
   people to become active?

   <silvia1> nigel: not everyone is here

   <silvia1> nigel: break

   <nigel> dvb link: [52]


   <nigel> issue-295?

   <trackbot> issue-295 -- Remove code point restrictions from
   IMSC -- open



   <nigel> issue-296

   <trackbot> issue-296 -- Remove xml:lang placement restrictions
   from IMSC -- open



   <nigel> issue-296

   <trackbot> issue-296 -- Remove xml:lang placement restrictions
   from IMSC -- open



   <nigel> proposal: remove restriction of a single xml:lang per

   <nigel> r12a: lang can be used for spellchecking, styling and
   other features.

   <nigel> no objections: proposal accepted.

   <nigel> issue-296: proposal accepted, pal to make edit

   <trackbot> Notes added to issue-296 Remove xml:lang placement
   restrictions from IMSC.

   <nigel> issue-295?

   <trackbot> issue-295 -- Remove code point restrictions from
   IMSC -- open



   <nigel> pal: has concern with reasoning in the issue
   description but the text in IMSC does have issues that need to
   be fixed.

   <nigel> ... Following discussion with Richard Ishida, Glenn and
   others, there's a revised proposal.

   <nigel> pal: 3 separate concerns expressed.

   <nigel> First is last para, to remove inference that limited
   character sets in client implementations are acceptable and

   <nigel> pal: IMSC doesn't intend this. Annex A are
   recommendations to the author as to which characters should be
   used for specific characters.

   <nigel> ... Not a restriction on implementations.

   <nigel> r12a: It's a set of recommendations for the minimum set
   of characters that authors would be expected to use rather than
   should use. What's meant is that authors should have access to
   fonts with these character sets as a minimum.

   <nigel> pal: The end result is that if I'm an author and I
   specify language=fr this is guidance for which characters
   should be available.

   <nigel> glenn: IMSC is designed to be a content profile only.

   <nigel> dsinger: refers to example from 3GPP work.

   <nigel> glenn: it isn't a limitation, and what it may contain
   is determined by Unicode and by the authoring tools. e.g.
   English: we have ASCII, also mathematical bold version of a-z
   that could be used. Is someone going to type those on a
   composition system?

   <nigel> dsinger: is there a document anywhere that maps
   language tags to character sets?

   <nigel> r12a: yes, it's called CLDR.

   <nigel> pal: first step is to agree to make a recommendation
   like that and then find the source.

   <nigel> glenn: doesn't agree that such a recommendation is a
   good idea.

   <nigel> r12a: this isn't really about code points and
   characters, but about a minimum set of characters you should
   have support for in a font.

   <nigel> glenn: but this doesn't specify processor minimal

   <nigel> glenn: nobody needs to be told not to write English
   with Chinese characters

   <nigel> dsinger: they do - the situation is unclear re e.g.
   mathematical symbols.

   <nigel> glenn: need to clarify between font support and
   terminal support

   <nigel> dsinger: need to know that a document will work on a
   specific terminal.

   <nigel> pal: that document restriction is equivalent to a
   processor recommendation.

   <nigel> glenn: so this is a change in what needs to be
   accomplished - it needs to be a processor constraint?

   <nigel> pal: no, it's a document constraint that achieves the
   same goal.

   <nigel> glenn: to clarify, if I'm an author and use lang="en" I
   should only stay within the Unicode code points that would
   normally be rendered in English.

   <nigel> r12a: that's not what I understood. I thought: if I'm a
   user for English then I would expect minimal support for this
   set of characters but could use any other characters, accepting
   they may not appear correctly.

   <nigel> pal: r12a states the processor requirement, glenn the
   content requirement.

   <nigel> r12a: so there's no limitation on what the author can
   use, just a recommendation for a minimal set that must be

   <nigel> dsinger: no it's the minimal set that can be expected
   to be supported, so things outside that set might not render

   <nigel> glenn: so does the CLDR define characters in those

   <nigel> pal: are we comfortable with defining it as a document

   <nigel> nigel: is it per element?

   <nigel> pal: it's the computed value for xml:lang for every
   piece of content.

   <nigel> glenn: I don't mind that, but don't want to define in

   <nigel> pal: is there a fundamental reason not to have
   recommendations at all?

   <nigel> glenn: it's an unnecessary constraint because
   practically people who author content in language have to use a
   keyboard with an OS-determined code point set output

   <nigel> pal: what about crazy symbols e.g. an aeroplane symbol?
   People don't type that.

   <nigel> r12a: CLDR defines the code point set per language.

   <nigel> nigel: we need a proposal for some text

   <nigel> pal: does dsinger want to draft some text that says
   what he said?

   <dsinger> In order to be confident that the text will be
   correctly presented, text that is written in a given language
   should use the code-points as defined in CLDR as required for
   that language.

   <nigel> group works on revised text...

   <nigel> glenn: do you have any guidance about how this problem
   has been handled before?

   <nigel> r12a: not that I remember.

   <nigel> glenn: is that because nobody thinks its a problem?

   <nigel> r12a: if I understand you're working backwards from a
   processor that assumes limited per-language capability, but
   mostly we're not dealing with that situation but one where you
   can define the font used, so it doesn't apply.

   <nigel> dsinger: we're now in a market where web capability is
   trickling into fixed capability devices like televisions.

   <nigel> r12a: do you specify that e.g. televisions must support
   some characters?

   <nigel> glenn: we have content profiles and processor profiles
   with different constraint logic. We have a formal mechanism to
   define those profiles and IMSC is a set of content profiles.

   <nigel> ... He's focussing on what must be/may be/must not be
   in content.

   <nigel> r12a: can you not specify a less restrictive processor?

   <nigel> glenn: we were discussing earlier the mapping between
   content and processor profile.

   <nigel> ... We will define some default mapping.

   <nigel> glenn: originally we only defined processor profiles
   against features.

   <nigel> nigel: can we not require that for restricted
   processors the author must have access to a font with the
   restricted set of code points?

   <nigel> pal: that wouldn't permit profile-based

   <nigel> ACTION: pal to edit dsinger's proposed wording which
   captures the intent. [recorded in

   <trackbot> Created ACTION-243 - Edit dsinger's proposed wording
   which captures the intent. [on Pierre-Anthony Lemieux - due

   <nigel> nigel: is there anything we must avoid?

   <nigel> r12a: my concern is a step removed - that we have
   constrained processors. If that's the reality I can't find an
   objection to the proposed wording.

   <nigel> pal: * Point 2: what set of characters can we use?




   <nigel> pal: one issue is that there are no SE Asian language
   sets so that's a deficiency that must be resolved. I've heard
   CLDR so there's a Unicode effort to do this.

   <nigel> ... Annex A is based on an analysis of subtitles not a
   reference to e.g. CLDR.

   <nigel> ... r12a pointed out that using reference automatically
   includes future additions.

   <nigel> ... There are some characters here that are included in
   this list that aren't in CLDR generally. So my proposal is to
   go through CLDR and compare this set with what's in CLDR and
   generate the delta. Then build the table as CLDR + additions
   e.g. box drawings.

   <nigel> ... Then I plan to present the outcome to this group.
   Until I go through that exercise I'm not sure what the outcome
   will be.

   <nigel> glenn: you need to be either exhaustive, i.e. per
   country, to determine the delta, or you publish something
   incomplete. There are no tables for many languages (lists some
   fun ones) so you won't have time to complete this within the
   charter period.

   <nigel> ... So practically we'll have to publish incomplete
   sets of tables based on the time available.

   <nigel> pal: that's my expectation.

   <nigel> glenn: is there a risk to this? What value is there in
   attempting to do this huge job? What's the author's risk if
   they use something not in the set. At worst a box on the
   screen. If downloadable fonts are used maybe not.

   <nigel> pal: there's the risk that some languages won't be
   included. So r12a proposed separating this section into a note
   that can be amended whenever new languages are analysed.

   <nigel> glenn: I propose only including the deltas not all the
   ligature entries. I'd also do it as a wiki-style registry that
   allows easy editing.

   <nigel> pal: It has to be more formal and be reviewed by the

   <nigel> nigel: that restricts the amendments to the charter

   <nigel> glenn: could also recommend to Unicode that they
   publish subtitle sets.

   <nigel> glenn: objects to anything that involves us publishing
   character tables.

   <nigel> pal: I'm not objecting to a note, but a wiki, because
   wikis have no scrutiny.

   <nigel> pal: This group should help with interoperability here.

   <nigel> glenn: at this level I don't think its appropriate for
   this group to do it. I don't mind referencing work by UTC in
   this area. I've made the same objections in CSS when they tried
   to define list counters in Ethiopian.

   <nigel> ... the group doesn't have the resources to do this
   sort of thing.

   <nigel> r12a: the i18n group published that as a note.

   <nigel> glenn: I wouldn't mind throwing it over to i18n.

   <nigel> pal: it's in SDP-US

   <nigel> glenn: I wouldn't mind it as a processor profile.

   <nigel> pal: but it's the same.

   <nigel> glenn: if you could specify for just US I might not

   <nigel> pal: what's the risk?

   <nigel> glenn: this group doesn't have the expertise. I don't
   see us as a repository for all regions coming to us. It'll
   never be complete and always be wrong.

   <nigel> glenn: this position is based on past experience.

   <nigel> nigel: is there an acceptable proposal?

   <nigel> glenn: would accept it if i18n took it on and we could
   reference. Or if we could relate to CLDR. Or having a small
   table that's specifically for 608 and 708 reasons, and if EBU
   or other countries want to provide specific regional

   <nigel> ... beyond the normal set then I might be able to
   accept that.

   <nigel> pal: but this is that.

   <nigel> glenn: the difference is who comes to whom.

   <nigel> pal: this is based on actual subtitle practice, so why
   wouldn't we accept it?

   <nigel> glenn: I have a lot of experience watching how Unicode
   attempted to encode countries' languages without their
   participation and it caused lots of problems. Eventually the
   countries went to Unicode.

   <nigel> pal: I would accept removing this section.

   <nigel> glenn: can we give it to the i18n group to document -
   it's not specific to captioning.

   <nigel> pal: this is an important scope issue - it's
   specifically for subtitling and captioning.

   <nigel> r12a: the i18n group wouldn't have the expertise needed
   to define the additional characters needed for capturing.

   <nigel> glenn: if it's just the deltas I'd like to see it on a
   case by case basis.

   <nigel> ... It's hard to argue in the general sense.

   <nigel> pal: my proposal is to generate the delta and we can
   have a look at it then.

   <nigel> glenn: I'll withdraw my pre-emptive objection and allow
   this work to proceed.

   <nigel> ACTION: pal to proceed with work to investigate deltas.
   If time doesn't allow the fallback is to remove annex A.
   [recorded in

   <trackbot> Created ACTION-244 - Proceed with work to
   investigate deltas. if time doesn't allow the fallback is to
   remove annex a. [on Pierre-Anthony Lemieux - due 2013-11-22].

   <nigel> pal: propose to remove annex B

   <nigel> issue-295: see action-244 and action-243.

   <trackbot> Notes added to issue-295 Remove code point
   restrictions from IMSC.




   <nigel> r12a: this is a reference to the correct way to
   identify language subtags

   <nigel> r12a: note spelling error in the word Finnish in Annex

   <nigel> pal: the input document is from an industry standard.

   <nigel> ... (not written by me!)

   <nigel> issue-188?

   <trackbot> issue-188 -- Bounding TTML (was: SDP-US) rendering
   complexity -- open



   <nigel> pal: feedback on the Hypothetical Render Model is
   needed at this point.

   <nigel> pal: this issue was a proposal to limit complexity in
   SDP-US. There is now that proposal, in IMSC, so I'm happy to

   <nigel> pal: the parameters in CFF-TT were deliberately chosen
   to be sufficient for SDP-US so this is covered in IMSC.

   <nigel> pal: this is specifically related to SDP-US, which has
   been published. How does the group wish to deal with it?

   <nigel> glenn: we have some potential maintenance to do.
   There's no reason not to implement errata. Adding this would be
   a step further than that. I wouldn't want to cut and paste IMSC
   HRM into SDP-US.

   <nigel> ... We could always add a note and an informative
   reference, as a clarifying errata.

   <nigel> glenn: does either SDP-US or IMSC support the set
   animation element?

   <nigel> pal: yes

   <nigel> glenn: but there are no different deltas within an
   intermediate synchronic document?

   <nigel> pal: yes, it's event based.

   <nigel> glenn: ISDs are now defined not to contain any set
   transitions. With animate that will change.

   <nigel> pal: I expect IMSC not to support animate so the
   functionality would have to be expressed in terms of a sequence
   of sets.

   <nigel> glenn: we specified in TTML 1 that a processor may
   interpolate between ISDs.

   <nigel> nigel: If we add complexity constraints do we need to
   ensure that FCC required minimum performance, i.e. derived from
   CEA-608 and 708, are met?

   <nigel> pal: That exercise was done by DECE. They are satisfied
   that the performance parameters in the HRM today meet those

   <nigel> pal: I propose re this issue to defer it to the
   maintenance of SDP-US and revisit it then.

   <nigel> no objections

   <nigel> issue-188 updated

   <nigel> issue-201?

   <trackbot> issue-201 -- How to specify aspect ratio to
   understand positioning that may apply for display or video. --



   <nigel> pal: discussion on Monday re definition of pixels now
   dependent on glenn to give further consideration.

   <nigel> ... Mapping of the root container to video is
   application dependent, in general, so should not be defined in
   TTML, but perhaps adding an aspect ratio metadata element to
   TTML indicating what was the aspect ratio of the video at

   <nigel> nigel: that's done in EBU-TT-D too.

   <nigel> glenn: we already have this in SMPTE-TT-11 with the
   m708:aspectRatio, whose intent is to communicate the aspect
   ratio of the related video at authoring.

   <nigel> ... my thinking was to introduce a ttp: or ttm: element
   or attribute.

   <nigel> nigel: I think it's ttm:

   <nigel> glenn: we use ttp: for metadata that affects

   <nigel> nigel: it's not for processing.

   <nigel> pal: IMSC might use it for processing. Is that bad?

   <nigel> nigel: it's bad.

   <nigel> pal: this is a response trying to address the long
   discussion we had previously. IMSC could just create an
   extension attribute and define it.

   <nigel> ... Another option is to define in TTML 2 an attribute
   that's aspectRatio, and allow profiles to specify processor

   <nigel> glenn: We could put something into the spec early to
   satisfy the authorial intention requirement, using ttm: and
   think more on this and maybe come up with a more formal way of
   affecting processor,

   <nigel> ... e.g. drawing from SVG viewbox semantics and mapping
   the viewport to the device coordinate space. As we proceed with
   that we might have some ttp: parameters that affect processor

   <nigel> ... I'm just thinking about this.

   <nigel> pal: we need to take into account that as soon as we
   define it people will use it.

   <nigel> glenn: I want to make sure the first thing we define
   carries little processing impact.

   <nigel> nigel: as ebu-tt-d already has it this would be a good
   thing to add, for profile convergence.

   <nigel> glenn: if we put something in ttm: space early it gives
   us the ability to support the current definition in SMPTE-TT as
   well as EBU-TT to satisfy the immediate need.

   <nigel> nigel: all accept this working proposal, subject to
   potential revision?

   <nigel> nobody objects

   <nigel> glenn: if we do that we'll have to put some large
   warning labels on it saying 'not for processing. We expect to
   introduce processing-related parameters soon'

   <nigel> pal: IMSC does specify processing behaviour based on an
   aspect ratio parameter.

   <nigel> issue-201: Glenn to investigate SVG viewbox etc and see
   if something can be brought in from that space.

   <trackbot> Notes added to issue-201 How to specify aspect ratio
   to understand positioning that may apply for display or video..

   <nigel> nigel: there are also uses for bar support and other
   aspect ratio parameters.


   <nigel> nigel describes what we did, from the agenda.

   <nigel> mark_vickers: We received a Consensus Input from the
   Web and TV IG.

   <nigel> nigel: we also received a liaison from EBU which we
   didn't cover on the agenda.

   <nigel> nigel: next meeting Thursday

   <nigel> glenn: regrets until Dec 5th.

   <nigel> nigel: thanks everyone.

   <nigel> meeting closes.

Summary of Action Items

   [NEW] ACTION: dsinger to consider the problem of the license
   change from CG to WG, with the AC and AB and staff [recorded in
   [NEW] ACTION: pal to edit dsinger's proposed wording which
   captures the intent. [recorded in
   [NEW] ACTION: pal to proceed with work to investigate deltas.
   If time doesn't allow the fallback is to remove annex A.
   [recorded in
   [NEW] ACTION: pal to raise this issue [recorded in
   [NEW] ACTION: plh to edit charter by next tuesday [recorded in
   [NEW] ACTION: silvia to add keywords to bugs in tracker
   [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [69]scribe.perl version
    1.138 ([70]CVS log)
    $Date: 2013-11-15 09:30:24 $



Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [71]



Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/poit/point/
Succeeded: s/thje isdue/the issue/
Succeeded: s/questionalble/questionable/
Succeeded: s/MS did object/IE team was uncomfortable with it for some ti
me before implementing it/
Succeeded: s/FORMS/foms/
Succeeded: s/indy UI/Indie UI/
Succeeded: s/ti,e/time/
FAILED: s/@@@/Kawamori/
Succeeded: s/back//
Succeeded: s/with/wish/
Succeeded: s/mark/mark_vickers/
Succeeded: s/IG-EVA/FG AVA/
Succeeded: s/page/charter/
WARNING: No scribe lines found matching ScribeNick pattern: <silvia> ...
Found ScribeNick: olivier
Found ScribeNick: nigel
Found Scribe: silvia
Inferring ScribeNick: silvia
ScribeNicks: olivier, nigel, silvia

WARNING: Replacing list of attendees.
Old list: +1.617.766.aaaa Ralph Taishan mijordan
New list: Taishan +1.617.766.aaaa mijordan

Default Present: Taishan, +1.617.766.aaaa, mijordan
Present: (BBC) (Opera) Giuseppe Glenn Ishida Israel Kepeng_Li Mark Nigel
 Olivier Pascale Pierre_Anthony Richard Sylvia Thereaux Thierry Vickers
Found Date: 15 Nov 2013
Guessing minutes URL: [72]

People with action items: dsinger pal plh silvia


WARNING: Possible internal error: join/leave lines remaining:
        <mark_vickers> mark_vickers_vickers has joined #tt

WARNING: Possible internal error: join/leave lines remaining:
        <mark_vickers> mark_vickers_vickers has joined #tt

   End of [73]scribe.perl diagnostic output]



This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.


Received on Thursday, 21 November 2013 16:30:10 UTC