15. The SMIL 3.0 State Modules

This section is informative.

The modules defined in this Chapter are all new modules which were not part of the SMIL 2.1.

The open issues at the time of writing this version of the SMIL State modules are:

• The StateTest module might be more at home in the Content Control Modules. Then the name Extended Content Control Module might also fit it better.
• In general, I don't much like the names. "State" means many different things to different people at different times.
• Many more, probably...

This section is informative.

A SMIL 2.1 presentation has a lot of state that influences how the presentation runs. Or, to rephrase that in a procedural way, state that influences decisions that the SMIL scheduler makes. All this state is either implicit in the presentation (what nodes are active and how long into their duration they are, how many iterations of a repeat we have done, which nodes in an excl are paused because a higher priority node has preempted them, etc), or completely external to the presentation (system tests and custom tests).

This has the effect that the only control flow that the SMIL author has at his/her disposal is that which is built in to the language, unless the SMIL engine includes some scripting language component and a DOM interface to the document that the author can use to create more complex logic.

In addition, the mechanisms that the BasicContentControl and CustomTestAttributes modules provide for testing values are limited: basically one can only test for predefined conditions being true (not for them being false) and there is a limited form of testing for multiple conditions with "and" being the only boolean operator.

The modules in this section provide a mechanism whereby the document author can create more complex controlflow than what SMIL provides through the timing and content control modules, without having to go all the way of using a scripting language. One way to provide this is to allow a document to have some explicit state (think: variables) along with ways to modify, use and save this state.

Application areas include things like quizzes, interactive adaptation of presentations to user preferences, computer-aided instruction and distant learning.

This section is informative.

The design of these modules was done after meeting with the W3C Backplane Group (part of the Hypertext Coordination Group) and various choices were influenced by the direction that group is taking.

These modules therefore borrow heavily from work done by other W3C working groups:

• The data model was taken from XForms, as was the use of XPath expressions.
• The XPath function interface to system and custom test data was modelled after work by the Device Independent WG.
• Attribute Value Templates used in StateInterpolation are lifted from XSLT.

This section is informative.

The SMIL 3.0 StateTest Module defined in this document is a new module which was not part of the SMIL 2.1.

This section is informative.

The mechanisms that the BasicContentControl and CustomTestAttributes modules provide for testing values are limited: basically one can only test for predefined conditions being true (not for them being false) and by specifying multiple system test attributes an author has a way to simulate an and operator but that is all.

This module introduces a generalized expr attribute that contains an expression. If the expression evaluates to false the element carrying the attribute is ignored.

This section is informative.

Here is a SMIL 3.0 Language Profile example of an audio element that is only played if audio descriptions are off and the internet connection is faster than 1Mbps. Think of using it for playing background music only when this will not interfere too much with the real presentation:

   <audio src="background.mp3" expr="not(smil-audioDesc()) and smil-bitrate() &gt; 1000000" />
   

This section is informative.

The SMIL 3.0 UserState Module defined in this document is a new module which was not part of the SMIL 2.1.

This section is informative.

This section introduces a data model that document authors can refer to in the context of the expr attribute, allowing elements to be rendered depending on author-defined values. Elements to change values in the data model are also included.

The actual choice of the data model is made in the language profile. The SMIL 3.0 Language Profile uses the XForms 1.0 data model.

This section is informative.

Here is a SMIL 3.0 Language Profile example of a sequence of audio clips that remembers the last audio clip played.

   <seq>
       <audio src="chapter1.mp3" />
       <setvalue ref="lastPlayed" value="1" />
       <audio src="chapter2.mp3" />
       <setvalue ref="lastPlayed" value="2" />
       <audio src="chapter3.mp3" />
       <setvalue ref="lastPlayed" value="3" />
   </seq>
   

Here is an extension of the previous example: not only is the last clip remembered but if this sequence is played again, later during the presentation, any audio clips played previously are skipped:

   <seq>
       <seq expr="lastPlayed &lt; 1">
           <audio src="chapter1.mp3" />
           <setvalue ref="lastPlayed" value="1" />
       </seq>
       <seq expr="lastPlayed &lt; 2">
           <audio src="chapter2.mp3" />
           <setvalue ref="lastPlayed" value="2" />
       </seq>
       <seq expr="lastPlayed &lt; 3">
           <audio src="chapter3.mp3" />
           <setvalue ref="lastPlayed" value="3" />
       </seq>
   </seq>
   

This section is informative.

As stated before, the actual choice of a data model is made in the profile that includes this module, but for ease of reading this section describes the data model used in the SMIL 3.0 Language Profile.

SMIL 3.0 uses the data model defined by XForms 1.0, see Introduction to XForms. This is a hierarchical data model with optional typing (through XML Schema) and spreadsheet-like dependencies between data items. There is a separation between the model, which contains the typing information and dependencies, and the instances, which contain the actual data. Instances are stored as XML trees, and can be contained in-line in the document or loaded from an external source. Instance data can also come from multiple places.

We are not sure the full XForms model is needed. We may want to cut down to the basic types, and we may introduce another, more minimal, data model. If we also have a newvalue element this would allow for basic state manipulation without exposing the SMIL author to all the details of data model, instance, etc.

The model is declared in the head, inside a state element. The XForms tags are not imported into the SMIL namespace, hence they need to use a namespace prefix.

Here is a quick breakdown of the most important tags:

model

Outer element for the data model. Contains all the other elements. An optional schema can be specified with the schema attribute.

instance

Defines some instance data for the model. Instance data can be contained as in-line XML or referenced through a src attribute.

bind

Defines constraints on data model elements. The elements to which the constraints apply are given with a nodeset attribute which takes an XPath expression. The expression can evaluate to multiple items. Type information for the nodeset can be given with the type attribute, pass an XML Schema type as parameter. Automatic value calculation can be specified through the calculate attribute, which expects an XPath expression.

submission

This element, which is only used if the StateSubmission module is included, determines how and where the instance data can be saved or transmitted. The most important attributes are:

ref

An XPath expression specifying the nodeset that is to be transmitted (default: / meaning everything).

action

A URL specifying where to transmit or save the nodeset.

method

How to serialize and transmit the data (such as post).

replace

What to replace with the reply: all for the whole SMIL presentation, instance for the instance data, none for nothing.

Data Model Examples

Here is the minimal state section that corresponds to the audio clip example above:

    <smil>
     <head>
      <state xmlns:f="http://www.w3.org/2002/xforms">
       <f:model>
        <f:instance>
         <data xmlns="">
          <lastPlayed>0</lastPlayed>
         </data>
        </f:instance>
       </f:model>
      </state>
      ...
  

Here is a more elaborate version of the previous example, which contains type checking, an automatic calculation and a submission tag that would save everything to a local file:

    <smil>
     <head>
      <state xmlns:f="http://www.w3.org/2002/xforms">
       <f:model>
        <f:instance>
         <data xmlns="">
          <lastPlayed>0</lastPlayed>
          <allPlayed/>
         </data>
        </f:instance>
        <f:bind nodeset="lastPlayed" type="xsd:integer"/>
        <f:bind nodeset="allPlayed" calculate="../lastPlayed &gt;= 3"/>
        <f:submission id="save" action="file:playstate.xml" method="post" replace="none"/>
       </f:model>
      </state>
      ...
  

This section is informative.

The SMIL 3.0 UserState Module defined in this document is a new module which was not part of the SMIL 2.1.

This section is informative.

This section introduces a method to save author defined state or to transmit it to an external server.

This section is informative.

To be provided.

This section is informative.

The SMIL 3.0 StateInterpolation Module defined in this document is a new module which was not part of the SMIL 2.1.

This section is informative.

This SMIL 3.0 Language Profile example shows an icon corresponding to the current CPU on which the user views the presentation, or a default icon for an unknown CPU:

   <switch>
    <img src="cpu-icons/{smil-CPU()}.png" />
    <img src="cpu-icons/unknown.png" />
   </switch>