[Bug 13359] A way is needed to identify the type of data in a track element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13359

--- Comment #11 from Glenn Adams <glenn@skynav.com> 2011-08-20 16:28:01 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > (In reply to comment #5)
> > > > > (In reply to comment #4)
> > > > > > (In reply to comment #3)
> > > > > > To expand, consider 3rd party P adding three in-band signaling tracks: IB1 -
> > > > > > content advisories for parental control, IB2 - SCTE35 segment descriptors for
> > > > > > targeted advertising and IB3 - EISS for interactive television. The user agent
> > > > > > executing Page O recognizes these in-band tracks and sources them as three
> > > > > > different track elements with kind = metadata as described in [1]. Since the
> > > > > > user agent knows how to recognize these in-band tracks it can inform JS of the
> > > > > > metadata type by a new TextTrack.type IDL attribute. Without this new
> > > > > > attribute, JS will have to contain logic to infer the metadata type, redoing
> > > > > > what the UA has already done.
> > > > > 
> > > > > How would a general-purpose UA (such as Opera, Chrome, Safari or Firefox)
> > > > > recognize IB1, IB2, and IB3? They are not specified in HTML so there is no
> > > > > requirement for them to be able to decode them and I haven't seen any moves
> > > > > that spans across these and other UAs to make IB1-3 a standard-supported format
> > > > > in them. If there is, then it would make a lot more sense to have actual
> > > > > kind=IB1-3 values as part of the spec IMHO.
> > > > 
> > > > There is no requirement that an HTML5 UA decode PNG files, JPEG files, MPEG
> > > > video, or even JavaScript or CSS for that matter. So what's the point of your
> > > > question?
> > > 
> > > There is also no field in HTML that provides a hint on which image file format
> > > is being used. Why would there need to be one that hints on which metadata
> > > format is being used?
> > 
> > Because we are not talking about the UA interpreting the metadata here, we are
> > talking about client JS interpreting the metadata (track). The utility of
> > TextTrackCue.getCueAsSource() is put in question unless some information is
> > provided on type. The alternative is that the JS client code must perform
> > content sniffing on the result of getCueAsSource().
> 
> 
> Why not just use a data-type attribute that provides this information?
> JS-interpreted data is what the data-* attributes are made for.
> 

In the use case mentioned previously, the page originator does not know a
priori the type of the track metadata, so it cannot effectively provide a hint.

> 
> > Also, I believe the request here is not for a markup supplied hint of type, but
> > a UA determined actual type (presuming the UA has an embedded sniffer or access
> > to other content type metadata in the transport or content) in order to supply
> > actual type information via an IDL attribute.
> 
> 
> "it is proposed that a @type attribute be added to the track element and an
> associated IDL attribute be added to the TextTrack interface" - that's a
> request for a content attribute IIUC.

You're correct. One reads this as a request for a content authored hint of
type, with the hint reflected into IDL. Perhaps Bob needs to adjust the request
to reflect that it is for an IDL attribute that exposes a UA determined
*actual* type, or if the UA cannot determine actual type, then a type
indication based on envelope or other context information accompanying or
referred to by the track content itself.

For example, if the track content is obtained via HTTP, then the UA could
either sniff the content to verify actual type or it could pass along a
Content-Type header value to the client JS via TextTrack.type.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Saturday, 20 August 2011 16:28:05 UTC