W3C

Web Media Profile

Guidelines for integration of interactive media services in a browser-based environment

W3C Editor's Draft 13 March 2012

This version:
Latest published version:
http://www.w3.org/TR/webtv-profile/
Previous version:
none
Editor:
Giuseppe Pascale, Opera

Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document was published by the Web and TV IG as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-web-and-tv@w3.org (subscribe, archives). All feedback is welcome.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

This section is non-normative.

1.1 Background

There is an increasing number of content and service providers worldwide that are deploying interactive video services based on web technologies. In order to achieve that, many organizations and companies have created profiles of web technologies suitable for use in a specific market and/or region. These profiles are supersets, subsets or both of several W3C specifications. Often these documents have been written without a direct involvement of relevant W3C working groups. Furthermore not always these different groups were aware of each other, leading to different profiles in different regions and markets. In some cases also extensions to web standards have been designed, leading to multiple incompatible solutions addressing the same use case.

The goal of this document is to reduce fragmentation and eliminate the needs for extensions, by providing a common meta-profile that allows external organizations to align with W3C and with each other. While is not possible to provide a profile that cover all needs of different organizations and stakeholders, this meta-profile tries to keep at a minimum the variables involved in defining new profiles, providing a common reference framework that different organization can reuse.

1.2 Design Goals

This sections list the goals that have driven the work on this document.

1.2.1 Avoid obsolesce

In the past decades, many attempts have been made to create profiles suitable for use in a specific market and/or region, particularly in the TV space, by external organizations. These groups have created documents which are supersets, subsets or both of several W3C specifications. Often, these external documents become obsolete when the W3C improves the related specifications since the W3C has little or no knowledge of these external documents. By working on a common TV profile within W3C it becomes easier to closely align external organizations with W3C and with each other and allows the W3C to move this profile forward on a regular basis to avoid obsolescence.

1.2.2 Improve interoperability

Use of web technologies in different markets and regions to create interactive TV services is increasing. TV services are not relegated anymore to TV sets and STBs but can be presented on a wide range of devices. Different organizations and companies have have defined their own profiles of web technologies that can be used in a given ecosystem to author content. These profiles are supersets, subsets or both of several W3C specifications. The proliferation of such profiles is making challenging to write content that works well across devices. By working on a common TV profile within W3C it becomes easier to closely align ongoing efforts of web based TV services in order to avoid fragmentation.

1.2.3 Coordinate deployments

The range of technologies available to web applications developers is theoretically wide. In practice, content developers have to fight with different levels of support of different specifications by different devices. This is inevitable since each implementer necessarily need to make a choice on what to implement and when. While in some ecosystems is fine to leave to each implementer to choose his own roadmap, in other ecosystems there is a need for coordination in order to harmonize the development cycle of the different stakeholders and provide a good user experience.

1.2.4 Provide a complete application environment

Many W3C specifications leave intentionally undefined some components that are essential to build a full application environment for interactive TV services. For example, the [HTML5] specification rely on "relevant specifications" to define rules for processing and rendering data coming from a media stream via an in-band track. Other examples of "variables" that are not specified in [HTML5] are supported video codecs or image formats. The same apply to other W3C specifications. Furthermore to provide a complete application environment, different specifications needs to be combined into one product, increasing the number of options and hence the level of fragmentation. This document aims to combine together relevant specification to provide a complete environment that can be used by different organizations as an application environment for their interactive TV services.

1.2.5 Do not reinvent the wheel

Some groups defined or discussed extensions to existing web technologies in order to cover use cases relevant for such groups. Sometime different groups have designed multiple incompatible extensions to cover the same use case. Other times what at a first look was identified as a gap in the web platform is resulted in actually being already supported reusing existing specifications. Since many use cases are common among different regions and organizations, by making the result of such analysis available in one document the risk that different groups defines new technologies to cover areas that are already well covered by existing specification (hence causing fragmentation) is reduced.

1.2.6 A tunable meta-profile

A profile document is generally beneficial for the industry because it provides a common environment that all different stakeholders can rely on with the ultimate goal of providing the best possible user experience. In doing this, several things need to be considered that sometimes go beyond technical standard activities and are rather close to business model of stakeholders. Furthermore, there are many different devices capable of presenting interactive TV services with different hardware capabilities that may also vary over time. Therefore is impossible to find a profile that suites all business models and devices. It is still beneficial though to identify and define all common parts in a meta profile that can be tuned as needed by other organizations, trying to keep the differences at a minimum.

1.3 Audience

...

1.4 Scope

The scope of this document is limited to:

The scope of this document is not to describe an entire operating system. In particular, hardware and software configuration that user would be expected to have on their devices are out of scope.

The scope of this document is not to describe a unique end-to-end delivery system. In particular, mandating a specific end-to-end network configuration (including network protocols, video codecs, video streaming technologies and so on) is out of scope for this document. Nonetheless this document may describe how some specific technologies may be combined together in order to provide a functional TV service.

2. Terminology

2.1 Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

2.2 Definitions

For the purposes of the present document, the following definitions apply:

3. System Overview

This section gives and overview of the typical architecture of an interactive TV services delivery system. The level of detail of this section is general and abstract: there is no attempt to provide an in-depth technical explanation of each component and of the interaction between them. Also in practice some logical components may be combined into one, and some components may be missing in some deployments and/or regions.

The main goal of this profile is to simplify and harmonize the production and delivery of TV Services to web enabled devices. For the purposes of this document a TV service is a commercial video service that may include elements of interactivity and that provides a coherent user experience. TV services are usually divided into two main groups: scheduled or linear services are the ones that have to be consumed by the user at the particular point in time when they are offered (e.g. a broadcast TV channel); on-demand services are the ones that can be consumed by the user at any point in time (e.g. web video portals).

In order to consume them, users need a device that is able to present TV services. Traditionally TV services have been consumed via TV sets or STBs connected to a display. Nowadays users have a wide range of devices (e.g. PC, laptops,smartphones, tablets) available both in their home and outside and expect to be able to access to TV services from any device.

TV services can be delivered to users via a variety of means. The most common means is via a uni-directional TV broadcast network. Different standards have been defined for such purpose, such as DVB, ATSC, ISDB. TV services may also be delivered via bi-directional IP connections, mainly via the Internet. An emerging scenario is represented by content streamed directly between devices connected via the home network. The term home network refers to the networking infrastructure that facilitates communications between devices within the home. This will typically (but not always) be connected to the Internet.

To provide a level of interactivity, TV services may be associated to or delivered as applications.

4. Application model

For the purposes of this document the term application refers to a collection of documents and associated resources that are authored using a set of languages commonly referred to as "web technologies" or "web standards". In order to be able to run applications, devices implement an interactive user agent commonly referred to as browser. The set of languages supported by browsers conforming to this profile are listed in section 5. Application Environment.

4.1 Launching applications

This section is non-normative.

4.2 Packaged applications

Should this be mandatory?

http://www.w3.org/mid/3721A4B2-266C-4C88-ABFD-9DC955EBD87C@gmail.com

While applications are commonly hosted on a Web Servers and the associated resources fetched by the browser when required, sometimes a single download and installation on a device is desirable. In order to enable this, devices must support the packaging format defined by the [WIDGETS] specification. Widgets are typically downloaded and installed on a client machine or device and can run as stand-alone applications, but they can also be embedded into Web pages and run in a browser.

5. Application Environment

This section lists which languages are supported by browsers conforming to this profile and that can be used to author applications. Browsers may support more languages than the ones listed in this section.

5.1 HTML

HTML is the markup language used to describe documents on the web. This profile rely on the 5th revision of HTML, also known as HTML5.

The [HTML5] specification defines conformance requirements for user agents and documents. Applications and authoring tools must comply with conformance requirements for documents unless differently specified in this document. Browsers must comply with conformance requirements for user agents unless differently specified in this document; in particular browsers must support the HTML syntax and the XHTML syntax for HTML documents as defined in [HTML5].

Do we need support for both syntaxes or can we go just for the HTML syntax?

HTML5 (by design) does not provide mechanisms for media-specific customization of presentation although several mechanisms to hook into languages and technologies that allow such customization are provided. Languages that are expected to be supported by browsers in connection with HTML5 are listed in the following sections.

5.2 Scripting

Scripts are small programs that can be embedded into applications. While defining features that rely on scripting, HTML5 do not mandate support for scripting for all user agents. Furthermore scripting is defined using a syntax that in most cases is independent from the underlying scripting language. For such reasons, this profile add the following additional requirements:

5.3 CSS

The list below needs review
Support for CSS as a whole is not required by HTML5, even though some features are defined in terms of specific CSS requirements. The following sections list modules and parameters that browsers conforming to this specification have to support.

5.3.1 CSS Properties

Browsers must support [CSS21].

5.3.3 CSS3 Basic Box Model

http://www.w3.org/TR/css3-box/

5.3.4 CSS3 Basic User Interface

http://www.w3.org/TR/css3-ui/

5.3.5 CSS3 Text Module

http://dev.w3.org/csswg/css3-text/

5.3.8 CSS Device Adaptation (viewport)

http://www.w3.org/TR/css-device-adapt/

5.3.9 CSS 'view-mode' Media Feature

http://www.w3.org/TR/view-mode/
Industry specifications may define additional mapping between CSS view modes and "system" view modes defined by such specifications

5.3.11 CSS3 Fonts

Are all features in CSS3 fonts stable enough to be implemented?
Browser must support [CSS3-FONTS]. The [CSS3-FONTS] module describes how font properties are specified and how font resources are loaded dynamically.

5.3.12 CSS3 Media Queries

The [CSS3-MEDIAQUERIES] module extend the functionality of media types by allowing more precise labeling of style sheets. A conforming browser must support media queries as defined in [CSS3-MEDIAQUERIES].
Maybe we want to list supported attributes anyway, in case more features are added to the spec after the profile is released.

5.3.13 CSS3 Backgrounds and Borders

This may need multiple subprofiles based on terminal capability
[CSS3-BG]

5.3.14 CSS3 2D Transform

This may need multiple subprofiles based on terminal capability
[CSS3-2D-TRANSFORMS]

5.3.15 CSS3 3D Transform

This may need multiple subprofiles based on terminal capability
[CSS3-3D-TRANSFORMS]

5.3.16 CSS3 Transitions

This may need multiple subprofiles based on terminal capability
http://www.w3.org/TR/css3-transitions/

5.4 XML HTTP Request

http://www.w3.org/TR/XMLHttpRequest/

5.5 Document Object Model (DOM)

Should be enough to rely on HTML5 here, i.e. on this section http://dev.w3.org/html5/spec/Overview.html#dependencies

5.6 Input Methods

5.6.1 Determine available input methods

I think we may want to be able to differentiate at least between these 3 set ups:

  • keyboard and mouse
  • touch screen
  • TV Remote
On the other end there are also mixed solutions. So another possible classification for input is:
  • Pointer based:
    • accurate pointing (mouse, trackball, stylus touch)
    • rough pointing (finger touch, wii)
    • no pointing
  • Key based:
    • full keyboard (desktop, laptop, blackberry)
    • limited keyboard (TV remote, nintendo ds, feature phones)
    • no keyboard

Some proprietary methods for some input methods exist, e.g. -moz-touch-enabled But there seem to be no universal method to determine input capabilities. Need to discuss this with relevant WGs (CSS, WebApps, WebEvents)

5.6.2 Traditional Remote Controls

Need to check the progress of DOM events in this area. See http://www.w3.org/TR/DOM-Level-3-Events/#remote-control

5.6.3 Touch screens

[TOUCH-EVENTS]

5.6.4 Mouse and Keyboard

5.6.5 Other input devices

5.7 Content Developers Guidelines

This section is non-normative.

6. Formats and Protocols

The aim of this section is to collect in one document the result of the discussion going on in different groups, like the HNTF or the MPTF of the web&tv IG. Therefore it should describe things like: and describe how these functionalities can be accessed by an application/user. If new specs needs to be written (as currently being discussed in different places) we need to decide if such specs should be part of this document or external documents referenced by this one (I prefer the second option). Note that ins some cases you have multiple protocols for the same functionalities, but we could still describe a unique way to expose such multiple protocols to the application/user.

6.1 Exposing Transport Metadata to Applications

6.2 Discovery and Communication with Home Network Services

No standard available at the moment. Useful references:

7. Testing

Relevant test material can be found here:

7.1 Testing Infrastructure

8. Performances

A. Acknowledgements

Thanks to ... for their contributions to this document

Thanks to participants of the following groups for their feedbacks: Web and TV Interest Group

B. References

B.1 Normative references

[CSS21]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification.. W3C Recommendation. URL: http://www.w3.org/TR/CSS21/
[CSS3-2D-TRANSFORMS]
Simon Fraser; Dean Jackson; David Hyatt; Chris Marrin; Edward O'Connor. CSS 2D Transforms Module Level 3. URL: http://www.w3.org/TR/css3-2d-transforms/
[CSS3-3D-TRANSFORMS]
Dean Jackson; David Hyatt; Chris Marrin. CSS 3D Transforms Module Level 3. URL: http://www.w3.org/TR/css3-3d-transforms
[CSS3-BG]
Elika J. Etemad; Bert Bos; Brad Kemper. CSS Backgrounds and Borders Module Level 3. URL: http://www.w3.org/TR/css3-background/
[CSS3-FONTS]
John Daggett (Mozilla). CSS Fonts Module Level 3 URL: http://www.w3.org/TR/css3-fonts
[CSS3-MEDIAQUERIES]
H. Lie, T. Çelik, D. Glazman, A. van Kesteren. Media Queries URL: http://www.w3.org/TR/css3-mediaqueries/
[ECMA-262]
ECMAScript Language Specification. December 1999. URL: http://www.ecma-international.org/publications/standards/Ecma-262.htm
[HTML5]
Ian Hickson; David Hyatt. HTML5. 25 May 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/html5
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[TOUCH-EVENTS]
Matt Brubeck; Sangwhan Moon; Doug Schepers; Touch Events version 1 URL: http://www.w3.org/TR/touch-events
[WIDGETS]
Marcos Cáceres. Widget Packaging and XML Configuration. W3C Recommendation. URL: http://www.w3.org/TR/widgets/

B.2 Informative references

No informative references.