previous   next   contents  

20. SMIL 3.0 Tiny Profile

Editors
Xabiel García Pañeda, Universidad de Oviedo
David Melendi Palacio, Universidad de Oviedo
Dick Bulterman, CWI
Eric Hyche, RealNetworks
Pablo Cesar, CWI

Table of contents

20.1 Overview and Summary of Changes for SMIL 3.0

This section is informative.

The SMIL 3.0 Tiny Profile is a new profile introduced in SMIL 3.0. It was not part of the SMIL 2.1.

20.2 Abstract

This section is normative.

The SMIL 3.0 Tiny Profile is the minimum collection of SMIL 3.0 modules that provide support for the SMIL 3.0 language.

This profile is suitable for systems which require very simple SMIL presentations where user interactions and specific content layout are not necessary. This is, for instance, the case of devices with reduced computing capabilities such as MP3/MP4 players, minimum capability mobile phones, car navigation systems, television sets or voice user agents. Also, it is possible to use the profile in the development of server-side playlists. These playlists are used to generate continuous streams from individual video or audio files. The server processes the playlists without any user interaction.

The functionality of the SMIL 3.0 Tiny Profile may be extended by using the SMIL 3.0 Scalability Framework.

20.3 Introduction to the SMIL 3.0 Tiny Profile

This section is informative.

The SMIL 3.0 Tiny Profile is defined as a markup language. The syntax of this language is formally described by a document type definition (DTD), or an XML or RelaxNG Schema which is based on the SMIL modules as defined in "The SMIL 3.0 Modules".

The Tiny Profile design requirements are:

  1. Ensure that the profile is a proper subset of the SMIL 3.0 Language Profile.
  2. Provide a minimum collection of SMIL 3.0 elements.

Examples of use cases for this profile are resource-constrained devices and server-side playlists.

There are many small devices in the market specifically designed to reproduce multimedia contents but without the capabilities of either a computer or even a mobile phone or a PDA. To define simple presentations for these devices there are several formats available such as M3U, PLS or WPL. The SMIL Tiny Profile meets the requirements of these devices as it includes a reduced set of modules of the SMIL language and may be integrated very easily. The simplest devices may be equipped with a SMIL parser to play sequences of files and show metadata, and complex devices equipped with a graphical display may use the profile to play audios, videos, pictures and text.

Server-side playlists allow content servers to generate a live stream combining stored audio, video and live streams in a way specified by a document named playlist. The basic idea behind using SMIL in server-side playlists is to standardize the format of the playlists used by different providers, thus, different servers could share the same playlist, playlists may easily be installed into a new solution or different authoring tools could be used to generate playlists no matter the type of server we are using.

20.4 Normative Definition of the SMIL 3.0 Tiny Profile

This section is normative.

Within this profile specification, the term Tiny Profile will be considered to refer exclusively to the SMIL 3.0 Tiny Profile as defined in this document.

20.4.1 SMIL 3.0 Tiny Profile Conformance

The definition of conformance for a SMIL 3.0 profile is given in the Definitions section of the SMIL 3.0 Scalability Framework. Based on these definitions, the Tiny profile is a Strict Host-Language Conformant SMIL 3.0 Profile.

Within the referenced sections of the Scalability Framework, the following definitions should be used:

  1. The profile identification string for the Tiny profile is: http://www.w3.org/2008/SMIL30/Tiny.
  2. Documents written for the Tiny profile must declare the default SMIL namespace with the xmlns attribute on the smil root element. For SMIL 3.0, this is:
    xmlns="http://www.w3.org/ns/SMIL"
  3. The SMIL 3.0 Tiny profile DOCTYPE is:
    <!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 3.0 Tiny//EN"
    "http://www.w3.org/2008/SMIL30/SMIL30Tiny.dtd">
    If a document contains this declaration, it must be a valid XML document. Note that this implies that extensions to the syntax defined in the DTD (or in the corresponding XML or RelaxNG schemas) are not allowed. If the document is invalid, the user agent should issue an error.
  4. The identification string for the non-normative DTD used for integration of errata is:
    http://www.w3.org/2008/SMIL30/informative-DTD/SMIL30Tiny.dtd
  5. Documents written for the Tiny Profile must declare (explicitly or implicitly via the DTD) the following values for the version and baseProfile attributes:
    version="3.0" baseProfile="Tiny"
    As a consequence of the two requirements above, the effective root element declaration for a Tiny profile document must be:
    <smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Tiny">
         ...
    </smil> 
    The root element may be extended as required with additional atttributes.

This version of SMIL provides a definition of strict host-language conformant SMIL 3.0 documents, which are restricted to tags and attributes from the SMIL 3.0 namespace. The Section "Extending/Restricting a SMIL 3.0 Profile" provides information on using the SMIL 3.0 Tiny profile with other namespaces, for instance, on including new tags within SMIL 3.0 documents.

Language designers and implementors wishing to extend the Tiny profile must consider the implications of the use of namespace extension syntax. Please consult the section on Scalable Profiles for restrictions and recommendations for best practice when extending SMIL.

20.4.2 Conforming SMIL 3.0 Tiny Profile User Agents

The definition of user agent conformance for SMIL 3.0 Tiny profile documents is given in the Conforming SMIL 3.0 User Agents section of the SMIL 3.0 Scalability Framework. Conforming Tiny profile user agents must adhere completely to this section.

20.4.3 The SMIL 3.0 Tiny Profile

The Tiny Profile supports the SMIL 3.0 features for basic multimedia presentations. It uses only modules from the SMIL 3.0 Recommendation. This Tiny profile includes the following SMIL 3.0 modules:

The collection names contained in the following table define the Tiny Profile vocabulary.

SMIL 3.0 Tiny Profile
Collection Name Elements in Collection
Structure smil, head, body
Layout layout
Metainformation meta,
MediaContent animation, audio, img, ref, text, textstream, video
Schedule par, seq

In the following sections, we define the set of elements and attributes used in each of the modules included in the Tiny Profile. The content model for each element is described. The content model of an element is a description of elements which may appear as its direct children. The special content model "EMPTY" means that a given element may not have children.

Collection Name Attributes in Collection
Core alt (CDATA), baseProfile 'Tiny', class (CDATA), label (CDATA), longdesc (CDATA), readIndex '0', title (CDATA), version (3.0) '3.0', xml:base (CDATA) [XMLBase], xml:id (id) (ID)
I18n xml:lang (CDATA)

The xml:id and id attributes are used to assign a unique XML identifier to every element in a SMIL document. These attributes are equivalent and must not both be used on an element. xml:id should be used in preference to id. When the document uses the SMIL 3.0 Tiny Profile DOCTYPE, only xml:id must be used.

The xml:id (id), class and title attributes in the collection Core are defined for all the elements of the Tiny Profile. The id attribute is used in the Tiny Profile to assign a unique XML identifier to every element in a SMIL document.

A conforming Tiny Profile document should not use the SMIL 1.0 attributes that have been depreciated in SMIL 2.0, SMIL 2.1 or SMIL 3.0. Tiny Profile implementations are not required to support these attributes. This would be considered as an unjustified burden for the targeted constraint devices. This applies to the depreciated test attribute of Content Control system-required.

20.4.4 Structure Module

The Structure Module provides a framework for structuring a SMIL document. The Structure Module defines semantics for the smil, head, and body elements. The Tiny Profile includes the Structure functionality of the Structure module and the Identity module.

In the Tiny Profile, the Structure elements may have the following attributes and content model :

Structure Module
Elements Attributes Content model
smil Core, I18n, systemRequired, xmlns (()*, (head, ()*)?, (body, ()*)?)
head Core, I18n ((meta)*, ((), (meta)*)?, ((layout), (meta)*)?)
body Core, I18n, MediaDescriptionAttributes, Timing, fill (auto | default | freeze | hold | remove | transition) 'default' (MediaContent | Schedule | )*

The body element acts as the root element to span the timing tree. The body element has the behavior of a seq element. Timing on the body element is supported. The syncbase of the body element is the application begin time, which is implementation dependent, as is the application end time.

20.4.5 Layout Module

The Layout Module provides a framework for spatial layout of visual components. It defines semantics for the layout element. The Tiny Profile includes the Layout functionality of the StructureLayout module.

In the Tiny Profile, Layout elements may have the following attributes and content model:

Layout Module
Elements Attributes Content model
layout Core, I18n, systemRequired, type 'text/smil-basic-layout' ()*

This profile adds the element to the content model of the head element of the Structure Module.

The content model of layout is empty. Profiles that extend the Tiny Profile may define their own content model of the layout element.

20.4.6 Metainformation Module

The Metainformation Module provides a framework for describing a document, either to inform the human user or to assist in automation. The Metainformation Module defines semantics for the meta and elements. In addition, this module defines semantics for the label attribute. The Tiny Profile includes the Metainformation functionality of the Metainformation module.

In the Tiny Profile, Metainformation elements may have the following attributes and content model:

Metainformation Module
Elements Attributes Content model
meta Core, I18n, content, name, skip-content (false | true) 'true' EMPTY
Core, I18n, skip-content (false | true) 'true' EMPTY

This profile adds the meta element to the content model of the head element of the Structure Module, as well as the element to the content model of the head and body elements of the Structure Module, to the ref, audio, img, video, text, and textstream elements of the BasicMedia module and to the par and seq elements of the BasicTimeContainers module.

The content model of metadata is empty. Profiles that extend the Tiny Profile may define their own content model of the metadata element.

20.4.7 Media Object Modules

The Media Object Modules provide a framework for declaring media. The Media Object Modules define semantics for the ref, audio, img, video, text, and textstream elements. The Tiny Profile includes the Media Object functionality of the BasicMedia and MediaDescription modules.

In the Tiny Profile, media elements may have the following attributes and content model:

Media Object Module
Elements Attributes Content model
ref, animation, audio, img, text, textstream, video Core, I18n, MediaDescriptionAttributes, Timing, endsync 'media', fill (auto | default | freeze | hold | remove | transition) 'default', mediaRepeat (preserve | strip) 'preserve', src, systemRequired, type ()*

The attribute collection MediaDescriptionAttributes is defined as follows:

Collection Name Attributes in Collection
MediaDescriptionAttributes abstract (CDATA), author (CDATA), copyright (CDATA)

This profile adds the ref, audio, img, video, text, and textstream elements to the content model of the par and seq elements of the Timing and Synchronization Modules and to the content model of the body element of the Structure Module.

20.4.8 Timing and Synchronization Modules

The Timing and Synchronization Modules provide a framework for describing timing structure, timing control properties and temporal relationships between elements. The Timing and Synchronization Modules define semantics for par and seq elements. In addition, these modules define semantics for attributes including begin, dur and end. The Tiny Profile includes the Timing and Synchronization functionality of the BasicInlineTiming and BasicTimeContainers modules.

In the Tiny Profile, Timing and Synchronization elements may have the following attributes and content model :

Timing and Synchronization Module
Elements Attributes Content model
par Core, I18n, MediaDescriptionAttributes, Timing, endsync 'last', fill (auto | default | freeze | hold | remove | transition) 'default', systemRequired (MediaContent | Schedule | )*
seq Core, I18n, MediaDescriptionAttributes, Timing, fill (auto | default | freeze | hold | remove | transition) 'default', systemRequired (MediaContent | Schedule | )*

The Attribute collection Timing is defined as follows:

Collection Name Attributes in Collection
Timing begin, dur, end

This profile adds the par and seq elements to the content model of the body element of the Structure Module.

Elements of the Media Object Modules have the attributes describing timing and properties of contents.

20.4.9 Content Control Modules

The Content Control Modules provide a framework for selecting content based on a set of attributes. The Tiny Profile includes the Content Control functionality of the SkipContentControl and RequiredContentControl modules.

In the Tiny Profile no Content Control elements are defined. It only contains the skip-content and systemRequired attributes. While the first may be used to selectively control the evaluation of the element on which the attribute appears, the second provides an extension mechanism for new elements or attributes.

20.5 Use Cases

This section is informative.

20.5.1 Server-side playlists

Server-side playlists allow content servers to generate a live stream from a set of contents. A computing system may retrieve stored audio, video and live streams, and combine them in a way specified by a document named playlist.

Nowadays these systems run as follows:

The basic idea behind using SMIL in server-side playlists is to standardize the playlists used by different providers. Depending on the format of the files to be used, different servers could share the same playlist. So if a new technology is used, the playlists can easily be installed into the new solution. Also, different authoring tools could be used to generate these playlists no matter the type of server we have.

Depending on the future evolution of the currently available implementations of server-side playlists, this functionality may be split to a SMIL Server-Side Playlist Profile. This would allow consideration for new functionality. For instance, we may alternate between live and stored contents in the same playlist, play with the layout to have complex streams (similar to those available in a conventional TV channel), or add complex timing features, etc.

Current playlist support

RealNetworks is one of the companies which implements this type of systems. To generate its live streams, it mainly uses a program called slta. This program uses a plain-text file where the path and names of the files to be used are provided. When the program starts, it opens the playlist file and starts to deliver data packets to the server by putting the files into a sequence. When the program reaches the end of the playlist or a certain length of this playlist, it may stop or it may read it and start again (the slta can loop the list of pre-recorded files either a specified number of times or indefinitely) Also, it is possible to add meta-data. As far as we know, it is impossible to alter the layout of the files. For instance, if we are a content provider working for several broadcasters we need to generate different versions of the same contents even if small variations are needed (like the insertion of a logo image). Also, timing functionality is very limited and only stored content can be used. An example of a slta playlist follows:

llandecubel_cabraliega.rm?title="Cabraliega"&autor="Llan de Cubel"
corquieu_labarquera_tanda.rm?title="Tanda"&author="Corquieu"
tolimorilla_desitiempupoema-a.rm?title="Desi tiempu"&author="Toli Morilla"
losberrones_10anos_ladelatele-a.rm?title="La de la tele"&author="Los Berrones"
jingle_1-a.rm?title="Jingle Asturies.Com"&author="Asturies.Com Canal UN"
elpresi_laxatapinta-a.rm?title="La xata pinta"&author="El Presi"
tolimorilla_natocintura-a.rm?title="Na to cintura"&author="Toli Morilla"

In the example, the playlist uses 7 files in rm format and each of the files has two associated meta-data items: a title and the name of the author. The slta will open these files sequentially or randomly depending on an input parameter.

Other developers are Microsoft (Windows Media Services) and Apple (Darwin/Quicktime Streaming Server). These companies provide what they call Server-Side playlists. They have included a management tool to create and manage these lists of contents. A module in the server uses these playlists and performs actions similar to those exposed in the case of RealNetworks solutions. A reduced set of SMIL 2.0 is available in Microsoft solutions. An example of a Microsoft Server-Side Playlist follows:

<?wsx version="1.0"?>
<smil>
<seq>
<media src="c:\wmpub\wmroot\audio1.wma" clipBegin="2:42" />
<media src="c:\wmpub\wmroot\audio2.wma" clipBegin="0:00" />
<media src="c:\wmpub\wmroot\audio3.wma" clipBegin="2min" />
<media src="c:\wmpub\wmroot\audio4.wma" clipBegin="0h" dur="30" />
</seq>
</smil>

In this example, the playlist uses 4 files in wma format which will be opened sequentially with different starting points according to their internal timeline.

20.5.2 Low-capacity devices

There are many small devices in the market specifically designed to reproduce multimedia contents but without the capabilities of either a computer or even a mobile phone or a PDA. An example is an mp3 player.

An mp3 player is a low-capacity device designed to reproduce audio files encoded in several formats. Usually, these devices are able to reproduce the files they contain sequentially, ordered by file name, or randomly. But in some cases, they are able to process a playlist in which a particular order for the files to be read is specified.

Nowadays there are several playlist formats used for this purpose. Some devices can use the M3U format, others PLS or WPL, etc. An example of an M3U playlist follows:

#EXTM3U

#EXTINF:167,Jorge Tuya - Puente de Ribadesella
tonada\puenteRibadesella.mp3
#EXTINF:193,Anabel Santiago - Coyi dun artu una flor
tonada\coyiArtuFlor.mp3
#EXTINF:207,Jesus Garcia - Tengo de subir al puertu
tonada\subirPuertu.mp3

In the example, three mp3 files stored in the tonada directory are played in sequence. Each #EXTINF: entry provides the length of the following file and the title which should be shown in the display of the player/device.

In conclusion, the SMIL Tiny Profile meets the requirements of the described devices. It includes a reduced set of modules of the SMIL language and can be integrated very easily. The simplest devices, designed to reproduce only audio, can be equipped with a SMIL parser to play sequences of files and show their associated metadata. Moreover, complex devices equipped with a graphical display, and video and image renderers, can use the profile to play sequences of audios and videos, or even a picture of the artist, or the title of the song being played is shown on the display.

Standardizing the format used in these devices allows users not only to reuse their multimedia files but also their playlists, once a new device has been bought.

20.6 Expanding the SMIL 3.0 Tiny Profile

This section is informative.

The SMIL 3.0 Tiny Profile is the minimum collection of SMIL 3.0 modules that provides support for the SMIL 3.0 language. Nevertheless, the SMIL Language includes powerful functionality for various/differing complexities, ranging from desktops to ubiquitous information appliances such as minimal capability mobile phones, car navigation systems, television sets, and voice user agents. Each of these platforms has its own specific capabilities and requirements. It is clear that not all SMIL 3.0 elements and attributes will be required on all platforms. SMIL 3.0 modularization groups semantically related SMIL elements, attributes, and attribute values into a disjoint set of SMIL modules. These modules may then be recombined to produce a SMIL profile that meets the needs of different communities. For example, a hand held device, digital talking book player, or a mobile phone may only support a small subset of SMIL 3.0 modules in its own profile.

For this purpose, the W3C SYMM working group has defined a scalability architecture in the SMIL 3.0 Scalability Framework. A scalable profile enables user agents to support incremental extra collections of modules containing the baseline functionality needed for an implementation environment, thus, a family of scalable SMIL profiles may be built using the SMIL 3.0 Tiny Profile plus additional sets of modules geared to the particular needs each profile addresses.

Example

The following example shows how a television channel may build a server-side playlist, based on the following broadcast table:

TV Channel Time Table
Begin End Program Provider Type
20:00 21:00 News Own Live
21:00 22:00 Coronation Avenue Equirrel Productions Stored
22:00 00:00 Football: Sporting de Gijón vs Real Oviedo AudioVisual Sport Live
00:00 01:00 News Own Live
01:00 02:15 International Cinema: Xicu'l Toperu Producciones Esbardu Stored

The resulting document is the SMIL presentation following the Tiny profile:

01 <?xml version="1.0" encoding="iso-8859-1" ?>
02
03 <smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Tiny"
04        xmlns:Wallclock="http://www.w3.org/2008/SMIL30/WallclockTiming"
05        xmlns:MediaClipping="http://www.w3.org/2008/SMIL30/MediaClipping"
06        systemRequired="Wallclock+MediaClipping" >
07  <head>
08     <layout></layout>
09     <meta name="Broadcaster" content="TV Channel" />
10     <meta name="Rights" content="Copyright 2007 TV Channel" />
11   </head>
12   <body>
13     <seq>
14       <video src="rtsp://videoserver.tvchannel.com/livenews.rm" begin="wallclock(20:00:00)" dur="60:00" title="News">
15         <!-- Metadata of the news -->
16         <metadata ...>
17         ... 
18         </metadata>
19       </video>
20       <video src="./series/coronationAv/chapter20.rm" clipBegin="5:00" clipEnd="65:00" title="Coronation Avenue" >
21         <!-- Metadata of Coronation Avenue -->
22         <metadata ...>
23         ... 
24         </metadata>
25       </video>
26       <video src="rtsp://videoserver.audiovisualsport.com/xixonUvieu.rm" dur="120:00" title="Sporting de Gijón vs. Real Oviedo" />
27       <video src="rtsp://videoserver.tvchannel.com/livenews.rm" dur="60:00" title="News" />
28       <video src="./movies/xicuToperu.rm" end="wallclock(02:15:00)" title="Xicu'l Toperu" />
29     </seq>
30   </body>
31 </smil>

The previous example uses the functionality defined by the SMIL 3.0 Tiny Profile. For example, lines 15-18 exemplifies how the metadata information can be included in the body section of the document, thus annotating specific programs. In addition, the example uses the clipBegin and clipEnd attributes from the MediaClipping module and the wallclock from the WallclockTiming module. These two required modules are declared in the smil element as defined in the SMIL 3.0 Scalability Framework.

IPTV and Interactive Television

As shown in the previous example, the SMIL 3.0 Tiny profile can be used for transmission of digital television channels. Nevertheless, IPTV and Interactive Television content will require a number of extra modules than those included in the SMIL 3.0 Tiny profile, such as linking, state, and layout functionality.

20.7 Appendix A: SMIL 3.0 Document Type Definition

This section is normative.

The Tiny Profile Document Type Definition is defined as a set of SMIL 3.0 modules. All SMIL 3.0 modules are integrated according to the guidelines in the W3C Note "Synchronized Multimedia Modules based upon SMIL 1.0" [SMIL-MOD], and defined within their respective module sections.


previous   next   contents