- From: David Singer <singer@apple.com>
- Date: Wed, 12 Sep 2012 14:00:53 -0700
- To: public-texttracks <public-texttracks@w3.org>
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. David Singer Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 12 September 2012 21:01:21 UTC