Re: [tt] minutes - 21 May 2013

On Sat, May 25, 2013 at 2:48 PM, Glenn Adams <glenn@skynav.com> wrote:
>
> 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.

OK, fair enough, even if that wasn't reflected in the charter of the WG.


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

Agreed. May I then kindly request that statements that you refrain
from making statements that imply that WebVTT has less features than
TTML, e.g. I quote from the minutes:

" 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.
"
and later

"glenn: I like "Ensure maximal semantic interop"
   ... right now I beliebe WebVTT is a subset of TTML, as far as
   I'm aware.
   ... for example TTML ability to specifiy feature priority
   ... if WebVTT is kept as a subset of TTML, that would maximize
   interop
"


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

I agree that it is possible to work on two items in one WG together
and I also agree that specification writers do not make decisions on
what is implemented.

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

You're implying that I made a statement about the future. That is not
true. I merely reacted to statements that were in the minutes that
needed correction - and then I reacted to the questions that were
posed about those. You and I are aware of the situation, but it seems
many other members of this WG didn't have a full understanding of the
past and the current status. I simply answered those questions.

Best Regards,
Silvia.

Received on Monday, 27 May 2013 13:06:12 UTC