See also: IRC log
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
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]
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
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
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]