Requirements from the Media API TF

This document lists the use cases, implied requirements and identified gaps that the Media API TF of the Web and TV IG has considered during its first iteration of work (March 2013 - February 2014)

Introduction

The Media APIs task force, part of the W3C Web and TV interest Group, merges the focus of three previously independent task forces (terminal, metadata and recording&downloading) and focuses on:

Identify requirements for recording and downloading media
Investigate requirements for discover and control of device capabilities (e.g. tuner control)
Investigate how to expose TV metadata to web applications
Investigate mapping between Media Element API and in-band metadata
Synchronization of broadcast content and web applications up to frame accurate

The task force works in iterations. Each iteration is made of 4 phases of work:

Phase 1: collect use cases
Phase 2: generate requirements
Phase 3: perform gap analysis, i.e.:
- Identify whether the requirements have been covered by existing specs or not
- If not, which specs/WGs would need to be addressed to fill these gaps?
Phase 4: consolidate UCs, reqs and gap analysis in one document and discuss next steps (reach out to WGs, etc)

This document it's a report of the result of the first iteration of work of the Media APIs task force.

Use Cases and Requirements

During the first phase of its work, the TF has asked members to contribute use cases that they were interested in investigating. Such use cases have been collected on the TF wiki and are available here

Starting from the Use Cases pointed above, the TF has derived a set of requirements; these are also recorded on the TF wiki and available here

The use cases and requirements have then been cross-referenced in a spreadsheet .

Gap Analysis

Based on the use cases and the requirements, the TF analyzed the gaps between the requirements and W3C specifications. The details of the result are available here.

There are 23 gaps across 10 specifications, which is summarized as follows:

Reqs	NSD	HTML5	HTML5.1	WebRTC	Web Storage	MSE	Push	Manifest	Service Worker	Web Crypto
#4 Service Synchronization	X							X
#5 Service Expiry	X							X
#5.2 Application Authentication										X
#6 Device Authentication					X
#7 Local Access Control	X
#8 Local Network Service Protection	X				X
#10 Wake-up Mechanism	X						X
#11 Service Information in Push Notification	X						X	X
#12 Offline Mode									X
#17 Tuner Control		X	X
#20 Content Download						X
#21 Metadata Protection				X	X
#21.B Metadata Protection (Offline)				X	X
#24 Content Recording while Watching			X

Some gaps can be addressed by one specification as an obvious way. We need to communicate with corresponding Working Group and get the estimation of if and when the gaps can be bridged.

Some gaps can be addressed by 2 or more specifications. We should communicate with corresponding Working Groups (WG), and find the best path (if, which and when) to fill the gap.

One particular features gap #17 Tuner Control, whose gaps was identified in HTML5, may have to go through a different route considering the heavy workload in HTML WG and precedent of how other feature gaps was handled, e.g. MSE, EME, WebVTT etc. Either a specific Task Force in HTML WG needs to be established to address this gap through the extension method or a Community group needs to be initiated to work on a new specification that can bridge this gap.

Next Steps

It is suggested that Web and TV IG take the following next steps:

Present the following WGs with the gaps and discuss the possible way to bridge those gaps:

Device APIs WG – NSD
HTML WG – HTML5, HTML5.1, MSE
WebApps WG – Manifest, Push, Service Worker, Web Storage
Web Crypto WG – Web Crypto API
WebRTC WG – WebRTC

Look into the possibility to initiated a Community Group to address the gap in Tuner Control