This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The introduction has confusing wording regardnig text track cues. The sentence: "Another generic rule to follow for in-band data tracks is that in order to map them to TextTrack objects, they need to be mapped to media-time aligned cues that relate to a non-zero interval of time. " Should be rephrased: "Another generic rule to follow for in-band data tracks is that in order to map them to TextTrack objects, the contents of the track need to be mapped to media-time aligned cues that relate to a non-zero interval of time." Then, while the sentence above uses "in-band data tracks" rightfully, the bullet point list below indicates: "5. Mapping text track content into text track cues." which says "text track content". I would say: "5. Mapping track content into text track cues, when applicable." You may have binary data mapped onto DataCues.
Created pull request: https://github.com/w3c/HTMLSourcingInbandTracks/pull/22 Please note that in the 5. headings, "Text Track" is the general name for any collection of time-aligned data and/or text cues in HTML, so I'm not renaming that. It merely references the content extracted in step 3.
Thanks for the changes. I still think the name of in the heading should be changed. If it talks about a "Text Track" (capital Ts), as your fix suggests, there is no need to map its content to cues because by definition a "Text Track" is made of cues. The mapping is only needed when there is no "Text Track" yet, i.e. when the input is a "text track" or "data track".
I'm confused about the proposed solution. Why can't in-band data tracks be mapped to TextTrack objects without exposing Cues? This would be appropriate for data tracks whose payload is decoded by a platform/native media player and never exposed to HTML but where an HTML page may want to control which (if any) in-band data track is presented.
Jon, by which proposed solution are you confused: mine or Silvia's changes ? I don't see a problem in having in-band data tracks be mapped to Text Tracks for the purpose of selecting them. In this case though, there is no cue mapping. Anyway, my comment was not about that aspect but just about changing "text tracks" to "data tracks" which is more generic.
Cyril: TextTrackCue objects don't magically just appear. You have to define what fields in the in-band text/data track are mapped to what fields in the TextTrackCue object. So, mapping to cues is required no matter whether the track is a "data" track or a "text" track. By definition, all time-aligned tracks that are not video or audio are "Text Tracks".
Silvia: sure. I think there is a misunderstanding here. The text is confusing because it talks about "Text Track" and not "text track" or "data track". To me "Text Track" is the output of the mapping, the HTML 5 object, not the input. I'd simply suggest: "Mapping Text Track content into text track cues" should be "Mapping track content into TextTrackCue objects"
Fixed in https://github.com/w3c/HTMLSourcingInbandTracks/pull/22