[Bug 25353] [DataCue] change DOMString? text to any? value

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25353

--- Comment #16 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
Some time ago, I wrote a blog post on "Your metadata is not my metadata":
http://gingertech.net/2010/10/01/your-metadata-is-not-my-metadata/ . I think
this whole thread is a prime example of this.

Here are are some replies in random order on the various topics of discussion:

* "text track" is a misnomer
I agree to some extent. The "text track" concept is really about time-aligned
blobs of data. However, there are some implications of this naming that I like: 
  - text is clearly a discontinuous data stream (i.e. we have to expect gaps in
the timeline). 
  - we don't expect a text track to be of as high volume as a video track.
  - the main use case, while not the only one, is text-based, namely captions
and subtitles.
  - captions/subtitles have a history and well understood properties - "data
track" would be a fair bit less concrete, though in hindsight might have been a
better choice

* DataCue objects created for metadata
While DataCue objects are on a kind=@metadata track, that use of the word
"metadata" is actually wrong (since "timed blobs of data" clearly aren't
metadata). So, we should have probably used kind=@timeddata rather than
kind=@metadata (maybe we can still fix this - let's see).


To make clear what we created DataCue for, I've gone ahead and explained its
use in the context of Matroska subtitle tracks - in particular SSA/ASS tracks:
http://rawgit.com/silviapfeiffer/HTMLSourcingInbandTracks/master/index.html#webm
(see the green notes)

This is the use case that we created DataCue for: streams of data extracted
from a media resource that the UA finds easy to map into TextTrackCue objects
to hand over to JS, but has no intention of rendering or even parsing.

We did not create DataCue for parsed content!

Therefore, for the suggested use case of timed *metadata* (the sort that I
called "Timed Semantic Metadata" in my blog post), we should think of something
more useful. I would suggest we invent a JSONCue for that and chuck all parsed
metadata into JSON objects that we let the browser extract.

Here's what I would suggest:

[Constructor(double startTime, double endTime, JSONObject metadata)]
interface JSONCue : TextTrackCue {
                    JSONObject metadata;
  readonly attribute DOMString type;
}

** metadata would contain the actual metadata
** type would contain a descriptor for what kind of metadata this is - we might
need to start a list (e.g. 'id3')

This is using the JSONObject as defined in ECMA-262 [1]. We could also make it
a JSONArray, but then we'd not have structured metadata. That's fine IMO, but
maybe we don't have to be this strict.

This will allow the creation of timed metadata tracks for media resources, such
as timed ID3 tags, or marking time intervals where there are ads expected, or
marking time intervals for copyright and other rights ownership, or for
viewership restrictions etc.

Since we're including @type into the cue, it's possible to mash up all sorts of
timed metadata in a single track, which is ok, seeing as the browser is not
rendering any of it and just handing over the data to the JS dev.

Incidentally, defining the @type values doesn't need us to also define the
format of the JSON blob that's in @metadata, seeing as we're leaving the
interpretation of that blob to the JS dev. They can do whatever data
analysis/filtering they need.

Thoughts?



[1] http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 19 May 2014 08:06:30 UTC