Table of contents

• 20.1 Overview and Summary of Changes for SMIL 3.0
• 20.2 Abstract
• 20.3 Introduction to the SMIL 3.0 Tiny Profile
• 20.4 Normative Definition of the SMIL 3.0 Tiny Profile
  • 20.4.1 SMIL 3.0 Tiny Profile Conformance
  • 20.4.2 Conforming SMIL 3.0 Tiny Profile User Agents
  • 20.4.3 The SMIL 3.0 Tiny Profile
  • 20.4.4 Structure Module
  • 20.4.5 Layout Module
  • 20.4.6 Metainformation Module
  • 20.4.7 Media Object Modules
  • 20.4.8 Timing and Synchronization Modules
  • 20.4.9 Content Control Modules
• 20.5 Use Cases
  • 20.5.1 Server-side playlists
    • Current playlist support
  • 20.5.2 Low-capacity devices
• 20.6 Expanding the SMIL 3.0 Tiny Profile
  • • Example
    • IPTV and Interactive Television
• 20.7 Appendix A: SMIL 3.0 Document Type Definition

This section is informative.

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

This section is normative.

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

This profile is suitable for systems which require very simple SMILpresentations where user interactions and specific content layout are notnecessary. This is, for instance, the case of devices with reduced computingcapabilities such as MP3/MP4 players, minimum capability mobile phones, carnavigation systems, television sets or voice user agents. Also, it ispossible to use the profile in the development of server-side playlists.These playlists are used to generate continuous streams from individual videoor audio files. The server processes the playlists without any userinteraction.

The functionality of the SMIL 3.0 Tiny Profile may be extended by usingtheSMIL 3.0 ScalabilityFramework.

This section is informative.

The SMIL 3.0 Tiny Profile is defined as a markup language. The syntax ofthis language is formally described by a document type definition (DTD), oran 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 theSMIL 3.0 Language Profile.
2. Provide a minimum collection of SMIL 3.0 elements.

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

There are many small devices in the market specifically designed toreproduce multimedia contents but without the capabilities of either acomputer or even a mobile phone or a PDA. To define simple presentations forthese devices there are several formats available such asM3U,PLS orWPL. The SMIL Tiny Profilemeets the requirements of these devices as it includes a reduced set ofmodules of the SMIL language and may be integrated very easily. The simplestdevices may be equipped with a SMIL parser to play sequences of files andshow metadata, and complex devices equipped with a graphical display may usethe profile to play audios, videos, pictures and text.

Server-side playlists allow content servers to generate a live streamcombining stored audio, video and live streams in a way specified by adocument namedplaylist. The basic idea behind using SMIL inserver-side playlists is to standardize the format of the playlists used bydifferent providers, thus, different servers could share the same playlist,playlists may easily be installed into a new solution or different authoringtools could be used to generate playlists no matter the type of server we areusing.

This section is normative.

Within this profile specification, the termTiny Profile will beconsidered to refer exclusively to the SMIL 3.0 Tiny Profile as defined inthis document.

20.4.1 SMIL 3.0 Tiny ProfileConformance

The definition of conformance for a SMIL 3.0 profile is given in theDefinitions section of theSMIL 3.0 Scalability Framework. Based on these definitions, the Tiny profile isaStrict 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 defaultSMIL namespace with thexmlnsattribute on thesmil 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 XMLdocument. Note that this implies that extensions to the syntax defined in the DTD (orin the corresponding XML or RelaxNG schemas) are not allowed. If the documentis 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) thefollowing valuesfor theversion andbaseProfile attributes:

   version="3.0" baseProfile="Tiny"

   As a consequence of the two requirements above, the effective root element declaration fora 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.0documents, which are restricted to tags and attributes from the SMIL 3.0namespace. The Section "Extending/Restricting a SMIL3.0 Profile" provides information on using the SMIL 3.0 Tinyprofile with other namespaces, for instance, on including new tags withinSMIL 3.0 documents.

Language designers and implementors wishing to extend the Tinyprofile must consider the implications of the use of namespace extensionsyntax. Please consult the section onScalable Profiles for restrictionsand recommendations for best practice when extending SMIL.

20.4.2 Conforming SMIL 3.0 Tiny Profile UserAgents

The definition of user agent conformance for SMIL 3.0 Tinyprofile documents is given in theConforming SMIL 3.0 UserAgents section of theSMIL 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 multimediapresentations. It uses only modules from the SMIL 3.0 Recommendation. This Tiny profile includes thefollowing SMIL 3.0 modules:

• Structure functionality
  • Structure Module
  • Identity Module
• Layout functionality
  • StructureLayout Module
• Metainformation functionality
  • Metainformation Module
• Media functionality
  • BasicMedia Module
  • MediaAccessibility Module
  • MediaDescription Module
• Timing functionality
  • BasicInlineTiming Module
  • BasicTimeContainers Module
• Content Control functionality
  • SkipContentControl Module
  • RequiredContentControl Module

The collection names contained in the following table define the TinyProfile vocabulary.

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

Thexml:id andid attributes are used to assign a unique XMLidentifier to every element in a SMIL document. These attributes areequivalent and must not both be used on an element.xml:id should be used in preference toid. When the document uses the SMIL 3.0Tiny Profile DOCTYPE, onlyxml:idmust be used.

Thexml:id (id),classandtitleattributes in thecollection Core are defined for all the elements of the Tiny Profile. Theidattribute is used in the Tiny Profileto assign a unique XML identifier to every element in a SMIL document.

A conforming Tiny Profile document should not use the SMIL 1.0 attributesthat have been depreciated in SMIL 2.0, SMIL 2.1 or SMIL 3.0. Tiny Profileimplementations are not required to support these attributes. This would beconsidered as an unjustified burden for the targeted constraint devices. Thisapplies to the depreciated test attribute of Content Controlsystem-required.

20.4.4 Structure Module

The Structure Module provides a framework for structuring a SMIL document.The Structure Module defines semantics for thesmil,head, andbody elements. The Tiny Profile includes theStructure functionality of theStructuremodule and theIdentitymodule.

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

Thebody element acts as the rootelement to span the timing tree. The body element has the behavior of aseq element. Timing on thebody element is supported. The syncbase ofthebody element is the applicationbegin time, which is implementation dependent, as is the application endtime.

20.4.5 Layout Module

TheLayout Module provides a frameworkfor spatial layout of visual components. It defines semantics for the layoutelement. The Tiny Profile includes the Layout functionality of theStructureLayoutmodule.

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

This profile adds the element tothe content model of thehead elementof theStructure Module.

The content model oflayout isempty. Profiles that extend the Tiny Profile may define their own contentmodel of thelayout element.

20.4.6 Metainformation Module

TheMetainformation Module provides aframework for describing a document, either to inform the human user or toassist in automation. TheMetainformationModule defines semantics for themeta andmetadata elements. In addition, thismodule defines semantics for thelabelattribute. The Tiny Profile includes the Metainformation functionality of theMetainformation module.

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

This profile adds themeta elementto the content model of theheadelement of theStructure Module, as wellas themetadata element to thecontent model of thehead andbody elements of theStructure Module, to theref,audio,img,video,text, andtextstream elements of theBasicMediamodule and to thepar andseq elements of theBasicTimeContainersmodule.

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

20.4.7 Media Object Modules

TheMedia Object Modulesprovide a framework for declaring media. TheMedia Object Modules define semanticsfor theref,audio,img,video,text, andtextstream elements. The Tiny Profileincludes the Media Object functionality of theBasicMediaandMediaDescriptionmodules.

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

The attribute collection MediaDescriptionAttributes is defined asfollows:

This profile adds theref,audio,img,video,text, andtextstream elements to the contentmodel of thepar andseq elements of theTiming and Synchronization Modules and to thecontent model of thebody element oftheStructure Module.

20.4.8 Timing and Synchronization Modules

TheTiming and Synchronization Modulesprovide a framework for describing timing structure, timing controlproperties and temporal relationships between elements. TheTiming and Synchronization Modules definesemantics forpar andseq elements. In addition, these modulesdefine semantics for attributes includingbegin,dur andend. The Tiny Profile includes the Timing andSynchronization functionality of theBasicInlineTiming andBasicTimeContainersmodules.

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

The Attribute collection Timing is defined as follows:

This profile adds thepar andseq elements to the content model of thebody element of theStructure Module.

Elements of theMedia ObjectModules have the attributes describing timing and properties ofcontents.

20.4.9 Content Control Modules

TheContent Control Modules provide aframework for selecting content based on a set of attributes. The TinyProfile includes the Content Control functionality of theSkipContentControlandRequiredContentControlmodules.

In the Tiny Profile no Content Control elements are defined. It onlycontains theskip-content andsystemRequired attributes.While the first may be used to selectively control the evaluation of theelement on which the attribute appears, the second provides an extensionmechanism for new elements or attributes.

This section is informative.

20.5.1 Server-side playlists

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

Nowadays these systems run as follows:

• There is a set of pre-encoded files stored on the server and/or live streams ready to be used.
• A document specifying the order of these files/streams is built (playlist).
• This document is then opened by the system to build a continuous stream of data by putting the files into a sequence.
• Metadata may be added to the playlist.

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

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

Current playlist support

RealNetworks is one of the companies which implements this type ofsystems. 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 tobe used are provided. When the program starts, it opens the playlist file andstarts to deliver data packets to the server by putting the files into asequence. When the program reaches the end of the playlist or a certainlength of this playlist, it may stop or it may read it and start again (theslta can loop the list of pre-recorded files either a specified number oftimes or indefinitely) Also, it is possible to add meta-data. As far as weknow, it is impossible to alter the layout of the files. For instance, if weare a content provider working for several broadcasters we need to generatedifferent versions of the same contents even if small variations are needed(like the insertion of a logo image). Also, timing functionality is verylimited and only stored content can be used. An example of a slta playlistfollows:

llandecubel_cabraliega.rm?title="Cabraliega"&autor="Llan deCubel"
corquieu_labarquera_tanda.rm?title="Tanda"&author="Corquieu"
tolimorilla_desitiempupoema-a.rm?title="Desitiempu"&author="Toli Morilla"
losberrones_10anos_ladelatele-a.rm?title="La de latele"&author="Los Berrones"
jingle_1-a.rm?title="JingleAsturies.Com"&author="Asturies.Com Canal UN"
elpresi_laxatapinta-a.rm?title="La xata pinta"&author="ElPresi"
tolimorilla_natocintura-a.rm?title="Na tocintura"&author="Toli Morilla"

In the example, the playlist uses 7 files in rm format and each of thefiles 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 inputparameter.

Other developers are Microsoft (Windows Media Services) and Apple(Darwin/Quicktime Streaming Server). These companies provide what they callServer-Side playlists. They have included a management tool to create andmanage these lists of contents. A module in the server uses these playlistsand performs actions similar to those exposed in the case of RealNetworkssolutions. A reduced set of SMIL 2.0 is available in Microsoft solutions. Anexample 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 beopened sequentially with different starting points according to theirinternal timeline.

20.5.2 Low-capacity devices

There are many small devices in the market specifically designed toreproduce multimedia contents but without the capabilities of either acomputer 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 filesencoded in several formats. Usually, these devices are able to reproduce thefiles they contain sequentially, ordered by file name, or randomly. But insome cases, they are able to process a playlist in which a particular orderfor the files to be read is specified.

Nowadays there are several playlist formats used for this purpose. Somedevices can use theM3Uformat, othersPLS orWPL, etc. An example of anM3U 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 thetonadadirectory are played in sequence. Each#EXTINF: entry providesthe length of the following file and the title which should be shown in thedisplay of the player/device.

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

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

This section is informative.

The SMIL 3.0 Tiny Profile is the minimum collection of SMIL 3.0 modulesthat provides support for the SMIL 3.0 language. Nevertheless, the SMILLanguage includes powerful functionality for various/differing complexities,ranging from desktops to ubiquitous information appliances such as minimalcapability mobile phones, car navigation systems, television sets, and voiceuser agents. Each of these platforms has its own specific capabilities andrequirements. It is clear that not all SMIL 3.0 elements and attributes willbe required on all platforms. SMIL 3.0 modularization groups semanticallyrelated SMIL elements, attributes, and attribute values into a disjoint setof SMIL modules. These modules may then be recombined to produce a SMILprofile that meets the needs of different communities. For example, a handheld device, digital talking book player, or a mobile phone may only supporta small subset of SMIL 3.0 modules in its own profile.

For this purpose, the W3C SYMM working group has defined a scalabilityarchitecture in the SMIL 3.0 Scalability Framework. A scalable profileenables user agents to support incremental extra collections of modulescontaining the baseline functionality needed for an implementationenvironment, thus, a family of scalable SMIL profiles may be built using theSMIL 3.0 Tiny Profile plus additional sets of modules geared to theparticular needs each profile addresses.

Example

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

The resulting document is the SMIL presentation following the Tinyprofile:

01 <?xml version="1.0" encoding="iso-8859-1" ?>0203 <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 TinyProfile. For example, lines 15-18 exemplifies how the metadata informationcan be included in the body section of the document, thus annotating specificprograms. In addition, the example uses theclipBegin andclipEnd attributes from theMediaClippingmodule and thewallclock from theWallclockTiming module.These two required modules are declared in the smil element as defined in theSMIL 3.0 Scalability Framework.

IPTV and Interactive Television

As shown in the previous example, the SMIL 3.0 Tiny profile can be usedfor transmission of digital television channels. Nevertheless, IPTV andInteractive Television content will require a number of extra modules thanthose included in the SMIL 3.0 Tiny profile, such as linking, state, andlayout functionality.

This section is normative.

TheTiny Profile Document TypeDefinition is defined as a set of SMIL 3.0 modules. All SMIL 3.0 modulesare integrated according to the guidelines in the W3C Note "SynchronizedMultimedia Modules based upon SMIL 1.0"[SMIL-MOD], and defined withintheir respective module sections.