- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 13 Sep 2012 09:00:08 +0200
- To: public-texttracks <public-texttracks@w3.org>, "David Singer" <singer@apple.com>
On Wed, 12 Sep 2012 23:00:53 +0200, David Singer <singer@apple.com> wrote: > > On Sep 12, 2012, at 13:24 , Ian Hickson <ian@hixie.ch> wrote: > >> On Wed, 12 Sep 2012, David Singer wrote: >>> >>> Even in the case where final deployment is on the web, we identified at >>> least one instance where keeping a file 'tagged' in workflows would be >>> beneficial. >> >> (Is there a bug filed on this case, by the way?) > > > I never did describe a captioning workflow, did I? My apologies. > > (I was surprised when I learned this; you may be, too.) > > > Apparently, captioning and sub-titling are often done under contract by > other houses than the maker of the original material (not a surprise) -- > and the original material owner (e.g. film studio) often has limited > rights to use the caption file(s) -- limited in both where they can use > the file (e.g. on TV only, not on the web, or in the USA only, not > Europe) and when or for how long. The original studio often doesn't > (often, is not allowed to) retain the caption file after the time runs > out. > > As a result, when (enter the 3rd protagonist) wants to use a piece of > content and have captions, they often have to contact both the studio > and (if they can find out who it is) the caption house. Confirming that > the caption file is correct for the version of the film they have (the > same edit with the same timing) is sometimes needed, and so on. > > (Yes, it's a mess. No, I can't change it.) > > > The upshot is that it's pretty useful for caption files to be > self-documenting; I don't think we need to say what attributes/values > they need in them (e.g. a content ID, title, etc.), but leaving space > for attribute value pairs that can be used for this is pretty useful. I > think we proposed stating that X- attribute names were open for > experimentation and this kind of 'in house' use, and would be sure not > to conflict with a standard name defined later; this seems enough for > now, to me. > > (Yes, you could insist that they are zipped up with their documentation, > but self-describing files are more clean, and -- importantly -- less > likely to get detached from their descriptions). > > Yes, this could be covered by comments, but I have seen too many places > where comments ended up having to have a 'required structure' to be > machine parsable; I'd rather reserve comments for human reading, and > attributes for machine reading, and not mix the two if possible. This is a decidedly non-Web use case. Do we have any reason to believe that WebVTT will be used as the exchange format between film studios and captioning houses? I don't really see why we should try to accommodate for non-Web users, in particular until they themselves come to ask for it. As for "X-": http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful-01 -- Philip Jägenstedt Core Developer Opera Software
Received on Thursday, 13 September 2012 07:00:48 UTC