- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Nov 2010 17:37:12 +0000
- To: public-html-a11y@w3.org
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 on the CC list for the bug.
Received on Wednesday, 3 November 2010 17:37:14 UTC