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

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

--- Comment #4 from Aaron Colwell <acolwell@google.com> ---
(In reply to Bob Lund from comment #3)
> (In reply to Aaron Colwell from comment #2)
> > I'm concerned this will lead to unspeced "protocols" between the UA and the
> > web application if we do this. Why is having a generic DataCue that returns
> > an any better than defining specific cue types for different types of
> > information that can be returned?
> 
> There are many types of metadata used in various media containers and,
> initially, no way for script to determine what type of metadata was in the
> track. I filed a bug [1] to address this limitation. The resolution was
> creation of inBandTrackMetadataDispatchType that applied only to metadata
> text tracks. This resolution defined what the UA needed to provide so that
> the UA could provide script information to decode the track while not
> requiring the UA to know the syntax of all the various types of metadata.

I'm fine with this, but I'm wondering if it makes sense for the UA to emit a
DataCue for metadata that it actually knows how to parse. I thought DataCue was
only intended for things the UA doesn't know how to parse which is why I feel
like the .value property is a little strange.

> 
> As I understand this bug, there may be UAs that can recognize some types of
> metadata and, in this case, format the data for script. This ability doesn't
> solve the general case I identified in [1]; there are many more types of
> metadata that any UA will recognize. Case in point is Nielsen ratings added
> a new private data track to MPEG-2 TS and supplied a Web app that used this
> data to do ratings on browser based platforms. All the UA needed to do was
> to populate the inBand...DispatchType attribute and make the raw cue
> available. The UA did not need to be extended to recognize the new metadata
> cue syntax.

This seems reasonable to me and I have no problem with this assuming that there
is some sort of registry that indicates what the dispatch type refers to in the
underlying format. In your example here, I'd expect there to be a registry
entry that maps a string to specifics about how private track data is mapped to
DataCues. For opaque stuff like private tracks, I realize this is the best you
can do. For things like PMT and PAT, I think it is worth having explicit cue
types for those since it is pretty straightforward to identify and parse that
data.

>  
> > 
> > This feels a little like the postMessage()/onmessage pairing, but the
> > posting entity is not actually visible to the web application so it has no
> > idea what the universe of things to expect could contain.
> > 
> > I also feels like this is taking us away from the text track concept into
> > something more "timed event"-like which makes me wonder if this should even
> > be considered a text track.
> 
> I don't see this. The bug is asking for a way so that the UA can format the
> metadata for those types it recognizes. The timed aspect of text tracks is
> still there.

My problem is that in the general case this isn't "text" and doesn't really
have anything to do with captioning or accessibility. Calling this type of
stuff a text track is not quite accurate. For example, does PMT really have an
end time? Isn't it just active until the next PMT? Do we really want to keep
all PMTs in the cuesList especially since they occur frequently? I'm wondering
if these types of "data/metadata tracks" should really be their own thing and
not placed in the text track class hierarchy just because the text track stuff
looks close enough to what we need.

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

Received on Wednesday, 16 April 2014 17:17:00 UTC