RE: Text Subteam Minutes for 8 May

Hi Silvia,

Silvia Pfeiffer wrote:
> >
> >   <JF> @kind="metadata" is not defined to take time-stamped files
> 
> That is wrong. All <track> resources require time-stamped content. Why do
you
> believe otherwise?

Because it doesn't actually say that anywhere that I can see, for one, and
specifically, the @kind value of metadata remains completely undefined
today. Can you point to where kind="metadata" is defined as time-stamped
content only? If metadata does not require being timed content (what would
that even look like?), then this refutes the assertion that all <track>s
MUST be time-stamped.

Finally, if we really wanted to play semantic games, I could use TTML with
role="transcript", and off I go. This is an artificial restriction (IMHO)
and is not a good reason to not continuing to pursue the use of <track>.

FWIW, there were a number of other engineers in the room while this
discussion was had, including many with more than a passing knowledge of
video and media on the web(*), and the "timed text only" argument did not
seem to hold much credence with them either. I respect your opinion here,
but it is but one opinion, and I have not been convinced that it is totally
correct.

(* Frank Olivier & Adrian Bateman from Microsoft, David Dorwin & Aaron
Colwell from Google, Bob Lund from Cable Labs, Mark Vickers from Comcast,
Yosuke Funahashi from Tomo-Digi, and Cynthia Shelley was able to have a
brief on-line chat with Sean Hayes who also supported using <track> in this
fashion) 

> 
> Overloading track is not the right thing to do from a data structure. POV.
We
> have to find another solution.

Re-use is a common language and design pattern, and has some significant
value, especially in the area of author education, where using <track> as
the vehicle for adding all textual support files to the <video> element is
elegant, is easy to explain, understand and hand-author, and adopts itself
to easy implementation in WYSIWYG editors. No technical reason has been
brought forward to prove that this is not a viable path forward. 

Besides, as Jonas Sicking has previously noted, this is software, we can do
anything. 
(http://lists.w3.org/Archives/Public/public-html/2011Mar/0627.html). 



Silvia, at this time I think that options are starting to narrow, and time
is running out. If you have another suggestion please do bring it forward,
but I for one (and I will be bold enough to channel other members of the
accessibility community) reject outright deferring this to HTML.next; I also
reject that a linkage to transcripts *MUST* only be rendered as on-screen
text. I have no appetite to make this a longdesc-by-proxy discussion, but in
2012 insisting that an on-screen text link as the ONLY method to link a
transcript (the IDREF proposal) simply does not hold water, sorry. It shows
a particular lack of creativity and narrow-mindedness that I find hard to
accept.

JF

Received on Thursday, 10 May 2012 06:42:23 UTC