[Bug 25354] [DataCue] data attribute should be ArrayBuffer?

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

--- Comment #5 from Aaron Colwell <acolwell@google.com> ---
(In reply to Eric Carlson from comment #4)
> (In reply to Aaron Colwell from comment #3)
> > (In reply to Brendan Long from comment #2)
> > > I think the idea is that we would generally provide either .data or .value,
> > > but if a UA gains the ability to parse the data and adds .value, it should
> > > continue providing .data if possible to avoid breaking existing applications.
> > > 
> > > I'm not opposed to splitting this into two different cue types if the
> > > consensus is that that's better though. For Apple's use-cases, we might want
> > > to start by defining an ID3Cue (or maybe more generically named, since
> > > name/value pairs are a common kind of metadata).
> > 
> > For known well defined things like ID3 I think it is better to define and
> > expose an ID3Cue instead of using something generic like DataCue. I would be
> > interested in participating in the discussion around exposing ID3 data via
> > an ID3Cue.
> 
> I wouldn't necessarily call ID3 a "well defined" format. An ID3 metadata
> item has a key and a value, and while you can infer the value's data type
> from the key in reality it can be anything at all.

Fair enough, but certain keys have particular meanings when considered in the
ID3 context. It is pretty straightforward to define what an ID3Cue would look
like and applications would know how to handle these key/value pairs when it
received an ID3Cue.

> 
> ID3 is not the only metadata format with *exactly* these characteristics
> (eg. QuickTime, MPEG-4, MPEG-7, etc). Are you really suggesting that we
> create different Cue types for every one?

It depends on which problem we are trying to solve. If we are trying to solve
the "How do I get song title, track, album data out for any media type?", then
it would probably make sense to have a specific cue type for this and define
mappings from all those formats into specific attributes. If we are trying to
solve the "Just expose the raw metadata in the underlying format" then I think
something like format specific cues or the combination of
TextTrack.inBandMetadataTrackDispatchType and DataCue w/ nothing but a .data
attribute is sufficient. I think any of these paths are easier to reason about
than sequences of DataCue<type, data>, DataCue<type, data, value>, or
DataCue<type, value>.

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

Received on Wednesday, 16 April 2014 18:10:31 UTC