[Bug 11207] Make track element additions technology neutral

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11207

--- Comment #6 from John Foliot <jfoliot@stanford.edu> 2010-11-03 17:37:10 UTC ---
(In reply to comment #4)
> 
> There is an obvious possibility that WebSRT be the format chosen by the media
> accessibility subgroup. 

The only thing that is obvious at this time is that WebSRT is being evaluated
to see if it meets all of the User and Author requirements currently identified
by the sub-team. Presuming that we will concur that WebSRT is *the* format is
premature at this time. A quick check of what WebSRT can and cannot do at this
time already suggests to me that it is incomplete in some ways.

> If this occurs, then any effort spent on genericizing
> the API will be wasted.  (In fact, it will be a waste if any single format is
> chosen, as you instead want a specialized API if you have only a single
> format.)  As such, it seems premature to spend any effort on this right now.

Right. So rather than "wasting our time" working on a "specialized API for a
single (WebSRT) format" - which may or may not be a recommended format - we'd
rather focus on a generic API at this time. You've just argued for our request
<grin>.


> 
> The fact that a final decision hasn't been made doesn't negate the fact that
> there aren't *currently* any plans to add an additional format.  So far, there
> has been no public announcement of any plans to add an additional format; there
> is only the a11y TF's investigation of formats, which has not yet resulted in
> any announcement.

Putting the cart before the horse is rarely a good long-term solution. There
have been no "announcements" one way or the other, and likely won't be until
such time as we have finished the work we set out to do, which was to a)
capture all user (and author) requirements, b) evaluate possible solutions
against those requirements, c) make one or more recommendations.

It is well known that WebSRT has captured a certain fondness in some circles,
and the fact that work on that specification is both current and active, but if
WebSRT cannot meet all the user/author requirements for ensuring accessibility
then the media sub-team must say so, and provide proof of such. However, as
part of the assessment, if 'holes' are discovered, and they can be addressed
inside the WebSRT spec, then it would strengthen the case for adopting WebSRT
as a baseline or recommended format.

Meanwhile, going back to our very first face-to-face discussion at Stanford on
Nov. 1, 2009 on this topic (which pre-dates the media sub-team) and subsequent
meetings at TPAC 2009 that same week, we emerged from those meetings noting
that likely we would need to support more than one time format (at that time
noting both SRT, TTML, and SMIL-TEXT)
http://lists.w3.org/Archives/Public/public-html/2009Nov/0163.html

To that end, I believe we have been both clear and consistent to date.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 3 November 2010 17:37:14 UTC