W3C home > Mailing lists > Public > public-web-and-tv@w3.org > May 2013

Re: [tt] minutes - 21 May 2013

From: Glenn Adams <glenn@skynav.com>
Date: Fri, 24 May 2013 22:48:58 -0600
Message-ID: <CACQ=j+eDay1KtUB8MVEc=0Wos6N4iP1ezHzsM77b_=kSU5GQLw@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Kazuyuki Ashimura <ashimura@w3.org>, W3C Web and TV <public-web-and-tv@w3.org>
On Fri, May 24, 2013 at 8:20 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

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

No, you are wrong. And you are reading too much into that charter language,
which just happens to mention only captioning. I would have to guess that
you haven't actually read the TTML spec, otherwise you would understand it
isn't focused solely on captioning, nor has that ever been the case since
the start of the TTWG.

For example, the group considered the needs for karaoke and scrolling
banner text (crawlers) as part of the use cases for TTML.


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

If you or browser vendors ever believed (1) was true, then you haven't read
the TTML specification. Given that (1) has often been given as the reason
for (3) and (4), I have to conclude that the browser vendors who reached
these untenable positions never closely studied the specification or
attempted to implement it.


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

I'm not sure about this either, since I didn't write that comment.
Personally, I find any discussion about whether TTML or VTT has more or
less features or more or less capabilities to be a major distraction
towards getting the real work done, which I mean the implementation and
support for both TTML and VTT in browsers and the greater good for the two
communities of authors. Every time we argue that one of these formats is
less than the other, we reduce the likelihood that we can serve the end
users that need this support.

Nobody in their right mind argues that only JPEG or PNG should be
supported. There are good reasons to support both. And those reasons are
the same that apply to TTML and VTT.

I believe the TTWG can effectively work on both formats as long as there is
a mutual understanding and respect for the work and deployment of both
formats. The W3C doesn't make decisions about what browser implementors
will implement, and we shouldn't use past performance in this regard as an
indicator or a bias.




>
> Thanks,
> Silvia.
>
Received on Saturday, 25 May 2013 04:49:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:09 UTC