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.
This section is informative.
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.
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".
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.
The Tiny Profile design requirements are:
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, PLP, 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 can be integrated very easily. The simplest devices can be equipped with a SMIL parser to play sequences of files and show metadata, and complex devices equipped with a graphical display can 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 can 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.
This section is normative.
This version of SMIL provides a definition of strictly conforming Tiny Profile documents, which are restricted to tags and attributes from the SMIL 3.0 namespace. In the future, the language described in this profile may be extended by other W3C Recommendations, or by private extensions. For these extensions, the following rules must be obeyed:
Conformant Tiny Profile user agents are expected to handle documents containing extensions that obey these two rules.
The Tiny Profile is a conformant SMIL 3.0 specification. The rules for defining conformant documents are provided in SMIL 3.0 Language Conformance in the SMIL 3.0 Language Profile document. Note that while the section is written for the SMIL 3.0 Language profile, all of the rules apply to the Tiny Profile as well, with the exception that the Tiny Profile's namespace should be used instead of the SMIL 3.0 Language Profile's namespace and the Tiny Profile's DOCTYPE declaration should be used instead of the SMIL 3.0 Language Profile DOCTYPE declaration.
Documents written for the Tiny Profile must declare a default namespace for its elements with an xmlns attribute on the smil root element with its identifier URI:
<smil xmlns="http://www.w3.org/2007/07/SMIL30/Tiny"> ... </smil>
The default namespace declaration must be
xmlns="http://www.w3.org/2007/07/SMIL30/Tiny"
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.
The SMIL 3.0 Tiny Profile DOCTYPE is:
<!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 3.0 Tiny//EN" "http://www.w3.org/2007/07/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.
Since the Tiny Profile defines a conformant SMIL document, the rules for defining conformant user agents are the same as provided in the Conforming SMIL 3.0 Language User Agents in the SMIL 3.0 Language Profile document, with the exception that the conforming user agent must support the Tiny Profile's namespace instead of the SMIL 3.0 Language Profile's namespace.
The Tiny Profile supports the SMIL 3.0 features for basic multimedia presentations. It uses only modules from the SMIL 3.0 Recommendation. As the language profile includes the mandatory modules, it is a SMIL Host Language conforming language profile. This language 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 | , |
| MediaContent | text, img, audio, video, ref, textstream |
| 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 can 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 | id (ID), class (NMTOKEN), title (CDATA), alt (CDATA), longdesc (CDATA), label (CDATA), xml:base (CDATA) |
| I18n | xml:lang (NMTOKEN) |
The 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. The unsupported depreciated SMIL 1.0 attributes are the following: anchor, background-color, clip-begin, clip-end, repeat; and the additional depreciated test attributes of Content Control: system-bitrate, system-captions, system-language, system-required, system-screen-size, and, system-screen-depth.
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.
In the Tiny Profile, the Structure elements can have the following attributes and content model :
| Structure Module | ||
|---|---|---|
| Elements | Attributes | Content model |
| smil | Core, I18n, systemRequired, xmlns | (head?,body?) |
| head | Core, I18n | (*,(,*)?,(layout,*)?) |
| body | Core, I18n, Timing, abstract, , copyright | (Schedule | MediaContent | )* |
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.
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 can have the following attributes and
content model:
| Layout Module | ||
|---|---|---|
| Elements | Attributes | Content model |
| layout | Core, I18n, type, systemRequired | EMPTY |
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.
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 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 can have the following attributes and content model:
| Metainformation Module | ||
|---|---|---|
| Elements | Attributes | Content model |
| Core, I18n, content (CDATA), name (CDATA) | EMPTY | |
| Core, I18n, skip-content | EMPTY | |
This profile adds the 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.
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 can have the following attributes and content model:
| Media Object Module | ||
|---|---|---|
| Elements | Attributes | Content model |
| text, img, audio, video, ref, textstream | Core, I18n, Timing, , copyright, abstract, title, src, type, systemRequired. | ()* |
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.
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 can have the following attributes and content model :
| Timing and Synchronization Module | ||
|---|---|---|
| Elements | Attributes | Content model |
| par | Core, I18n, Timing, systemRequired | (Schedule | MediaContent | )* |
| seq | Core, I18n, Timing, systemRequired | (Schedule | MediaContent | ) * |
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.
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 can 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.
This section is informative.
Server-side playlists allow content servers to generate a live stream from a set of contents. A computing system can 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.
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.
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 with PLP, 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.
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 can 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 can be built using the SMIL 3.0 Tiny Profile plus additional sets of modules geared to the particular needs each profile addresses.
For example, a TV Channel needs to build a server-side playlist where the contents shown in the following table would like to be broadcast:
| 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 |
Apart from the functionality defined in the SMIL 3.0 Tiny Profile, the TV Channel would like to use the clipBegin and clipEnd attributes, as well as wallclock values. Thus, the MediaClipping and WallclockTiming modules are required and declared in the smil element as defined in the SMIL 3.0 Scalability Framework.
The resulting document follows:
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 3.0 Tiny//EN"
"http://www.w3.org/2007/07/SMIL30/SMIL30Tiny.dtd" >
<smil xmlns="http://www.w3.org/2007/07/SMIL30/Tiny"
xmlns:Wallclock="http://www.w3.org/2007/07/SMIL30/WallclockTiming"
xmlns:MediaClipping="http://www.w3.org/2007/07/SMIL30/MediaClipping"
systemRequired="Wallclock+MediaClipping" >
<head>
<layout></layout>
<meta name="Broadcaster" content="TV Channel" />
<meta name="Rights" content="Copyright 2007 TV Channel" />
</head>
<body>
<seq>
<video src="rtsp://videoserver.tvchannel.com/livenews.rm" begin="wallclock(20:00:00)" dur="60:00" title="News" />
<video src="./series/coronationAv/chapter20.rm" clipBegin="5:00" clipEnd="65:00" title="Coronation Avenue" />
<video src="rtsp://videoserver.audiovisualsport.com/xixonUvieu.rm" dur="120:00" title="Sporting de Gijón vs. Real Oviedo" />
<video src="rtsp://videoserver.tvchannel.com/livenews.rm" dur="60:00" title="News" />
<video src="./movies/xicuToperu.rm" end="wallclock(02:15:00)" title="Xicu'l Toperu" />
</seq>
</body>
</smil>
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.