Status of this document
This Note was produced by the W3C TV-Web Interest Group. It is the result
of discussions on URI schemes suited for use in TV Broadcast environments. The
document reflects preliminary results, and is intended to serve as a base to
further work to design TV Broadcast URIs. Please send comments to the TV-Web
mailing list firstname.lastname@example.org.
Publication of a W3C Note does not imply endorsement by the entire W3C
Membership. A list of current W3C technical reports and publications,
including Working Drafts and Notes, can be found at http://www.w3.org/TR.
This section represents the status of
this document at the time this version was published. It will become outdated
if and when a new version is published. The latest status is
maintained at the W3C.
Table of Contents
- 1. TV Broadcast: Definition and scope
- 2. Application Scenarios
- 3. Requirements on Global TV Broadcast URI
- 4. Exceptions in TV Broadcast URIs
This document is an informational document and discusses the requirements
posed to URI schemes for identifying resources in TV Broadcast environments.
The document is the outcome of discussions on this subject by the W3C TV-Web
Interest Group [TVWebIG, TVWebMail].
Typical use cases are summarized where TV Broadcast URIs are involved. A
distinction is made between Global and Local usage. Also, a hierarchy of
resource types is identified. Requirements related to the Global usage case
Definition of TV Broadcast
In this document TV Broadcast is used as the generic term to refer
to currently existing TV systems, their transport protocols, and their typical
operation of content provision and distribution. TV Broadcast concerns both
digital and analog systems and includes systems like DVB, ATSC, DSS, NTSC, and
PAL. The TV Broadcast "network layer" is typically non-IP based.
The term TV Broadcast URI refers to URIs which identify, and
possibly locate, TV Broadcast content. In this document "URI" is used
to indicate TV Broadcast URI.
Typically, TV Broadcast systems are push systems. The content streamed
along a TV Broadcast transport is scheduled by the service provider; the user
has no influence on that. In this model the user accesses the stream(s) rather
than the server at the upstream station.
Hierarchy in TV Broadcast content
TV Broadcast content is modeled in a four-layer hierachy, consisting of
service, event, component, and fragment. Service is at the top, fragment is at
the bottom of the hierarchy.
The term service is used to refer to a concatenation of programs,
all being broadcast by the same service provider. The programs of a service
share some tuning characteristics. Service corresponds to the naming "channel"
as used in today's analog TV.
The term event is used to refer to a single TV program. An event
consumes a time period within a service and therefore can be characterized
with begin and end times. The service provider determines the granularity in
which the service is split in events. An event can be a complete program or an
episode of a program. Events can be grouped in series, e.g., to form a serial.
Events are the typical entities which EPGs list to present program schedule
The term component is used to refer the constituents of an event.
The audio and video of a TV program are obvious examples. In case of
multilingual programs there are multiple audio components. In case of
interactive programs the components are the application documents and the
other data these applications are using. Next to continuous data like audio
and video, component also encompasses discrete data like Web pages and
applications describing composition and interactivity. The URI identifying an
application can constitute the base URI for the further components referenced
by that application.
The term fragment is used to refer to a subpart of a component.
For instance, it can be a slice of a video sequence, or a subregion in an
Due to the push character of TV Broadcast there are two dimensions of
hierarchy, a schedule related and a content related. The first is the
hierarchy of transport system, transport stream, service, series, event; The
second is the hierarchy of series, event, component, fragment.
The term resource is to be understood as in RFC 2396, sec.1.1
[RFC2396]. In the context of TV Broadcast a resource refers to the entities
service, event, component, and fragment in particular.
Setting and usage of TV Broadcast URIs
TV Broadcast applications need a mechanism to identify and locate the
components building the application. The URI scheme is a useful tool for that
as it opens possibilities for seamless transition in referencing resources at
TV Broadcast transport and Internet sites. URI schemes to locate resources at
the Internet are well-known, and are not further observed in this document.
URI schemes to locate resources in a TV Broadcast transport channel have been
proposed, but most are designed with a particular TV Broadcast transport
environment in mind.
Next to locating components at TV Broadcast transport channels, another
aspect of TV Broadcast URIs concerns referencing the events. In the first
place, events are accessible at the TV Broadcast transport channel, possibly
at several channels and at multiple periods of time. The above mentioned URI
schemes also address this aspect, but all in their own way. In the second
place, the content may be stored and made available through another path than
the TV Broadcast transport channel. Most evident are local storage, like
VCR-type of devices, and the Internet itself. Local storage devices can be
connected through an in-home network to the user agent presenting the
application. Local storage in the sense of the client's local file system or
in the sense of cache buffering are not observed in this document.
TV Broadcast content delivered through a so-called IP-tunnel is considered
as content made available through the Internet. An IP-tunnel refers to a
forwarding path which is logically separated from the conventional TV
Broadcast transport protocol but uses the same physical transmission link.
Application types, further definition and scope
Applications can be distinguished in usage of URIs for Global and Local
Global refers to URIs contained in documents which can be accessed
anywhere around the world, and which identify content related to any TV
Broadcast system in the world, including storage devices associated with that
TV Broadcast system. Such a global URI may include identification of the TV
Broadcast system to be used.
Local refers to URIs contained in documents which are accessed
within a certain TV Broadcast system, and which identify content to be
accessed through that TV Broadcast system. URIs that reference content outside
the local TV Broadcast system, are assumed to be either Global URIs or
traditional URIs for locating resources at the Internet.
This document concentrates on Global URIs, as those have a world-wide
interest for standardization. It would be nice when Local URIs bear an
identical format, but that is considered not a necessary requirement. Local
URIs can be specified within their respective application domains. On the
other hand, it would be nice when Global URIs can serve as a base URI for
Local URIs, either as direct copy or by some mapping function.
Further, URIs can be distinguished in identifying a service or event, and
in identifying a particular content item (component or fragment) in such a
service or event. This reflects the two dimensions observed above of schedule
related and content related hierarchy. The use cases where a content item in a
certain service is to be identified while the context isn't already that
service, seem rare. Consequently, a URI is not required to carry both
informations (service and content item) together.
This distinction suggests that identification of a particular content item
belongs to the Local class of URIs, and that Global URIs typically identify a
service or an event. However, an exception can be found in the case where the
same content item is referenced in various transport contexts, e.g. in a
An important class of Global URIs identify their resource in a location and
time independent way, i.e. independent of the particular TV Broadcast
transport system and particular schedule. For instance, they are also valid
after local storage. As such, they resemble URN behavior, opposed to URL
As the set of resources and their various locations can scale to large
numbers, it is preferred that the URI scheme imposes a hierarchical structure,
certainly when the URI's purpose is to locate a resource. A hierarchy allows
for step-by-step resolution and navigation to the resource identified. By
that, efficiency and scalability is improved. Further, implying a hierarchical
structure allows to group resources, and by that to distinguish between, for
example, in identifying a serial and an event in that serial.
Use cases, both Local and Global URI
Below, some representative use cases are listed. An exhaustive list of
application scenarios is provided in [USECASES].
- Basic EPG type of locating:
Reference TV Broadcast services and events from a Web page for navigating
to them. The references are tolerant to modifications in the actual
transmission schedule, but a coarse indication can be derived. The
broadcast program can be indicated through tuning data or through naming.
Next to navigation to the program, the EPG also supports for setting
reminders or recording of programs. Instead of a single program, the
serial of which the program is part, is referred to, such that setting a
reminder or a recording for all episodes can be accomplished.
It is the year 2002. Fox is broadcasting a World Cup game from South Korea
in both analog and digital formats, with the broadcast reaching North
America, Europe, Africa, Asia, Latin America, Australia, etc., through a
wide variety of local affiliates and re-broadcast operators. Fox wishes
to put a hyperlink to the broadcast on its web site, so that users of
Internet-connected TV receivers all over the world with the right software
(perhaps native, perhaps downloaded) can click on the hyperlink and have
their receivers tune to the broadcast (or set a reminder for the
broadcast, if the game is not currently on).
- A sports fanatic wants to watch all the above broadcasts by Fox.
Therefore he records all the broadcasts and copies the above Fox World Cup
page to his local disc. From that page he can access the broadcasts or,
when they have been recorded, view them from his recording device. At its
site Fox also provides the transmitted broadcasts, albeit at high
compression rates. The page will direct users who haven't recorded the
broadcast to these videos.
- A Web page is composed for presentation on a TV Broadcast receiver. The
Web page is delivered in association with a TV Broadcast program (the
transmission paths may be physically separated). The Web page includes an
object which refers to the associated audio/video image of the TV
- In a Web page a TV Broadcast event is referred, but the exact location
is not known at authoring time. The URI is incomplete in its information.
Instead a query is added to retrieve the missing information. When the
available TV Broadcast system supports the query mechanism, the URI can be
resolved and the identified resource can be retrieved. The query language
is technology-independent, i.e. it is not relying on specific fields, such
as SI data, in the TV Broadcast transmission system.
- A TV Broadcast of a soccer match is data-enhanced; in a data carousel
module or an encapsulated IP datagram a file is contained which gives
up-to-the-second statistics on goals scored, fouls committed, corner kicks
taken, shots at goal, shots on goal, etc. The broadcaster wants to put a
URI on their web site which references this file, allowing applications on
Internet-connected TV receivers all over the world to get to the file and
display it in nifty ways.
- A data file is transmitted along with a TV program, the data file is
containing additional information to that program. It also contains
hyperlinks to the programs and/or data in other data files being broadcast
on the same channel and in other channels, so that receivers can set
reminders for the upcoming game and/or data file.
- A Web page is transmitted with a TV Broadcast commercial. The commercial
is about an upcoming TV Broadcast program. The viewer can click a hotspot
area such as to set a reminder for that program. The Web page can also be
accessed at the broadcaster's Web site.
- A set of three Web page is transmitted with a TV Broadcast commercial.
The viewer can navigate the three pages. The pages are transmitted
frequently along various TV Broadcast systems. The pages can also be
accessed at the advertiser's Web site, where they are maintained at a
particular sub directory. Therefore, the advertiser uses relative
referencing between the pages.
- A live quiz show is enhanced such that the viewer can play along. The
enhancement data are a mixture of Web pages, which compose the quiz's
question and answer environment, element values, which carry the actual
questions and (correct) answers to be inserted in the Web pages, and
procedural cells to control the viewer's score. The Web pages are provided
at a Web site long before the show is aired, such that viewers can
prepare. The element values are transported along the TV Broadcast
transmission channel during the show. They are synchronized with the
actions in the show such as to complete and update the application.
There are several levels of play along: some pages provide the viewer with
hints such as to ease answering, and some pages provide less alternatives
in the multiple choice questions. The viewer can select his level by
navigating between these pages.
Upon the actual broadcast an application is broadcast with the program to
initiate the enhancement. The application references the Web site, such
that upon tuning to the TV Broadcast the Web site's home page gets
retrieved. Triggered by stream events in the TV Broadcast transport
stream, the application also controls the insertion of element values
(questions and answers) and the score management (e.g., no score increment
after answer presentation).
- A Web site provides a EPG covering programs transmitted world-wide. A
viewer is visiting this site and browses the EPG. Upon encountering his
favorite movie "Once upon a time in the Cyber" he clicks the item on the
EPG. Regretfully, the movie isn't scheduled for the 419 TV Broadcast
satellites his receiver is configured to. Instead of setting a reminder,
the receiver informs the user the movie will not appear on his reception
Conventions used in this document
In this document three levels of priority are used to indicate the
desirability of a requirement.
- The key word "MUST" is to be understood as an essential and critical
- The key word "SHOULD" indicates an important requirement.
- The key word "MAY" indicates a useful feature.
[These key words and their meaning are based upon RFC 2119 [RFC2119]. That
RFC specifies similar wording for implementation compliance with a protocol
specification. In this document the wording reflects specification compliance
with protocol goals.]
TV Broadcast differs from the conventional Internet in several ways. The TV
Broadcast URI scheme is affected by that in the following aspects:
- The URI scheme MUST comply with RFC 2396 [RFC2396].
- Where the URI serves as a name identifier (URN), the corresponding URN
specifications MUST be taken into account, e.g. [RFC2141, RFC2168].
- Where the URI serves as a locator identifier (URL), the definition of
the URI scheme MUST follow the guidelines as set forth in [URLGUIDE].
- The URI MAY support queries to be posed to the TV Broadcast receiver.
The query language MUST be independent to the TV Broadcast system.
- The URI scheme SHOULD support relative referencing such that a
TV-program with all its associated resources can be referenced against a
common base, which is the TV Broadcast URI of that aggregate.
- Where the URI serves as a locator identifier (URL), the URI scheme
SHOULD include a hierarchical structure either to identify the resoure as
a service or an event from a service, or to identify the resource as an
event, a component from an event, or a fragment from a component. The
structure SHOULD provide optional levels to group events into series or
serials and to group components into composites.
Where the URI serves as a name identifier (URN), the URI scheme MAY
include such hierarchical structure.
- The URI scheme SHOULD support the spectrum of transport protocols
applied and standardized in TV Broadcast systems. This includes both
audio/video and data broadcast protocols.
- A URI MUST be invariant with respect to the normal range of transport
stream transformations along the path from provider to user, both in
referencing the time and the location of the resource in that transport
- Given a URI, it MUST be possible for a receiver to actually locate the
resource, or conclude that it is not reachable.
- A URI MUST be meaningful when interpreted, independent of the
transmission context in which the URI is called. Transmission context
refers to a coherent set of content streams as they arrive at the
receiver. An example is a set of TV broadcast services sharing a same
physical connection; another is an Internet connection. In case the
context is the same transmission system as in which the content is
located, the URI MUST be resolvable.
- Where the URI serves as a name identifier (URN), it SHOULD be resolvable
under any of the following network access conditions:
The actual resource's retrieved content data MAY differ in terms of
content encoding, content quality, performance, and edit version.
- TV Broadcast
- In Home/local storage
- Where the URI serves as a name identifier (URN), the scheme MUST support
referencing various instantiations of the same content (encoding,
quality/compression ratio, versions/edits).
- Any actual scheme SHOULD be coordinated with standardisation bodies such
as ATSC, DVB, and DAVIC, and SHOULD be reasonably acceptable to those
- The URI scheme MUST interoperate with the Internet access schemes, such
as to enable seamless transition in referencing resources at TV Broadcast
or Internet sites.
- The host is not necessarily a server identifiable through an IP-address.
For instance, the "host" is a transport stream.
- The resource access and retrieval scheme is not necessarily IP-stack
- The resource's availability implicitly depends on, or at least relates
to, a transmission schedule.
Because TV Broadcast is a resource constrained environment, it is
worthwhile to keep the length of the URI limited. This document does not pose
a requirement on a maximum length of a TV Broadcast URI. It is left to the
particular application domain to specify such limitations.
Key words for use in RFCs to Indicate Requirement Levels,
- RFC 2119, S. Bradner. March 1997.
- [TVWebIG] W3C TVWeb Interest
- Group page of the W3C TV-Web IG. Philipp Hoschka.
TV-Web Mail Archives,
- Threads starting with messages 0040, 0041, and 0046. Oct/Nov 1998.
Uniform Resource Identifiers (URI): Generic Syntax,
- RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter. Aug. 1998.
- RFC 2141, R. Moats. May 1997.
Resolution of Uniform Resource Identifiers using the Domain Name
- RFC 2168, R. Daniel, M. Mealling. June 1997.
Guidelines for new URL Schemes,
- Internet-Draft, L. Masinter, H.T. Alvestrand, D. Zigmond, R. Petke.
- Posting to the TV-Web IG, C. Finseth. December 1998.