- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sat, 25 May 2013 12:20:36 +1000
- To: Glenn Adams <glenn@skynav.com>
- Cc: Kazuyuki Ashimura <ashimura@w3.org>, W3C Web and TV <public-web-and-tv@w3.org>
On Sat, May 25, 2013 at 10:49 AM, Glenn Adams <glenn@skynav.com> wrote: > > On Wed, May 22, 2013 at 12:47 AM, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: >> >> On Wed, May 22, 2013 at 1:31 AM, Kazuyuki Ashimura <ashimura@w3.org> >> wrote: >> > available at: >> > http://www.w3.org/2013/05/21-webtv-minutes.html >> > >> > also as text below. >> > >> > Thanks a lot for taking these minutes, Mark Vickers! >> > >> > Please note that I've added the action item from this call >> > to Tracker as ACTION-114 at: >> > https://www.w3.org/2011/webtv/track/actions/114 >> > >> > Kazuyuki >> > >> > --- >> > [1]W3C >> > >> > [1] http://www.w3.org/ >> > >> > - DRAFT - >> > >> > Web and TV Interest Group Teleconference >> > >> > 21 May 2013 >> > >> > [2]Agenda >> > >> > [2] >> > http://lists.w3.org/Archives/Public/public-web-and-tv/2013May/0020.html >> > >> > See also: [3]IRC log >> > >> > [3] http://www.w3.org/2013/05/21-webtv-irc >> > >> > Attendees >> > >> > Present >> > Kaz, Pierre, Glenn, Jean-Charles, Mark_Vickers, Olivier >> > >> > Regrets >> > Chair >> > Pierre >> > >> > Scribe >> > Mark >> > >> > Contents >> > >> > * [4]Topics >> > 1. [5]Revised TTWG charter >> > 2. [6]Meeting time >> > * [7]Summary of Action Items >> > __________________________________________________________ >> > >> > <Mark_Vickers> pierre: Agenda: 1. meeting time. 2. TTWG Charter >> > 3. Testing project >> > >> > Revised TTWG charter >> > >> > <olivier> >> > [8]https://lists.w3.org/Archives/Member/w3c-ac-forum/2013AprJun >> > /0136.html >> > >> > [8] >> > https://lists.w3.org/Archives/Member/w3c-ac-forum/2013AprJun/0136.html >> > >> > <pal_> [9]http://www.w3.org/2013/05/timed-text-charter.html >> > >> > [9] http://www.w3.org/2013/05/timed-text-charter.html >> > >> > <inserted> scribenick: Mark_Vickers >> > >> > Pierre: The main addition to the charter is WebVTT >> > ... There seems to be support in the TTWG, but some opposition >> > on AC list discussion. Can the Web & TV industry provide some >> > direction. >> > >> > Olivier: One thing that could be useful is to point to adoption >> > of both specs. Both specs have wide adoption. AC statements >> > that TTML is irrelevant & noxious are concerning. >> > >> > Pierre: TTML has had great adoption. It is the responsibility >> > of W3C to harmonize the two. >> > >> > Glenn: Harmonize implies merging into one. I expect both will >> > exist. I think it will be good for both to be in one group. >> > There has been much misinformation on TTML, for example on XSL. >> > Having both in one group will decrease partisanship. >> > ... Cox has asked for specific language in the charter asking >> > for a level playing field and support of both. >> > >> > <inserted> scribenick: olivier >> > >> > Mark_Vickers: we've had too much of a focus on tech issues, not >> > enough IMHO on doing what's best for people with hearing >> > impairments >> > >> > <glenn> >> > [10]http://lists.w3.org/Archives/Public/public-tt/2013May/0082. >> > html >> > >> > [10] >> > http://lists.w3.org/Archives/Public/public-tt/2013May/0082.html >> > >> > Mark_Vickers: more important than this vs that architecture >> > >> > <glenn> >> > [11]http://lists.w3.org/Archives/Public/public-tt/2013May/0087. >> > html >> > >> > [11] >> > http://lists.w3.org/Archives/Public/public-tt/2013May/0087.html >> > >> > Mark_Vickers: in that regard fewer specs would be better than >> > more >> > ... would be good to see all TTML variants pulled into one >> > ... and make sure we can maximally map the semantics between >> > the two, if there are to be more than one spec >> > ... if there can't be a mapping, we would lose information >> > >> > <kaz> scribenick: Mark_Vickers >> > >> > glenn: Do you think it's realistic that one community will give >> > up one sntax? >> > >> > olivier: I don't think that it's realistic for there to be one >> > spec given current usage. >> > >> > mark_vickers: I agree it's unlikely to be one spec, but I think >> > it's worth stating that it's an ideal. >> > >> > glenn: I don't agree with a single spec notion because I think >> > it's impractical and causes more trouble. >> > ... I agree it's important to serve the community for captions, >> > both hearing and hearing-impaired. >> > >> > Pierre: What about the goal of maximizing semantic >> > compatibility? >> > >> > glenn: To some degree. The goals of TTML were broader, for >> > example in the use of SMIL. I wouldn't expect WebVTT to adopt >> > that. >> >> Right. You're still able to put SMIL and whatever else into WebVTT >> cues, but they won't be interpreted by a browser natively. >> >> >> > Pierre: But to the amount that one is a semantic superset of >> > the other> >> > >> > mark_vickers: what about when semantics cannot be mapped? >> > >> > glenn: browsers need to support both formats >> > ... The superset format can be mapped, but some information >> > will be lost. >> > >> > <pal_> [12]http://www.w3.org/2011/webtv/wiki/Timed_Text_Efforts >> > >> > [12] http://www.w3.org/2011/webtv/wiki/Timed_Text_Efforts >> > >> > pierre: Would it be worth sharing the TF list of adoption of >> > TTML & WebVTT to show adoption of both? >> > ... Can we come up with a requirement that all are happy? >> > >> > glenn: it would be useful to identify the caption communities >> > >> > olivier: the audio group has a hierarchy of developer, >> > implementor, spec maker. In the case of timed text: user, >> > author, implementor, spec maker >> > >> > glenn: I'd order user, author first, but whether implementor or >> > spec maker is first is unclear >> > >> > olivier: an example is if something is tedious to specify, but >> > important for implementors, you need to do the spec >> > >> > glenn: I see the order as user, {author, implementor, spec >> > maker} with the latter an unoredered list >> > >> > pierre: I think author is a priority over the latter two >> > >> > glenn: How about user, author, {`implementor, spec maker}? >> > >> > <olivier> "ensure maximal interop"? >> > >> > pierre: Some progress on community. How do we get to agreement >> > on the points on mapping? >> > >> > olivier: I like maximize semantic mapping >> > ... what really worries me is that if the two evolve together, >> > there will be mapping from one to the other, but if there's not >> > a clear decision of which is a superset, we're in trouble >> > >> > glenn: I like "Ensure maximal semantic interop" >> > ... right now I beliebe WebVTT is a subset of TTML, as far as >> > I'm aware. >> >> My understanding is the exact opposite: since TTML only focuses on >> captions, but WebVTT on captions, descriptions, metadata, and >> chapters, WebVTT has a broader applicability than TTML. > > > I'm afraid your understanding is incomplete. TTML is designed to support all > kinds of text with timing semantics. Captions and subtitles are just one > such example. It is equally capable of interchanging other applications use > of timed text, including descriptions, metadata, and chapters. My arguments were just following the mission statement of the TTWG [1]: "The mission of the Timed Text Working Group, part of the Video in the Web Activity, is to produce a W3C Recommendation for media online captioning by refining the W3C specification "Timed Text Markup Language (TTML) 1.0" based in implementation experience and interoperability feedback." That clearly speaks about captioning alone and TTML has been developed with that background, while WebVTT was from the start developed with a broader applicability. It may well be that today this is different and the TTML spec speaks about timed text in general and captioning in particular. I'm just pointing out that there initial design goals were different. [1] http://www.w3.org/AudioVideo/TT/ > I just don't understand why folks in the VTT community spend so much time > making false statements about TTML. False statements like (1) TTML requires > XSL-FO, (2) TTML has narrower applicability than VTT, (3) TTML is complex to > implement, or (4) TTML would cause browser bloat. None of these claims are > true and I would caution those who think otherwise to prove their claims if > they intend to continue making them. Statement (1), (3) and (4) have been made by browser developers before the development of WebVTT and were the reasons browsers decided to develop WebVTT. I will not defend these statements - I'm just pointing them out because at the time I fought long and hard for the adoption of TTML and eventually went along with the browser vendors' decision to go with WebVTT. Note that IE supports only a very small subpart of TTML, so these claims have not been proven false yet. >> > ... for example TTML ability to specifiy feature priority >> >> Can you explain what "feature priority" means? Would you mind answering this question still? Like you, I am afraid that there are many false statements about WebVTT, including that it has less capabilities than TTML, which I am not convinced of. So, when stating that TTML has a capability to "specify feature priority which WebVTT doesn't have", it would be helpful to explain what that term actually means. Thanks, Silvia.
Received on Saturday, 25 May 2013 02:21:31 UTC