Timed Text Working Group

09 Feb 2012


See also: IRC log


Matt May, Frans de Jong, Sean Hayes (Chair), Plh, Geoff Freed, Carl Cargill, Thomas Bause, Michael Dolan, John Birch



Sean: interested in an overview of the state of TTML
... discussion in HTML5
... TTML could be used with the track element
... SMPTE_TT has been released, which added a few features
... in particular images
... some work in DECE as well
... and they have a mechanism, package media, for download
... also based TTML
... EBU has been working on a replacement for their STL files
... use din most european broadcasting station
... more recently, the FCC, as a result of 21st century act, gave safe harbor to TTML
... now if you use TTML for captions, you're deemed to be compliant
... though it's not restricted to it
... now it's time to revisit what we should do next
... any question?

Sean: if we're going to get a new charter
... I want to find out what are the work items for that
... there are a couple of blocking issues in the schema
... next thing is use of TTML in HTML5
... if we are going to be used as a SMPTE safe harbor, none of our profiles are a good fit for that
... so, somewhere in between our existing profiles, we could come up with a more useful profile
... an other issue: live production of captions
... we don't have of updating TTML on the fly
... there are a few issues coming from v.next
... the addition coming from SMPTE
... so thinking about all of them, what should we put in the charter?
... is there enough work to carry on with
... the profile work is extremely pressing

Errata in the current spec

Sean: the XSD doesn't reflect the prose
... because XSD isn't expressive enough
... PLH fixed on those issues
... that's in the errata
... the other is that there is no extension point
... but the text is clear
... EBU, SMPTE, DECE are trying to follow that extension model
... the only way to make it happen in XSD
... adding ##other would fix it
... but also invalid content as well
... unless we have some kind of meta level content
... so no technical way to narrow it down
... that's a big one

Mike: yes, the problem is that using ##other would be too relax, but don't seem we have a choice.
... my view is that we should relax, it's the best of two evil

Plh: +1. btw, it's possible to do this in XSD 1.1

John: mixed feelings in the EBU...

Sean: as interim, let's relax. also W3C just launched a more complex validator service based on relax ng, schematron, etc, so we could look into using that
... so let's make that change in the interim for now
... any objection?

[none heard]

Sean: can we change the download package

Plh: I'll look into it

<scribe> ACTION: Plh to fix ISSUE-150 by relaxing the schema [recorded in http://www.w3.org/2012/02/09-ttml-minutes.html#action01]

Sean: some isues coming out of the EBU
... they're using the SMPTE timing model
... it turns out that the insync mechanim doesn't allow the media markup mode to work properly
... default values doesn't work
... the default value needs to be all instead of last
... I'll create an issue for this one
... related one: we need to clarify what the sync base in SMPTE continuous mode
... it's not clear whether they should be referencing the external timeline or using the same model as TTML by using the parent container
... I think it was intended to reference the external timeline with the markup mode
... I'll create an issue around that
... in the example profile, we have something called metadata foreign but we don't define it
... we should delete them
... next one: ambiguity in the way the profile work
... whether other features are optional or prohibited
... there is no current prohibition mechanism
... something we should revisit

?: em unit isn't well defined or can't be calculated

Sean: they can be calculated but I agree a clarification is needed
... the font size is restricted to be one cell
... [...]
... one remaining one which is recent
... we have the transformation profile, but we don't define what the transformation process is
... so clarification is needed

<scribe> ACTION: Sean to create issues for the errata above [recorded in http://www.w3.org/2012/02/09-ttml-minutes.html#action02]


Sean: huge heated debate on how ttml is debate
... use of XSL FO
... people thought that it means that you need to have an XSL FO
... despite my comment that we don't have conflicts with the CSS object model
... we just used XSL FO because it was a recommendation at the time we were writing
... I think it was the right decision at the time
... but lots of people are upset on how TTML is defined
... one thing which would be very useful is to work a message on how to apply TTML to HTML5
... there is now a community group working on WebVTT, an alternative format
... but we have to define a mapping between TTML and the HTML APIs
... IE is implementing it and might invent its own
... so we need to make sure there is an agreed way
... part of that work is that to add a section which explain TTML with CSS, or replace XSL FO with CSS
... or make it a separate note
... so that we don't have to change TTML 1.0
... and we could always fold it into TTML.next later
... there are a couple of places where we might need to relax our values

Plh: starting with a note sounds like a good idea

Resolved: we'll work on a Note on how to TTML with HTML5/CSS

<scribe> ACTION: Sean to start the Note on how to use TTML with HTML5/CSS [recorded in http://www.w3.org/2012/02/09-ttml-minutes.html#action03]

Delivery profile

Sean: we were thinking about interchange with TTML 1.0
... to capture the intent different broadcasters and authors
... we didn't really put effort into constraining the profile around the concept of delivery
... I think it was a mistake
... Adobe, Microsoft, DECE created their owns
... it's extremely pressing to work on a profile asap
... I think the place to start is an other Note, due to the pressing timeline
... and fold that in into TTML.next later

Mike: SMPTE hasn't done too much in terms of delivery. SMPTE added support for glyph/images and added more metadata support
... 90% of SMPTE-TT is TTML in fact
... DECE was a delivery subset, for the decoder behavior
... buffer model, etc.
... we added one attribute
... primarily for the delivery of subtitles

Sean: so they constrained the value space of time
... we don't have any feature to allow to do that
... the feature system isn't fine grain enough
... we also need to get agreement that the choices of DECE made were the valid ones
... the CVA requirements were different
... we punted a few issues on 708
... we should back and look at that

John: when people talk about delivery and distribution, I interpret that as the last leg, ie delivery to the user
... in the broadcaster world, this is from the subtitler to the broadcaster
... so we're using the same term to mean different things
... I agree that we need constraints on TTML
... to have some guarantee of interop
... very much agree about your comment on profiles
... whether feature are optional or forbidden in profiles

Sean: the profile is supposed that is something that the document carries with it
... we couldn't imagine a scenario where it was needed to say that the processor shouldn't do something
... so it didn't make sense to put that prohibition
... but everybody has used the profile the other way around
... so we built the wrong thing
... we need to have profiles to describe the players

John: or look at the profile for cutting off parts of the language
... in EBU, we're trying to create TTML lite
... the reason is that EBU-TT is targeted towards exchange files between editing systems

Sean: indeed, DECE and SMPTE took the approach of not allowing features that are not within a profile
... I support making that legal
... we would have to come with prohibited values
... so I think make sense to work on this rapidly
... I think we should fold that into the charter

Need for an update protocol

Sean: due to XML nature, it's not possible to update a TTML document live
... we don't have an update mechanism
... solution is to create standalone doc, but kind of defeating the point
... because XML is slightly fluid, due to the DOM for example
... they are a number of different approaches that one can use
... I think that's a big gap
... we struggled with it at Microsoft for example
... we did put some vague notes in an annex in TTML 1.0
... but didn't narrow it down

John: is there a differentiation between streaming and live update?
... like live editing, with a forward/backward process
... I'm not convinced they're both the same thing

Sean: agreed, they're not. Microsoft smooth streaming sends small ttml files updates
... but it's only additional in time

John: streaming is an issue of fragementation and reassembling
... while update needs to have search
... EBU is looking into that

Sean: I'd rather have EBU come to the table in the TTML WG
... otherwise it's going to make the situation more difficult
... I'd like to encourage those people to come back at the table
... only do things EBU centric if they don't get what they need here

John: agreed. my only reservation is the timescale
... EBU_TT has a very aggressive timeline
... will the TTML WG able to respond fast?

Sean: I'd propose that we create a subgroup that come up with a strawman proposal
... and fold it out later
... breaking the things down into smaller bits will allow us to move faster
... I'd rather work on small deliverables and package them later into a bigger spec later

Carl: +1

Sean: at this point, I'd like to know if we think we have enough work to do

Carl: +1

John: +1

[no objection]

Resolved: TTML is going to draft a new charter

Sean: I'd like some help on drafting this charter together

Carl: I'm happy to help

Mike: ditto

Matt: yes, Adobe can help

Sean: we';ll put that together over the next week or so, and have an other meeting after that
... how about a weekly call between now and end of March

Carl: +1

Sean: then let's do the same

plh: how about reintroducing dynamic flow?

John: I proposed it a while back and learned a lot since then
... dynamic flow was always in a relaxed timing model
... I think it's just too complex
... with my current understanding of CSS/XSL and layout philosophy, I'd suggest to drop it or be handle differently

Sean: I tried to implement it and it goes against the grain
... I don't think it makes a lot of sense nowadays
... people are welcome to send use cases and proposal for why they would want to add dynamic flow again

John: agree dynamic flow doesn't fit well with our styling model

Sean: let's adjourn for now

Summary of Action Items

[NEW] ACTION: Plh to fix ISSUE-150 by relaxing the schema [recorded in http://www.w3.org/2012/02/09-ttml-minutes.html#action01]
[NEW] ACTION: Sean to create issues for the errata above [recorded in http://www.w3.org/2012/02/09-ttml-minutes.html#action02]
[NEW] ACTION: Sean to start the Note on how to use TTML with HTML5/CSS [recorded in http://www.w3.org/2012/02/09-ttml-minutes.html#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/02/09 18:53:37 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/creating/create/
Succeeded: s/add/update/
No ScribeNick specified.  Guessing ScribeNick: plh
Inferring Scribes: plh
Default Present: +41.22.717.aaaa, +1.858.882.aabb, +1.541.488.aacc, +44.154.558.aadd, Matt, Plh, +1.617.300.aaee, Frans, Sean, Carl, +1.212.664.aaff, Brussels, +44.147.383.aagg, John_Birch
Present: Matt Frans Sean Plh Geoff
Agenda: http://lists.w3.org/Archives/Public/public-tt/2012Feb/0004.html
Got date from IRC log name: 09 Feb 2012
Guessing minutes URL: http://www.w3.org/2012/02/09-ttml-minutes.html
People with action items: plh sean

[End of scribe.perl diagnostic output]