- From: Philippe Le Hegaret <plh@w3.org>
- Date: Thu, 09 Feb 2012 13:54:50 -0500
- To: public-tt <public-tt@w3.org>
Available at
http://www.w3.org/2012/02/09-ttml-minutes.html
Timed Text Working Group
09 Feb 2012
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-tt/2012Feb/0004.html
See also: [3]IRC log
[3] http://www.w3.org/2012/02/09-ttml-irc
Attendees
Present
Matt May, Frans de Jong, Sean Hayes (Chair), Plh, Geoff
Freed, Carl Cargill, Thomas Bause, Michael Dolan, John Birch
Chair
Sean
Scribe
plh
Contents
* [4]Topics
1. [5]Intro
2. [6]Errata in the current spec
3. [7]TTML in HTML5
4. [8]Delivery profile
5. [9]Need for an update protocol
* [10]Summary of Action Items
_________________________________________________________
Intro
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
[11]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
[12]http://www.w3.org/2012/02/09-ttml-minutes.html#action02]
TTML in HTML5
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
[13]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 [14]http://www.w3.org/2012/02/09-ttml-minutes.html#action01]
[NEW] ACTION: Sean to create issues for the errata above [recorded
in [15]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
[16]http://www.w3.org/2012/02/09-ttml-minutes.html#action03]
[End of minutes]
Received on Thursday, 9 February 2012 18:54:58 UTC