- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 19 Feb 2010 10:52:22 +1100
- To: Geoff Freed <geoff_freed@wgbh.org>
- Cc: Dick Bulterman <Dick.Bulterman@cwi.nl>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "markku.hakkinen@gmail.com" <markku.hakkinen@gmail.com>, "symm@w3.org" <symm@w3.org>
On Thu, Feb 18, 2010 at 11:41 PM, Geoff Freed <geoff_freed@wgbh.org> wrote: > > one brief comment from me below; i’m out of the office today and will have > to save my other comments for tomorrow. > geoff/wgbh > > >> On 2/18/10 7:09 AM, "Dick Bulterman" <Dick.Bulterman@cwi.nl> wrote: >> >> (SRT, which has huge user uptake, is not sufficiently easier to use than >> smilText, it is not XML and there is nobody who really 'owns' it. From a >> standardization perspective, I would tend to view it as a non-starter, >> were it not that it provides lowest common denominator support -- but, >> so does Fortran.) > > GF: I very much agree here with Dick. The things that make me most > apprehensive about SRT are... > > -- it has no ownership > -- it has no standards-group backing > -- it has very little, if any, styling (plz correct me if I’m wrong) There are several people in the WG that have already proposed to write a RFC for srt. It will be really simple to do, mostly because styling will be left out and left to CSS. That is actually an advantage of srt over any other choice. In this respect it compares more to an RSS feed format than to a markup format. Its huge uptake online is the big advantage here, so it would be more productive to look at it as identical to the most basic functionality in DFXP or in SmilText: text with start and end time. In fact, I believe that should be the lowest possible profile of DFXP, too, so in essence it becomes identical to srt. Then it's just a choice similar to the one between atom and rss. What I am more curious about is to create a specification for DFXP where there is a mapping from DFXP constructs to HTML/CSS/JavaScript, because that is what we will require to make an implementation in a Web browser. This mapping is implicit in Philippe's specification, but needs to be made explicit in a document. It may well be the most relevant document for the collaboration between the timed text WG and the html WG. > For the W3C to issue a recommendation that itself recommends the use of a > non-standard caption-text format would, at the very least, appear rather > awkward. The current list is DFXP and srt. I don't see anything awkward about it. The first is W3C politics and the second is Web dominance, to put it blunt. Every Web user out there who would not see srt in that list would believe the W3C is ignoring reality. > Ease of authoring can’t really be used as a basis for its consideration. > John F made an excellent point the other night: unless they’re just > inserting occasional blocks of text, most people who write captions will not > be writing them by hand with NotePad or TextEdit, they’ll use an application > like MAGpie, Subtitle Workshop or a broadcast-level suite to create and > format them. There are more srt files available on the Web than DFXP files. In fact, I have found it really difficult to find DFXP files in use in the wild. A list of such would be really helpful for implementation purposes. You'd be amazed how many people create srt files by hand or with a simple application that is available for free from the Internet. If you search for "subtitles" on Google, almost the whole first page points to sites that provide subtitles in srt format or to free software to create them, e.g. http://www.opensubtitles.org/ http://www.jubler.org/ http://subscene.com/ http://www.allsubs.org/ http://www.divxsubtitles.net/ http://www.podnapisi.net/ http://www.mysubtitles.com/ I wasn't able to find a single site that offers DFXP or SmilText files. > From my perspective, SmilText or profile of DFXP (or both) would be best as > a recommended caption-text format. That’s not to say we shouldn’t include > SRT in the list, but I just don’t think it should be the primary > recommendation. There is no primary recommendation. Right now DFXP and srt stand on the same line and both should be implemented. But an srt implementation will be trivial and for DFXP we may still need to come up with a common profile. So, there is work to be done and it will definitely take longer to have more than just basic DFXP support. Is there a reason that both SmilText and DFXP should be recommended? The examples at http://www.w3.org/TR/SMIL3/smil-text.html look a lot like some of the examples in DFXP. Best Regards, Silvia.
Received on Thursday, 18 February 2010 23:53:17 UTC