4. The SMIL 2.1 Content Control Modules

Editor for SMIL 2.1

Thierry Michel, W3C.

Editors for SMIL 2.0

Dick Bulterman, Oratrix

Jeffrey Ayars, RealNetworks.

4.1 Summary of Changes for SMIL 2.1

This section is informative.

The SMIL 2.1 specification leaves the SMIL 2.0 Content Control Modules [SMIL20-content-control] unchanged.

4.2 Introduction

This section is informative.

This section defines the SMIL 2.1 content control modules. These modules contain elements and attributes which provide for runtime content choices and optimized content delivery. SMIL content control functionality is partitioned across four modules:

• BasicContentControl, containing content selection elements and predefined system test attributes;
• CustomTestAttributes, containing author-defined custom test elements and attributes;
• PrefetchControl, containing presentation optimization elements and attributes; and
• SkipContentControl, containing attributes that support selective attribute evaluation.

Since all of the content control elements and attributes are defined in modules, designers of other markup languages can reuse this functionality on a module by module basis when they need to include media content control in their language.

The functionality in the CustomTestAttributes module builds on the functionality of the BasicContentControl module; profiles implementing the CustomTestAttributes module must also implement the BasicContentControl module. The PrefetchControl and SkipContentControl modules have no prerequisites.

In some of the module descriptions for content control, the concept of "user preference" may be present. User preferences are usually set by the playback engine using a preferences dialog box, but this specification does not place any restrictions on how such preferences are communicated from the user to the SMIL player.

It is implementation dependent when content control attributes are evaluated. Attributes may be evaluated multiple times. Dynamic reevaluation is allowed but not required.

4.3 The SMIL 2.1 BasicContentControl Module

4.3.1 SMIL 2.1 BasicContentControl Module Overview

SMIL 1.0 provides a "test-attribute" mechanism to process an element only when certain conditions are true, for example when the language preference specified by the user matches that of a media object. One or more test attributes may appear on media object references or timing structure elements; if the attribute evaluates to true, the containing element is played, and if the attribute evaluates to false the containing element is ignored. SMIL 1.0 also provides the switch element for expressing that a set of document parts are alternatives, and that the first one fulfilling certain conditions should be chosen. This is useful to express that different language versions of an audio file are available, and that the client may select one of them.

The SMIL 2.1 BasicContent module includes the test attribute functionality from SMIL 1.0 and extends it by supporting new system test attributes. This section will describe the use of the predefined system test attributes, the switch element and test attribute in-line placement. A mechanism for extending test attributes is presented in the CustomTestAttributes module.

Predefined System Test Attributes

This specification defines a list of test attributes that can be added to language elements, as allowed by the language designer. In SMIL 1.0, these elements are synchronization and media elements. Conceptually, these attributes represent Boolean tests. When any of the test attributes specified for an element evaluates to false, the element carrying this attribute is ignored.

SMIL 2.1 supports the full set of SMIL 1.0 system attributes. The SMIL 1.0 compatible system test attributes are:

• systemBitrate
• systemCaptions
• systemLanguage
• system-overdub-or-caption (note: this attribute has been deprecated in favor of systemCaptions or systemOverdubOrSubtitle)
• systemRequired
• systemScreenDepth
• systemScreenSize

Note that, with the exception of system-overdub-or-caption, the names of these attributes have been changed to reflect SMIL 2.1's camelCase conventions. The SMIL 1.0 hyphenated names are deprecated in this release.

New to SMIL 2.1 are system test attributes that define additional characteristics of the system environment. These are:

• systemAudioDesc
• systemCPU
• systemComponent
• systemOperatingSystem
• systemOverdubOrSubtitle

The complete definition of each attribute is given in the attributes definition section.

The switch element

The switch element allows an author to specify a set of alternative elements from which only the first acceptable element is chosen.

An example of the use of the switch is:

  ...
  <par>
    <video src="anchor.mpg" ... />
    <switch>
      <audio src="dutchHQ.aiff" systemBitrate="56000" ... />
      <audio src="dutchMQ.aiff" systemBitrate="28800" ... />
      <audio src="dutchLQ.aiff" ... />
    </switch>
  </par> 
  ...

In this example, one audio object is selected to accompany the video object. If the system bitrate is 56000 or higher, the object dutchHQ.aiff is selected. If the system bitrate is at least 28800 but less than 56000, the object dutchMQ.aiff is selected. If no other objects are selected, the alternative dutchLQ.aiff is selected, since it has no test attribute (thus is always acceptable) and no other test attributes evaluated to true.

Authors should order the alternatives from the most desirable to the least desirable. Furthermore, authors may wish to place a relatively fail-safe alternative as the last item in the switch so that at least one item within the switch is chosen (unless this is explicitly not desired).

Note that some network protocols, e.g. HTTP and RTSP, support content-negotiation, which may be an alternative to using the switch element in some cases.

It is the responsibility of the SMIL 2.1 player to determine the setting for system test attribute values. Such settings may be determined statically based on configuration settings, or they may be determined (and re-evaluated) dynamically, depending on the player implementation. Players may not select members of a switch at random.

System Test Attribute In-Line Use

To allow more flexibility in element selection, test attributes may also be used outside of the switch element.

In the following example of in-line test attribute use, captions are shown only if the user wants captions on.

 ...
 <par>
    <audio src="audio.rm"/>
    <video src="video.rm"/>
    <textstream src="stockticker.rt"/>
    <textstream src="closed-caps.rt" systemCaptions="on"/>
 </par>
 ...
 

The alternatives indicated by the in-line construct could be represented as a set of switch statements, although the resulting switch could become explosive in size. Use of an in-line test mechanism significantly simplifies the specification of adaptive content, especially in those cases where many independent alternatives exist. Note, however, that there is no fail-safe alternative mechanism (such as defining an element without a test attribute inside of a switch) when using test attributes in-line.

Examples of Switch and Test Attribute Use

1. Choosing between content with different total bitrates

   In a common scenario, implementations may wish to allow for selection via a systemBitrate attribute on elements. The SMIL 2.1 player evaluates each of the elements within the switch one at a time, looking for an acceptable bitrate value.

    ...
    <par>
       <text .../>
       <switch>
          <par systemBitrate="40000">
          ...
          </par>
          <par systemBitrate="24000">
          ...
          </par> 
          <par systemBitrate="10000">
          ... 
          </par> 
       </switch> 
    </par> 
    ...

   In this example, if the system bitrate has been determined to be less than 10000 (in mobile telephone cases, for example), then none of the par constructs would be included.

2. Choosing between audio resources with different bitrates

   The elements within the switch may be any combination of elements. For instance, one could specify an alternate audio track:

    ...
    <switch>
       <audio src="joe-audio-better-quality" systemBitrate="16000" /> 
       <audio src="joe-audio" />
    </switch>
    ... 

   If the system bitrate was less than 16000, the standard-quality audio would be presented by default.

3. Choosing between audio resources in different languages

   In the following example, an audio resource is available both in Dutch and in English. Based on the user's preferred language, the player can choose one of these audio resources.

    ...
    <switch>
       <audio src="joe-audio-nederlands" systemLanguage="nl"/>
       <audio src="joe-audio-english" systemLanguage="en"/>
    </switch>
    ... 

   In this example, if the system language setting was anything other than Dutch or English, no audio would be presented. To make a choice the default, it should appear as the last item in the list and not contain a test attribute. In the following fragment, English is used as the default:

    ...
    <switch>
       <audio src="joe-audio-nederlands" systemLanguage="nl"/>
       <audio src="joe-audio-english" />
    </switch>
    ... 

4. Choosing between content written for different screens

   In the following example, the presentation contains alternative parts designed for screens with different resolutions and bit-depths. Depending on the particular characteristics of the screen, the player must use the first alternative in which all of the test attributes evaluate to true.

    ...
    <par>
       <text .../>
       <switch>
          <par systemScreenSize="1024X1280" systemScreenDepth="16">
          ...
          </par>
          <par systemScreenSize="480X640" systemScreenDepth="32">
          ...
          </par> 
          <par systemScreenSize="480X640" systemScreenDepth="16"> 
          ... 
          </par> 
       </switch> 
    </par> 
    ...

5. Supporting multiple options via in-line use

   This example shows a video that is accompanied by zero or more media objects. If the system language has been set to either Dutch or English, then the appropriate audio object will play. In addition, if the system language has been set to either Dutch or English and systemCaptions has also been set to on, the appropriate text files will also be displayed.

     ...
     <par>
       <video src="anchor.mpg" ... />
       <audio src="dutch.aiff"   systemLanguage="nl"  ... />
       <audio src="english.aiff" systemLanguage="en" ... />
       <text  src="dutch.html"   systemLanguage="nl" systemCaption="on"... />
       <text  src="english.html" systemLanguage="en" systemCaption="on"... />
     </par> 
     ...

   If system language is set to something other than Dutch or English, no objects will be rendered (except the video). Note that there is no catch-all default mechanism when using test attributes for in-line evaluation.

6. Choosing the language of overdub and subtitle tracks

   In the following example, a French-language movie is available with English, German, and Dutch overdub and subtitle tracks. The following SMIL segment expresses this, and switches on the alternatives that the user prefers.

    ...
    <par>
       <switch>
          <audio src="movie-aud-en.rm" systemLanguage="en"
                systemOverdubOrSubtitle="overdub"/>
          <audio src="movie-aud-de.rm" systemLanguage="de"
                systemOverdubOrSubtitle="overdub"/>
          <audio src="movie-aud-nl.rm" systemLanguage="nl"
                systemOverdubOrSubtitle="overdub"/>
          <!-- French for everyone else --> 
          <audio src="movie-aud-fr.rm"/>
       </switch> 
       <video src="movie-vid.rm"/>
       <switch> 
          <textstream src="movie-sub-en.rt" systemLanguage="en" 
                systemOverdubOrSubtitle="subtitle"/>
          <textstream src="movie-sub-de.rt" systemLanguage="de"
                systemOverdubOrSubtitle="subtitle"/> 
          <textstream src="movie-sub-nl.rt" systemLanguage="nl"
                systemOverdubOrSubtitle="subtitle"/> 
          <!-- French captions for those that really want them --> 
          <textstream src="movie-caps-fr.rt" systemCaptions="on"/>
       </switch> 
    </par> 
    ...

4.3.2 Elements and Attributes

SMIL 2.1 BasicContentControl defines the switch element and a set of predefined system test attributes.

The switch element

The switch element allows an author to specify a set of alternative elements. An element is selected as follows: the player evaluates the elements in the order in which they occur in the switch element. The first acceptable element is selected at the exclusion of all other elements within the switch. Implementations must NOT arbitrarily pick an object within a switch when test attributes for all child elements fail.

Predefined Test Attributes

SMIL 2.1 defines the following system test attributes. When any of the test attributes specified for an element evaluates to false, the element carrying this attribute is ignored. Note that most hyphenated test attribute names from SMIL 1.0 have been deprecated in favor of names using the current SMIL camelCase convention. For these, the deprecated SMIL 1.0 name is shown in parentheses after the preferred name.

It is the responsibility of the SMIL 2.1 Player to determine the settings for each predefined test variable. These values may be determined by static configuration settings, or they may be evaluated dynamically during runtime. Such setting and (re)evaluation behavior is implementation dependent.

For this version of SMIL elements with specified test attributes that evaluate to false, or elements within a switch that are not selected, are considered to be ignored and will behave as though they were not specified in the document. Any references to these elements will be as if the elements were not in the document. In particular, any ID references to the element will act as if there was no element with that ID. Languages that integrate this module must specify any additional behavior related to these ignored elements. In the SMIL 2.1 Language profile, timing attributes that reference invalid IDs are treated as being indefinite.

Authors should be aware that this model for handling ignored elements may be revised in a future version of SMIL, and the related semantics may well change. These changes should not affect implementations that only support parse-time (or equivalent) evaluation of test attributes and/or the switch element. However, the semantics of dynamic re-evaluation (i.e. re-evaluation during document presentation) of test attributes and/or switch elements are not defined in this version of SMIL; this will be addressed in a future version.

Authors should realize that if several alternative elements are enclosed in a switch, and none of them evaluate to true, this may lead to situations such as a media object being shown without one or more companion objects. It is thus recommended to include a "catch-all" choice at the end of a switch which is acceptable in all cases.

4.3.3 Integration Requirements for the BasicContentControl Module

The functionality in this module does not build on functionality defined in other SMIL 2.1 modules.

4.3.4 Document Type Definition (DTD) for the BasicContentControl Module

See the full DTD for the SMIL Content Control modules.

4.4 The SMIL 2.1 CustomTestAttributes Module

4.4.1 SMIL 2.1 CustomTestAttributes Module Overview

The use of predefined system test attributes in the SMIL BasicContentControl module provides a selection mechanism based on attributes that are fixed within the module's definition. The CustomTestAttribute module extends this facility with the definition of author-defined custom test attributes. Custom test attributes allow presentation authors to define their own test attributes for use in a specific document. Custom test attributes may be shared among application documents using the uid attribute.

As with system test attributes, custom test attributes can be used within timing structure and media object elements; if they evaluate to true, the containing element is activated and if they evaluate to false, the containing element is ignored. In this version of SMIL, an ignored element will be treated as if it were not part of the source document. As a result, any element referencing the ID of the ignored node will, in effect, reference an invalid ID. Languages that integrate this module must specify any additional behavior related to these ignored elements.

Since custom test attributes are application/document specific, they need a mechanism to allow attribute definition and attribute setting. Attribute definition is done via the customAttributes and customTest elements. The initial state of any custom test attribute can be set at author-time with the defaultState attribute, which takes a value of either true or false. This module provides an override attribute with a value hidden that gives an author the ability to discourage runtime resetting of any attributes using these mechanisms.

The state of the attribute can be changed in one of three ways:

1. by modifying the value of the default state attribute in the document source before delivery to the player;
2. by using the unique identifier given in the uid attribute to dereference a runtime value for the customTest; or
3. by an interface presented to the user (or the user agent) through the document player at runtime.

The exact rules for setting and modifying the values associated with custom test attributes are given below.

An implementation may support either, both, or none of methods 2 and 3. If method 2 is supported, the URI value in uid is simply a unique identifier and does not imply that the runtime value must be fetched over the Web. The value may be stored and retrieved locally, and simply identified by the uid. The precise manner in which this is done is implementation dependent. If method 3 is supported, the custom test attribute facility does not require any specific UI support for direct user manipulation of the custom test attributes.

Example Use

The following example shows one way in which custom test attributes can be applied within a SMIL 2.1 Language profile document:

<smil>
  <head>
    <layout>
       <!-- define projection regions -->
    </layout>
    <customAttributes>
      <customTest id="west-coast" title="West Coast Edition" 
        defaultState="false" override="visible"  
        uid="http://defs.example.org/user-settings/west-coast" />
      <customTest id="east-coast" title="East Coast Edition" 
        defaultState="false" override="visible" 
        uid="http://defs.example.org/user-settings/east-coast" />
      <customTest id="far-north"  title="Northern Edition"
        defaultState="false" override="visible"
        uid="http://defs.example.org/user-settings/far-north" />
      <customTest id="the-rest"   title="National Edition"
        defaultState="true"  override="hidden" />
    </customAttributes>
  </head>
  <body>
    ...
    <par>
      <img src="background.png" region="a"/>
      <video src="story_1v.rm" region="b" />
      <switch>
        <audio src="story_1w.rm" region="c" customTest="west-coast"/>
        <audio src="story_1e.rm" region="c" customTest="east-coast"/>
        <audio src="story_1n.rm" region="c" customTest="far-north"/>
        <audio src="story_1r.rm" region="c" customTest="the-rest"/>
      </switch>
    </par>
    ...
  </body>
</smil>

The customAttributes element in the header contains the definition of the available custom test attributes. Each custom test attribute, defined by the customTest element, contains an identifier and a title (which can be used by a user agent, if available, to label the attribute), as well as an (optional) initial state definition, a UID that contains a unique identifier for the value setting for this attribute and an override flag.

The custom test variables named "west-coast", "east-coast" and "far-north" are defined with a default rendering state of false. They each contain a reference to a URI which is used to define local settings for the respective variables.

The custom test variable "the-rest" is defined with a default rendering setting of true.

Inside the body, a SMIL switch construct is used to select media objects for inclusion in a presentation depending on the values of the various custom test attributes. The first object that contains a value of true will be rendered, and since in this example the last option will always resolve true, it will be rendered if no other objects resolve to true.

While this example shows switch-based use of custom test attributes, the facility could also be applied as test attributes in in-line use.

Rules for Setting Values

The setting of the value associated with a custom test attribute proceeds as follows:

1. The initial setting is taken from the value of the defaultState attribute, if present. If no default state is explicitly defined, a value of false is used.
2. Next, if a URI mechanism is supported by the implementation, the URI defined by the uid attribute is checked to see if a persistent value has been defined for the custom test attribute with the associated id. If such a value is present, it is used instead of the default state defined in the document (if any). Otherwise, the existing initial state is maintained.
3. Next, if a UI-based mechanism (either via the SMIL DOM, a player GUI or some other means) is available and a value has been set by the user, the value associated with the custom test attribute is set to the user-specified value. If no user preference has been defined, either the UID-based value or the default value from the document text (in that order) is used.

Note that a user setting of the custom test attribute will take precedence over a URI setting. If the user has not specified a value for the attribute then the URI setting takes precedence. As with predefined system test attributes, this evaluation will occur in an implementation-defined manner. The value may be (re)evaluated dynamically, but this is not required. Note also that not all implementations need support uid or UI setting of attributes.

4.4.2 Elements and Attributes

This section defines the elements and attributes that make up the functionality in the SMIL CustomTestAttributes module. The customAttributes and customTest elements are used to define custom test attribute variables and the customTest attribute is used in-line on media object and timing structure references to control evaluation of the containing elements.

The customAttributes element

The customAttributes element contains definitions of each of the custom test attributes. The contained elements define a collection of author-specified test attributes that can be used in switch statements or as in-line test attributes in the document.

The customTest element

The customTest element defines an author-specified name that will be used as the test argument in the switch element or in-line on media object and timing structure elements. The customTest elements are defined within the section delineated by the customAttributes elements that make up part of the document header.

The customTest attribute

In addition to the customAttributes and customTest elements, this module provides a customTest attribute that can be applied by language designers to media objects and timing structure elements requiring selection. In all operational aspects, the custom test attribute is similar to the predefined system test attribute facility of the Basic Content Control module.

4.4.3 Integration Requirements for the CustomTestAttribute Module

The functionality in this module builds on functionality defined in the BasicContentControl module, which is a required prerequisite for inclusion of the CustomTestAttribute module.

The profile implementing the custom test elements and attributes must provide a means of associating a unique XML identifier with a customTest element, so that it can be used by the customTest attribute. And the profile should provide a means of associating descriptive text with a customTest element, which may be used in a GUI or other selection mechanism that may be presented to the user. For the SMIL 2.1 Language Profile, the element's id and title attributes serve this purpose.

4.4.4 Document Type Definition (DTD) for the CustomTestAttribute Module

See the full DTD for the SMIL Content Control modules.

4.5 The SMIL 2.1 PrefetchControl Module

4.5.1 SMIL 2.1 PrefetchControl Module Overview

This module defines an element and attributes that can be used to control the fetching of content from a server in a manner that will improve the rendering performance of the document.

This element will give a suggestion or hint to a user agent that a media resource will be used in the future and the author would like part or all of the resource fetched ahead of time to make the document playback smoother. User-agents can ignore prefetch elements, though doing so may cause an interruption in the document playback when the resource is needed. It gives authoring tools or savvy authors the ability to schedule retrieval of resources when they think that there is available bandwidth or time to do it. A prefetch element is contained within the body of an XML document, and its scheduling is based on its lexical order unless explicit timing is present.

Prefetching data from a URL that changes the content dynamically is potentially dangerous: if the entire resource isn't prefetched, a subsequent request for the remaining data may yield data from a newer resource. A user agent should respect any appropriate caching directives applied to the content, e.g. no-cache 822 headers in HTTP. More specifically, content marked as non-cacheable would have to be refetched each time it was played, where content that is cacheable could be prefetched once, with the results of the prefetch cached for future use.

Examples

1. Prefetch an image so it can be displayed immediately after a video ends:

    <smil xmlns="http://www.w3.org/2005/SMIL21/Language"> 
      <body> 
        <seq>
          <par>
            <prefetch id="endimage"
               src="http://www.example.org/logo.gif"/>
            <text id="interlude"
               src="http://www.example.org/pleasewait.html" fill="freeze"/>
          </par>
          <video id="main-event" src="rtsp://www.example.org/video.mpg"/> 
          <img src="http://www.example.org/logo.gif" dur="5s"/>  
       </seq> 
      </body> 
    </smil> 
       

   The example starts with a prefetch in parallel with the rendering of a text object. The text is discrete media so it ends immediately, the prefetch is defaulted to prefetch the entire image at full available bandwidth and the prefetch element ends when the image is downloaded. That ends the <par> and the video begins playing. When the video ends the image is shown.

2. Prefetch the images for a button so that rollover occurs quickly for the end user:

    <html>
    <body>
        <prefetch id="upimage" src="http://www.example.org/up.gif"/>
        <prefetch id="downimage" src="http://www.example.org/down.gif"/>
        ....
        <!-- script will change the graphic on rollover -->
        <img src="http://www.example.org/up.gif"/>
      </body>
    </html>
       

4.5.2 Elements and Attributes

The prefetch element

The prefetch gives authors a mechanism to influence the scheduling of media object transfers from a server to the player.

Documents must still playback even when the prefetch elements are ignored, although rebuffering or pauses in presentation of the document may occur. If the prefetch for a prefetch element is ignored, any timing on the element is still respected, e.g. if a prefetch element has a dur="5s", elements that depend on the prefetch element's timing behave as if the prefetch took 5 seconds.

The intrinsic duration of a prefetch element is either the duration of the media fetch, if the prefetch operation is supported by the implementation, or zero if prefetch is not supported.

If a prefetch element is repeated, due to restart or repeat on a parent element the prefetch operation should occur again. This insures appropriately "fresh" data is displayed if, for example, the prefetch is for a banner ad to a URL whose content changes with each request.

4.5.3 Integration Requirements for the PrefetchControl Module

A profile integrating the PrefetchControl module must add the attributes necessary to specify the media to be fetched. In general, these will be the same resource specifying attributes as those on the media elements themselves. In addition, the profile must add any necessary attributes to control the timing of the prefetch element.

4.5.4 Document Type Definition (DTD) for the PrefetchControl Module

See the full DTD for the SMIL Content Control modules.

4.6 The SMIL 2.1 SkipContentControl Module

4.6.1 SMIL 2.1 SkipContentControl Module Overview

This module contains one attribute, skip-content attribute, that can be used to selectively control the evaluation of the element on which this attribute appears. This attribute is introduced for future extensibility of SMIL. The functionality is unchanged from SMIL 1.0.

4.6.2 Elements and Attributes

Element definition

The SkipContentControl module does not contain any element definitions.

The skip-content attribute

4.6.3 Integration Requirements for the SkipContentControl Module

It is the responsibility of the language profile to specify which elements have skip-content attributes to enable this expansion mechanism.