Timed Text Working Group Teleconference -- 15 Nov 2013

<trackbot> Date: 15 November 2013

<glenn> we should have the phone situation fixed shortly

Introductions

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

<glenn> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/design/TPAC2013-TTMLAnimations.pdf

<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

(Huawei)

pal: want to question third assumption - about continuous animation

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://www.w3.org/wiki/TTML/changeProposal001

<glenn> http://www.w3.org/wiki/TTML/changeProposal001

<nigel> http://www.w3.org/wiki/TTML/changeProposal001

glenn: still presenting from https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/design/TPAC2013-TTMLAnimations.pdf, now on slide 10
... change proposal - http://www.w3.org/wiki/TTML/changeProposal001
... 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> https://www.w3.org/AudioVideo/TT/tracker/issues/22

pal: who filed this issue and cared about this?
... re - https://www.w3.org/AudioVideo/TT/tracker/issues/22
... 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 animations
... back to slide set

<glenn> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html#animation-vocabulary-animate

glenn: looking at current TTML2 draft
... does look quite complicated, there are a lot of attributes there
... 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 support
... need to introduce multi-valued style property expression
... next - repeatcount and repeatdur, both in SVG. propose only supporting repeatcount

<glenn> http://www.w3.org/TR/2001/REC-smil-animation-20010904/

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/227

pal: it's issue-227 - http://www.w3.org/AudioVideo/TT/tracker/issues/227

glenn: we closed it because thought it was a duplicate of issue-22

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 http://www.w3.org/2013/11/15-tt-minutes.html#action01]

<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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/176

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

issue-277?

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/277

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 item
... agenda is about use of shorthand properties

issue-176?

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/176

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

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

action-215?

<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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/215

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 - http://www.w3.org/wiki/TimedText/tpac

pal: can we close action-205?

<nigel> issue-205?

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/205

<nigel> action-205?

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/205

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

ISSUE-286?

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/286

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

<glenn> http://lists.w3.org/Archives/Public/public-tt/2013Nov/0031.html

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

<glenn> http://lists.w3.org/Archives/Public/public-tt/2013Nov/0031.html

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

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 CSS
... 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 element
... 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 compatibility
... 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 properties
... and let authors use them to do what they want
... or we could define a proprety that is like EBU-TT, such as rowpadding
... 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 excercise
... 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

WebVTT

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

http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input

+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 metadata
... 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 tracks
... 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

questions?

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

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

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 situation

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 http://www.w3.org/2013/11/15-tt-minutes.html#action02]

<trackbot> Error finding 'silvia'. You can review and register nicknames at <http://www.w3.org/AudioVideo/TT/tracker/users>.

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 webvtt

<nigel_> next slide: tools

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

<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> http://foms-workshop.org/

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

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

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

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

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

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

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

testing

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

<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

<silvia> https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html

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

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

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

… 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

http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input

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 http://www.w3.org/2013/10/timed-text-charter.html

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 v.next 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 "v.next"

… 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 v.next 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 mapping

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 deliverable

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 subm,itted

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 later

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, too?

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 dates

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 support

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

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 dependency

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

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

<pal> http://www.itu.int/en/ITU-T/focusgroups/ava/Pages/default.aspx

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 http://www.w3.org/2013/11/15-tt-minutes.html#action03]

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

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 http://www.w3.org/2013/11/15-tt-minutes.html#action04]

<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

<nigel> http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input

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

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

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

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

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

<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 <http://www.w3.org/AudioVideo/TT/tracker/users>.

<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 <http://www.w3.org/AudioVideo/TT/tracker/users>.

<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 <http://www.w3.org/AudioVideo/TT/tracker/users>.

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

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

<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> http://www.w3.org/wiki/TTML/changeProposal005

<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: http://www.dvb.org/groups/TM

<nigel> issue-295?

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/295

<nigel> issue-296

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/296

<nigel> issue-296

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/296

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

<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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/295

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

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

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

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

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

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

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

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

<nigel> ACTION: pal to edit dsinger's proposed wording which captures the intent. [recorded in http://www.w3.org/2013/11/15-tt-minutes.html#action05]

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

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

<pal> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html

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

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

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

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

<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 http://www.w3.org/2013/11/15-tt-minutes.html#action06]

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

<r12a> http://rishida.net/utils/subtags/index.php?check=zh-cmn-Hant&submit=Check

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

<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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/188

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

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

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

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/201

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

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

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

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

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

wrap-up

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

- DRAFT -

Timed Text Working Group Teleconference

15 Nov 2013

Attendees

Contents

Introductions

state of TTML1 Animation

Inline Regions

Readability and IMSC redux

WebVTT

testing

Converging WebVTT and TTML

TTWG Roadmap

Converging WebVTT and TTML

wrap-up

Summary of Action Items

Scribe.perl diagnostic output