- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 27 May 2013 11:09:15 -0600
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Kazuyuki Ashimura <ashimura@w3.org>, W3C Web and TV <public-web-and-tv@w3.org>
- Message-ID: <CACQ=j+dcUw7vRaLpJawUecdAMgukinVK6zW2_rA4rzArQpp-Jw@mail.gmail.com>
On Mon, May 27, 2013 at 7:05 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:
> 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.
> "
>
ah, i see you are commenting on the recorded minutes; i hadn't actually
looked at those until you now cite them; i do recall saying that in the use
of SMIL, TTML had structural timing that wasn't in VTT (as far as I'm
aware); i don't recall saying the goals of TTML were broader though, so
that may have been an incorrect paraphrase by the note taker;
> and later
>
> "glenn: I like "Ensure maximal semantic interop"
>
I do remember saying this in response to a proposal by someone who said
this but without using the word "semantic"
> ... right now I beliebe WebVTT is a subset of TTML, as far as
> I'm aware.
>
I don't recall saying this.
> ... for example TTML ability to specifiy feature priority
>
I know I didn't say this, since there is no such thing as "specify feature
priority" in TTML.
> ... if WebVTT is kept as a subset of TTML, that would maximize
> interop
> "
>
Whether I said this or not, it is true. However, whether it is (currently)
a semantic subset or whether it is desirable to make it so is an open
question in my mind. I personally don't have sufficient interest in
answering this question to do the research necessary to determine the
answer. My guess is that there is a subset of each format that is a close
if not identical match, but that there are features in both that aren't
supported in the other format.
If someone wanted to do this research, then it might be useful so we don't
have to make uninformed guesses or statements about this matter.
As for whether it is desirable to make one a subset of the other, I
expressed in the meeting that I was personally opposed to this spending
time on this matter. And that as far as I was concerned, both TTML and VTT
were independent formats with distinct communities of users (i.e., authors
and content/services providers who emit these formats).
I would prefer the charter of the TTWG to express equal
relevance/legitimacy for both efforts without attempting to characterize
one or the other as being broader/narrower, superset/subset, etc.
>
>
> > 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'm just reminding us of the (non) role of the W3C: that implementers make
their own choices (a truism). I'm also pointing out (indirectly) that what
browsers implement change over time. For example, numerous browsers did not
support SVG in the past, but now more do so. Same for MathML. That some
browsers have started with VTT but not TTML does mean that they (some or
all) won't eventually support TTML.
> 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.
>
One problem I perceive is that you have not been able to join in the calls
or discussions (at least in the TTWG or in the Web&TV TT TF), and this
creates certain impediments to understanding. I don't know if this can be
fixed or not.
>
> Best Regards,
> Silvia.
>
Received on Monday, 27 May 2013 17:10:10 UTC