This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25733 - Add reference to external "Sourcing In-band Media Resource Tracks from Media Containers into HTML" spec
Summary: Add reference to external "Sourcing In-band Media Resource Tracks from Media ...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: CR HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Sam Ruby
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
: 25732 (view as bug list)
Depends on:
Blocks: 25581
  Show dependency tree / graph
 
Reported: 2014-05-15 19:37 UTC by Bob Lund
Modified: 2014-07-21 19:42 UTC (History)
7 users (show)

See Also:

Attachments

Description Bob Lund 2014-05-15 19:37:32 UTC 
There has been discussion in bugs [1][2][3][4] about creating a specification for sourcing  in-band tracks in media resources. This bug proposes the following steps to effect this change.

1) A proposal was made to public-html-admin [5] as a first step in creating an HTML WG Note based on “Sourcing In-band Media Resource Tracks” [6].

2) An informative reference to this WG Note, e.g. [INBANDTRACK] would be added to the HTML 5.0 spec.

3) Language would be added to HTML 5 Sourcing in-band text tracks [7][8], e.g.
“The sourcing in-band tracks specification [INBANDTRACK] provides guidelines
for the creation of video, audio and text tracks and their attribute
values as mapped from in-band tracks in media resource types typically
supported by User Agents. Implementations are encouraged to include
guidelines in this specification for media resource types they support to facilitate interoperability. The sourcing in-band tracks specification [INBANDTRACK] is the authoritative reference for sourcing in-band track guidelines. An implementation that supports a resource type listed in the sourcing
specification must conform to the specification guidelines for that media
resource type.”

4) Existing text in [7][8] could be changed to refer to [INBANDTRACK]

5) The HTML5 AudioTrackList and VideoTrackList Objects sections [9][10] should also refer to [INBANDTRACK] for setting audio/video id, kind, label and language

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25132
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25133
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24986
[4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24997
[5] http://lists.w3.org/Archives/Public/public-html-admin/2014May/0029.html
[6] http://rawgit.com/silviapfeiffer/HTMLSourcingInbandTracks/master/index.html
[7] http://www.w3.org/TR/html5/embedded-content-0.html#sourcing-in-band-text-tracks
[8] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#sourcing-in-band-text-tracks
[9] http://www.w3.org/TR/html5/embedded-content-0.html#audiotracklist-and-videotracklist-objects
[10] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#audiotracklist-and-videotracklist-objects
Comment 1 Bob Lund 2014-05-15 19:38:03 UTC 
*** Bug 25732 has been marked as a duplicate of this bug. ***
Comment 2 Silvia Pfeiffer 2014-06-01 04:13:04 UTC 
I'll take care of this as soon as the WG has a permanent URL for this spec.
Comment 3 Silvia Pfeiffer 2014-06-06 04:47:43 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted

Change Description:
https://github.com/w3c/html/commit/c3a32873e10c45fc948541ca229914d4cf07cdee

Rationale: Added for bug 24997
Comment 4 Sam Ruby 2014-06-17 17:39:29 UTC 
After discussing this with PLH, the chairs are reopening this bug pending a discussion with the Director.  The concern is specs referenced by this registry containing normative statements and not being published in accordance with the W3C's IPR policy.

PLH intends to schedule this during HTML5's last call period.  The chairs support the need for a light weight process here.
Comment 5 Silvia Pfeiffer 2014-06-17 23:37:37 UTC 
Please note that the "Sourcing In-band Media Resource Tracks from Media Containers into HTML" spec is only referenced as "(Non-normative)" in the HTML spec. Therefore, it should not matter to the HTML spec. However, it will matter to how the "Sourcing In-band Media Resource Tracks from Media Containers into HTML" itself will be published. Looking forward to the advice.
Comment 6 Philippe Le Hegaret 2014-07-16 12:11:01 UTC 
As long as The Group is fine with making informative statements and having the informative reference, we're fine.

As a side note, publishing the registry in the dated space of W3C isn't ideal since it doesn't take the update automatic. I'm open to alternative approaches on that front.
Comment 7 Robin Berjon 2014-07-17 10:17:37 UTC 
(In reply to Philippe Le Hegaret from comment #6)
> As long as The Group is fine with making informative statements and having
> the informative reference, we're fine.

My understanding is that there is no objection to this.

> As a side note, publishing the registry in the dated space of W3C isn't
> ideal since it doesn't take the update automatic. I'm open to alternative
> approaches on that front.

I'm not sure what you mean by making the update automatic. Do you mean making it so that the editors can write there? Unless I'm mistaken, that's in fact possible — or at least we used to do it.

Alternatively, these could also be on dev.w3, dvcs.w3, etc.
Comment 8 Sam Ruby 2014-07-21 19:42:17 UTC 
As there are no objections to the original fix, I'm returning this to RESOLVED FIXED.