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

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

--- Comment #11 from Aaron Colwell <acolwell@google.com> ---
(In reply to Eric Carlson from comment #10)
> (In reply to Aaron Colwell from comment #9)
> > (In reply to Eric Carlson from comment #8)
> > > (In reply to Aaron Colwell from comment #7)
> > > > 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.
> > > > 
> > >   That was our original idea, but when we presented it at the F2F last week
> > > Maciej pointed out that that would make it difficult for a UA to return a
> > > typed value for a key after shipping a version where it returned it as an
> > > ArrayBuffer.
> > 
> > I guess I was under the assumption that .type would be different for the raw
> > unparsed vs parsed. Is the idea that it is better to roll out a single .type
> > that a UA can potentially backfill .value in a later revision instead of not
> > outputting a .type until the UA can support a parsed .value?
> 
> .type identifies the .key namespace. It should not change depending on
> whether or not the UA is able to parse the cue value.

I think I misunderstood an earlier comment you made. Are you planning on
creating a new DataCue for each ID3 frame in a single ID3 tag? I was assuming
that you were grouping all the ID3 frames contained in a ID3 tag in a single
DataCue. My assumption was that parsed vs unparsed frame values would be an
internal detail of the ID3 mapping to DataCue.value and not leak out into the
DataCue interface itself.

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

Received on Thursday, 17 April 2014 19:17:46 UTC