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

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

--- Comment #7 from Aaron Colwell <acolwell@google.com> ---
(In reply to Eric Carlson from comment #6)
> (In reply to Aaron Colwell from comment #5)
> > (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 metadata values can be text, an image ("APIC") with optional MIME type,
> a defined structure (eg. "POPM", "AENC", etc), a number (eg. "PCNT"), or
> arbitrary binary data (GEOB) with optional MIME type. 
> 
> It seems to me that will require an ID3Cue attribute(s) to provide at least
> String, Object, and ArrayBuffer values. This is exactly what Ted is
> suggesting.

Are you planning on creating a DataCue for each individual frame in an ID3 tag?
I was assuming that a single ID3Cue would contain all the values in a single
tag. I was expecting ID3Cue to expose a map<DOMString, any> type interface. 

Was your plan for ID3 in DataCue to have .type be "ID3" and .value return an
Object with keys representing the frame name and the values being the frame
contents?

At the end of the day, I'd like there to be a way to force agreement on how
particular metadata is exposed so we don't end up with multiple ways for
exposing stuff like ID3. I'd also like provide a clear way to differentiate
between the UA having no clue what the data is vs it has parsed the data into
the agreed standardized structure for the application.

Do we actually need .data AND .value? Couldn't we just represent this as
something like .type = "unknown" (or "application/octet-stream" or "") and
.value = an ArrayBuffer() w/ the data? It seems like that would be better than
having everything optional.

> 
> > > 
> > > 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. 
> 
> I think we are trying to provide script access to arbitrary metadata carried
> in media files. Nothing more.
> 
> 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>.
> 
> http://id3.org/id3v2.4.0-frames defines more than 40 keys for "text" values
> alone. Do you suggest we define key names for all of them? 
> 
> We will have to have an escape mechanism for unknown keys, why not just use
> the ID3 keys as-is?

No. I was assuming the frame names would be used as the map keys.

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

Received on Wednesday, 16 April 2014 20:23:03 UTC