précédent   suivant   sommaire  

10. Le module de temporisation et de synchronisation de SMIL 2.0

Rédacteurs :
Patrick Schmitz (cogit@ludicrum.org), (Microsoft)
Jeff Ayars (jeffa@real.com), (RealNetworks)
Bridie Saccocio (bridie@real.com), (RealNetworks)
Muriel Jourdan (Muriel.Jourdan@inrialpes.fr), (INRIA)


Table des matières

10.1 Introduction

Cette section est informative

Cette section définit le module de temporisation et de synchronisation. SMIL 1.0 a résolu des problèmes fondamentaux de synchronisation des médias et défini une facon puissante de chorégraphier des contenus multimédias. SMIL 2.0 étend la gestion de la temporisation et de la synchronisation en ajoutant des possibilités au modèle de temporisation et la syntaxe associée. Certains éléments de la syntaxe de SMIL 1.0 ont été modifiés ou dépréciés. Cette section du document spécifie le module de temporisation et de synchronisation.

Deux audiences sont visées par ce module : les développeurs de visualisateurs ou d'éditeur SMIL 2.0 et les auteurs d'autres langages XML désirant intégrer des éléments de temporisation et de synchronisation. Un langage auquel ce module est intégré est appelé langage hôte. Un document contenant des éléments et attributs de temporisation et de synchronisation SMIL est appelé document hôte.

Comme ce module est utilisé dans différents profiles (i.e., langages hôtes), les exigences de la syntaxe associée peuvent varier. Ces différences de syntaxe devraient rester minimes aussi bien que pratiques.

La gestion de la temporisation et de la synchronisation de SMIL 2.0 est découpée en 15 modules, permettant ainsi une grande flexibilité pour les créateurs d'autres langages intégrant ces fonctionnalités. Ces modules sont décrits dans « Annexe E : Les modules de temporisation et de synchronisation de SMIL ».

10.2 Aperçu de la temporisation de SMIL

Cette section est informative.

La temporisation de SMIL définit les éléments et attributs servant à coordonner et synchroniser la présentation d'un média au cours du temps. Le terme de média couvre un large champs, incluant les types de médias discrets tels que les images fixes, le texte et les graphiques vectoriels, ainsi que les types de médias continus étant intrinsèquement basés sur le temps tels que la vidéo, l'audio et les animations.

Trois éléments de synchronisation gèrent des utilisations de temporisation communes :

Ces éléments sont appelés conteneurs de temps. Ils regroupent les enfants qu'ils contiennent selon des plans de montage chronologiques coordonnées.

La temporisation de SMIL fournit également des attributs permettant de spécifier le comportement d'un élément au cours du temps. Les éléments ont un début et une durée simple. Le début peut être spécifié de différentes façons : par exemple, un élément peut démarrer à un temps donné, ou se baser sur le démarrage d'un autre élément, ou encore démarrer en réponse à un événement (un clic de souris par exemple). La durée simple définit la durée de présentation de base d'un élément. Les éléments peuvent être définis pour répéter une durée simple, un certain nombre de fois ou encore pendant un certain temps. La durée simple et les effets de répétition sont combinés pour donner la durée active. Lorsque la durée active d'un élément est écoulée, celui-ci peut être soit retiré de la présentation, soit gelé (conservé dans son dernier état), par exemple pour combler un espace dans la présentation.

Un élément devient actif lorsque démarre sa durée active et devient inactif lorsque se termine sa durée active. Durant sa durée active, l'élément est actif, et en dehors de sa durée active, l'élément est inactif.

La Figure 1 illustre la gestion d'un élément se répétant dans un simple conteneur de temps <par>. La syntaxe correspondante est incluse dans le diagramme.

Basic strip illustration of timing

<par begin="0s" dur="33s">
   <video begin="1s" dur="10s" repeatCount="2.5" fill="freeze" .../>
</par>

Figure 1 - Le diagramme partiel montre une gestion de base de la temporisation. Le terme « Durée simple* » indique que cette durée simple est coupée avant sa fin.

Les attributs qui contrôle cet aspect de la temporisation ne servent pas que pour les éléments médias, mais aussi pour les conteneurs de temps. Cela permet par exemple de répéter une séquence entière et de la coordonner comme une seule entité avec d'autres médias ou d'autres conteneurs de temps. Même si les auteurs peuvent spécifier une durée simple pour le conteneur de temps, il est souvent plus simple de la laisser non spécifiée, auquel cas ce sont les éléments enfants contenus qui définiront cette durée. Lorsqu'un élément n'a pas de durée simple spécifiée, le modèle temporel définit une durée simple implicite pour l'élément. Par exemple, la durée simple implicite d'une séquence est calculée par la somme des durées actives de tous ses enfants.

Chaque conteneur de temps impose un certain nombre de valeurs par défaut et de contraintes sur les enfants contenus. Par exemple dans un élément <seq>, les éléments commencent par défaut juste après la fin de l'élément précédent et dans tous les conteneurs de temps, la durée active de tout élément enfant est contrainte de ne pas dépasser la durée simple du conteneur. La figure 2 illustre les effets de la répétition d'un conteneur <par> et de ses contraintes sur un élément enfant <video>.

More complex strip illustration of timing

<par begin="0s" dur="12s" repeatDur="33s" fill="freeze" >
   <video begin="1s" dur="5s" repeatCount="1.8" fill="freeze" .../>
</par>

Figure 2 - Le diagramme partiel montre les contraintes d'un conteneur de temps sur les éléments enfants. Le terme « Durée simple* » indique que cette durée simple est coupée avant sa fin.

Le modèle de temporisation de SMIL définit comment les éléments du conteneur de temps et les attributs de temporisation sont interprétés pour construire un graphe temporel. Le graphe temporel modélise la planification et les relations de synchronisation de la présentation. Le graphe temporel est une structure dynamique, changeant en fonction des événements induits par l'utilisateur, des réceptions de média et du contrôle DOM de la présentation. À tout instant donné, le graphe temporel modélise le document à cet instant et la sémantique décrite dans ce module. Cependant, comme les événements induits par l'utilisateur ou d'autres facteurs créent des changements dans les éléments, les règles sémantiques sont réévaluées pour conserver un graphe temporel à jour.

Lorsqu'une valeur begin ou end se rapporte à un événement, ou au début ou à la fin active d'un autre élément, il peut être impossible de calculer la valeur de temps. Par exemple, si un élément est prévu pour démarrer lors d'un certain événement, la valeur de temps de begin ne sera pas connue avant que l'événement ne se produise. Ces valeurs begin et end sont alors dites non résolues. Quand une telle valeur de temps est connue (i.e., quand on peut la calculer comme temps dans la présentation), elle est dite résolue. Un temps résolu est dit défini s'il n'a pas la valeur indefinite. Voir aussi la discussion dans « La consolidation de la temporisation basée sur les événements et de la temporisation planifiée ».

Dans un environnement idéal, la présentation devrait se dérouler exactement comme spécifiée. Cependant, les diverses limitations du monde réel (tel que les retards dus à l'encombrement du réseau) peuvent influer sur la lecture effective d'un média. La façon dont l'application s'adapte et gère la présentation par rapport aux problèmes d'interprétation d'un média est appelée comportement de synchronisation à l'exécution. SMIL possède des attributs permettant à l'auteur de contrôler ce comportement de synchronisation à l'exécution pour la présentation.

10.3 La définition du Langage

Cette section est informative

Le modèle de temporisation est construit en allant des concepts les plus simples aux plus complexes : tout d'abord les contrôles de temporisation de base et de durée simple, ensuite les attributs de contrôle des répétitions et de contrainte des durées actives. Finalement les éléments de définition des conteneurs de temps seront présentés.

Le modèle temporel dépend d'un certain nombre de définitions à propos du document hôte : un document hôte est présenté sur un intervalle de temps.

10.3.1 Les attributs

Cette section définit l'ensemble des attributs de temporisation communs à tous les éléments de synchronisation SMIL.

Sauf indication contraire, dans ce qui suit, en cas d'erreur dans la syntaxe de la valeur d'argument d'un attribut, l'attribut sera ignoré ( comme s'il n'était pas spécifié).

Les attributs begin et dur : La gestion de base de la temporisation

Cette section est informative.

La temporisation de base pour un élément se fait grâce aux attributs begin et dur. Les auteurs peuvent exprimer le début d'un élément de plusieurs façons différentes, allant des temps d'horloge simples au temps où se produit un événement (par exemple, un clic de souris). La durée simple d'un élément est définie comme une simple valeur de temps. La syntaxe de l'attribut begin est décrite ci-dessous. Les règles de syntaxe formelle pour chaque valeur d'attribut sont décrites dans « Les grammaires des valeurs des attributs de temporisation » ; un résumé de la syntaxe de la valeur d'un attribut est fourni ici afin d'aider le lecteur.

Cette section est normative.

begin : smil-1.0-syncbase-value | begin-value-list
Définit quand un élément devient actif.
La valeur de l'attribut est soit une déclaration de base de synchronisation SMIL 1.0, soit une liste de valeurs séparées par des points-virgules.
smil-1.0-syncbase-value : "id(" Id-value ")" ( "(" ( "begin" | "end" | Clock-value ) ")" )?
Déprécié. Décrit une base de synchronisation et un décalage par rapport à cette base de synchronisation. Le début de l'élément est défini par rapport au début ou à la fin active d'un autre élément.
begin-value-list : begin-value (";" begin-value-list )?
Une liste de valeurs séparées par des points-virgules. L'interprétation d'une liste de temps de début est détaillée dans la section « L'évaluation des listes des temps de début et de fin ».
begin-value : ( offset-value | syncbase-value | event-value | repeat-value | accesskey-value | media-marker-value | wallclock-sync-value | "indefinite" )
Décrit le début d'un élément.
offset-value : ( "+" | "-" )? Clock-value
Décrit le début d'un élément comme un décalage par rapport à une base de synchronisation implicite. La définition de la base de synchronisation implicite dépend du conteneur de temps parent de l'élément. Le décalage est mesuré dans le temps simple du parent.
syncbase-value : ( Id-value "." ( "begin" | "end" ) ) ( ( "+" | "-" ) Clock-value )?
Décrit une une base de synchronisation et un décalage par rapport à celle-ci. Le début de l'élément est défini par rapport au début ou à la fin active d'un autre élément.
event-value : ( Id-value "." )? ( event-ref  ) ( ( "+" | "-" ) Clock-value )?
Décrit un événement et un décalage optionnel qui déterminent le début de l'élément. Le début de l'élément est défini par rapport au moment où cet événement s'est déclenché. Les événements peuvent être n'importe quel événement défini pour le langage hôte en accord avec [DOM2Events]. Cela peut être des événements de l'interface utilisateur, des déclencheurs d'événement transmis par le réseau, etc. Les détails de la temporisation liée aux événements sont décrits dans la section ci-dessous « La consolidation de la temporisation basée sur les événements et de la temporisation planifiée ».
repeat-value : ( Id-value "." )? "repeat(" integer ")" ( ( "+" | "-" ) Clock-value )?
Décrit un événement de répétition qualifié. Le début de l'élément est défini par rapport au moment du déclenchement de l'événement repeat avec une valeur d'itération spécifiée.
accesskey-value : "accesskey(" character ")"( ( "+" | "-" ) Clock-value )?
Décrit une clé d'accès qui détermine le début de l'élément. Le début de l'élément est déterminé par rapport au moment où le caractère correspondant à la clé d'accès est entré par l'utilisateur.
media-marker-value : Id-value ".marker(" marker-name ")"
Décrit le début de l'élément comme point de montage nommé défini par un élément média.
wallclock-sync-value : "wallclock(" wallclock-value ")"
Décrit le début de l'élément comme un temps d'une horloge réelle. La syntaxe du temps d'une horloge réelle est basée sur la syntaxe définie dans la norme [ISO8601].
"indefinite"
Le début de l'élément sera déterminé par un appel à la méthode "beginElement()" ou un hyperlien pointant sur l'élément.
Les méthodes du DOM pour la temporisation et la synchronisation SMIL sont décrites dans la section « Les méthodes réservées du DOM ».
La temporisation basée sur les hyperliens est décrite dans la section « Les hyperliens et la temporisation ».
Sémantique de la valeur de begin

Cette section est normative

Cette section est informative.

Les enfants d'un conteneur par commencent par défaut lorsque le conteneur commence (ce qui équivaut à begin="0s"). Les enfants d'un conteneur seq commencent par défaut lorsque l'enfant précédent termine sa durée active (ce qui équivaut à begin="0s") et le premier commence par défaut lorsque le conteneur commence. Les enfants d'un conteneur excl ont par défaut une valeur de début de "indefinite".

La valeur de begin peut spécifier une liste de temps. Cela peut servir à spécifier plusieurs « moyens » ou « règles » pour commencer un élément, par exemple si l'un d'entre plusieurs événements est déclenché. Une liste de temps peut aussi définir plusieurs temps de début, permettant de jouer un élément plus d'une fois (ce comportement peut être contrôlé, par exemple, pour ne permettre que l'utilisation effective du début le plus antérieur - voir aussi « L'attribut restart »).

En général, le temps le plus précoce dans la liste détermine le temps de début de l'élément. Il y a d'autres contraintes sur l'évaluation d'une liste de temps de début qui sont détaillées dans la section « L'évaluation des listes des temps de début et de fin ».

Notez que même s'il est possible de mettre la valeur "indefinite" dans une liste de valeurs de begin, la valeur "indefinite" n'est réellement utile que comme valeur simple. La combiner avec d'autres valeurs n'influe pas sur la temporisation du début, car les méthodes de début du DOM peuvent être invoquées avec ou sans la spécification de "indefinite" pour begin.

Lorsqu'un temps de début est spécifié comme variante de base de synchronisation, une valeur de marqueur ou une valeur d'horloge réelle, le temps défini doit être converti par l'implémentation en un temps relatif au conteneur de temps parent ( c'est-à-dire, en un temps qui équivaut à une valeur de décalage). Ceci est appelé conversion de l'espace temporel et est détaillé dans la section « La conversion entre temps local et temps global ».

La gestion des décalages négatifs pour begin

Cette section est informative.

L'utilisation de décalages négatifs pour définir des temps de début définit simplement les relations de synchronisation de l'élément. Cela ne surclasse en aucun cas les contraintes du conteneur de temps et cela ne peut surclasser les contraintes de temps de la présentation.

Cette section est normative.

Le temps de début calculé définit la relation de synchronisation planifiée de l'élément, même s'il n'est pas possible de démarrer l'élément au moment calculé. Le modèle temporel utilise le temps de début calculé et non pas le temps observé du début de l'élément.

Cette section est informative.

Si un élément a un début qui est résolu comme devant commencer avant le début du conteneur de temps parent, les contraintes du conteneur s'appliquent toujours. Par exemple :

<par>
   <video id="vid" begin="-5s" dur="10s" src="movie.mpg" />
   <audio begin="vid.begin+2s" dur="8s" src="sound.au" />
</par>

L'élément video ne peut démarrer avant que l'élément par ne commence. Le début est simplement défini comme ayant débuté « dans le passé » lors du début de par. Le lecteur observera que la vidéo commence à 5 secondes de son début, et se termine au bout de 5 secondes. Notez que l'élément audio commence par rapport au début de la vidéo et que le temps de début calculé est utilisé et non le temps de début observé contraint par le parent. De ce fait, l'audio commence à 3 secondes de son début et dure également 5 secondes.

Le comportement peut être rapproché de l'utilisation d'une valeur de l'attribut clipBegin appliquée sur l'élément, mais qui ne s'applique qu'à la première itération d'éléments se répétant. Dans l'exemple précédent, si l'un des éléments était défini pour se répéter, la seconde itération puis les suivantes du média seraient jouées à partir du début du média (voir aussi «Les attributs repeatCount, repeatDur et repeat : les éléments de répétition  »).

Cette section est normative.

Le comportement peut être rapproché de l'utilisation d'une valeur de l'attribut clipBegin appliquée sur l'élément, mais qui ne s'applique qu'à la première itération des éléments se répétant.

En fait, l'élément commence au temps de début calculé en suivant l'algorithme ci-dessous :

Let o be the offset value of a given begin value,
d be the associated simple duration,
AD be the associated active duration.
Let rAt be the time when the begin time becomes resolved.
Let rTo be the resolved sync-base or event-base time without the offset
Let rD be rTo - rAt.	If rD < 0 then rD is set to 0.
 
If AD is indefinite, it compares greater than any value of o or ABS(o).
REM( x, y ) is defined as x - (y * floor( x/y )). 
If y is indefinite or unresolved, REM( x, y ) is just x.

Let mb = REM( ABS(o), d ) - rD
If ABS(o) >= AD then the element does not begin.
Else if mb >= 0 then the media begins at mb.
Else the media begins at mb + d.
Soit o la valeur de décalage d'une valeur de début donnée,
d la durée simple associée,
AD la durée active associée.
Soit rAt le temps où le temps de début se résoud.
Soit rTo le temps de la base de synchronisation, ou celui basé sur un événement, sans le décalage
Soit rD égal à rTo - rAt. Si rD < 0, alors rD égale 0

Si AD est indéfini, il est évalué supérieur à toute valeur de o ou ABS(o).
REM( x, y ) est défini comme x - (y * floor( x/y )).
Si y est indéfini ou non-résolu, REM( x, y ) correspond juste à x.

Soit mb = REM( ABS(o), d ) - rD
Si ABS(o) >= AD, alors l'élément ne commence pas.
Autrement si mb >= 0, alors le média commence à mb.
Sinon le média commence à mb + d.

Si l'élément se répète, la valeur d'itération de l'événement de repeat se calcule à partir du temps de début calculé ci-dessus et non pas sur le nombre observé de répétitions.

Cette section est informative.

Exemple :

<smil ...> 
...
<ref begin="foo.activateEvent-8s" dur="3s" repeatCount="10" .../>
...
</smil>

L'élément commence lorsque l'utilisateur active (en cliquant par exemple) l'élément "foo". Le temps de début est calculé comme étant 8 secondes plus tôt et commence donc à se jouer à 2 secondes dans la durée simple de 3 secondes, dans la troisième itération de la répétition. Une seconde plus tard, la quatrième itération de l'élément va commencer et l'événement repeat associé aura son compteur d'itération à 3 ( celui-ci commençant à 0). L'élément se terminera 22 secondes après son activation. L'événement beginEvent est déclenché lorsque l'élément commence, mais a une valeur d'estampille qui correspond au temps de début défini, i.e., 8 secondes plus tôt. Les dépendants temporels sont activés par rapport au temps de début calculé et non par rapport au temps de début observé.

Note : Si les auteurs de scripts désirent distinguer le nombre d'itérations calculé du nombre d'itérations observé, ils peuvent compter le nombre effectif des événements repeat dans le gestionnaire d'événement associé.

Les délais négatifs de début

Un temps de début spécifie une relation de synchronisation entre l'élément et son conteneur de temps parent. La temporisation des variantes de base de synchronisation, d'une base d'événement, d'un marqueur ou d'une horloge réelle est implicitement convertie en un décalage sur le conteneur de temps parent, tout comme le spécifierait directement une valeur de décalage. Pour les enfants d'un élément seq, il s'agit toujours d'un décalage positif à partir du début du conteneur de temps seq. Cependant, pour les enfants de conteneurs de temps par et excl, le décalage calculé, par rapport au temps de début du parent, peut être négatif.

Notez qu'un élément ne peut pas effectivement commencer avant que le conteneur de temps parent ne commence. Un élément avec un délai de temps négatif se comporte comme s'il avait commencé plus tôt. L'effet sur la présentation pour l'élément (par exemple, l'affichage d'un média visuel) est équivalent à celui d'une valeur de l'attribut clipBegin (avec la même magnitude) pour la première, et seulement la première, itération d'un élément répété. Si aucune répétition n'est spécifiée, l'effet sur la présentation pour l'élément d'un décalage de début négatif est équivalent à celui d'une spécification de clipBegin, avec la même magnitude que la valeur de décalage. Néanmoins, les effets secondaires de la « temporisation » ne sont pas équivalents à ce qui est décrit pour une valeur de clipBegin. Tout ce qui dépend de la valeur de début se comportera comme si l'élément avait démarré plus tôt.

La sémantique de la valeur de dur

La longueur de la durée simple est spécifiée par l'attribut dur. La syntaxe de cet attribut est décrite ci-dessous.

Cette section est normative.

dur
Spécifie une durée simple.
L'attribut prend sa valeur dans ce qui suit :
Clock-value
Spécifie la longueur de la durée simple, mesurée dans le temps actif de l'élément.
La valeur doit être supérieure à 0.
"media"
Spécifie la durée simple en tant que durée intrinsèque du média. Ceci n'est valide que pour les éléments définissant un média.
"indefinite"
Spécifie une durée simple indéfinie.

S'il y a la moindre erreur de syntaxe dans l'argument de valeur de dur, l'attribut sera ignoré (comme s'il n'était pas défini).

Si la valeur "media" est utilisée pour l'attribut d'un élément qui ne définit pas un média (par exemple, les conteneur de temps SMIL 2.0 par, seq et excl), l'attribut sera ignoré (comme s'il n'était pas défini). Les médias contenus, tels que les enfants d'un élément par, ne sont pas considérés comme des médias directement associés à l'élément.

Si l'élément n'a pas d'attribut dur (valide), la durée simple de cet élément est définie comme étant sa durée implicite. La durée implicite dépend du type de l'élément. La première distinction se fait entre les différents types des éléments médias et des conteneurs de temps. Si l'élément média n'a pas d'enfant temporisé, il est appelé élément média simple.

Si l'auteur spécifie une valeur pour l'attribut dur qui est plus courte que la durée implicite pour un élément, la durée implicite sera écourtée par la durée simple spécifiée.

Si l'auteur spécifie une durée simple qui est plus longue que la durée implicite pour un élément, la durée implicite de l'élément sera étendue à la durée simple spécifée :

Notez que, quand une durée simple est "indefinite", certains cas d'utilisation simple peuvent conduire à des résultats surprenants. Voir l'exemple #4 de l'Annexe B.

Exemples

L'exemple suivant montre une temporisation de début avec un décalage simple. L'élément <audio> démarre 5 secondes après que le conteneur de temps <par> a commencé et se termine 4 secondes plus tard.

<par>
   <audio src="song1.au" begin="5s" dur="4s" />
</par>

L'exemple suivant montre une temporisation de début avec une base de synchronisation. L'élément <img> démarre 2 secondes après le début de l'élément <audio>

<par>
   <audio id="song1" src="song1.au" />
   <img src="img1.jpg" begin="song1.begin+2s" />
</par>

Les éléments peuvent aussi être spécifiés pour commencer en réponse à un événement. Dans cet exemple, l'élément image commence (apparaît) quand l'utilisateur clique sur l'élément "show". L'image se termine (disparaît) 3 secondes et demi plus tard.

<smil ...>
...
<text id="show" ... />
<img begin="show.activateEvent" dur="3.5s" ... />
...
</smil ...>

L'attribut end : le contrôle de la durée active

Cette section est informative.

SMIL 2.0 fournit un contrôle supplémentaire sur la durée active. L'attribut end permet à l'auteur de contraindre la durée active en spécifiant une valeur de fin via un décalage simple, une base de temps, une base d'événement, une base de synchronisation ou des appels aux méthodes DOM. Les règles pour combiner les attributs afin de calculer la durée active sont présentées dans la section « Le calcul de la durée active ».

Les règles de syntaxe de chaque valeur d'attribut sont décrites dans la section « Les grammaires des valeurs des attributs de temporisation ». Un résumé de la syntaxe est fourni ici afin d'aider le lecteur.

Cette section est normative.

end : smil-1.0-syncbase-value | end-value-list
Définit une valeur de fin pour l'élément pouvant contraindre la durée active.
La valeur de l'attribut est soit une déclaration de base de synchronisation SMIL 1.0, soit une liste de valeurs séparées par des points-virgules.
smil-1.0-syncbase-value : "id(" Id-value ")" ( "(" ( "begin" | "end" | Clock-value ) ")" )?
Déprécié. Décrit une base de synchronisation et un décalage à partir de cette base de synchronisation. La fin de l'élément est définie par rapport au début ou à la fin active d'un autre élément.
end-value-list : end-value (";" end-value-list )?
Une liste de valeurs de fin séparées par des points-virgules. L'interprétation d'une liste de temps de fins est détaillée dans la section « L'évaluation des listes des temps de début et de fin ».
end-value : ( offset-value | syncbase-value | event-value | repeat-value | accesskey-value | media-marker-value | wallclock-sync-value | "indefinite" )
Décrit la valeur de fin d'un élément.
offset-value : ( "+" | "-" )? Clock-value
Décrit la valeur de fin comme un décalage par rapport à une base de synchronisation implicite. La définition de la base de synchronisation implicite dépend du conteneur de temps parent. Le décalage est mesuré dans le temps simple du conteneur parent.
syncbase-value : ( Id-value "." ( "begin" | "end" ) ) ( ( "+" | "-" ) Clock-value )?
Décrit une base de synchronisation et un décalage à partir de cette base de synchronisation. La fin de l'élément est définie par rapport au début ou à la fin active d'un autre élément.
event-value : ( Id-value "." )? ( event-ref  ) ( ( "+" | "-" ) Clock-value )?
Décrit un événement et un décalage optionnel qui détermine la valeur de fin. La valeur de fin est définie par rapport au moment où cet événement s'est déclenché. Les événements peuvent être n'importe quel événement défini pour le langage hôte en accord avec [DOM2Events]. Cela peut être des événements de l'interface utilisateur, des déclencheurs d'événement transmis par le réseau, etc. Les détails de la temporisation liée aux événements sont décrits dans la section ci-dessous « La consolidation de la temporisation basée sur les événements et de la temporisation planifiée ».
repeat-value : ( Id-value "." )? "repeat(" integer ")" ( ( "+" | "-" ) Clock-value )?
Décrit un événement de répétion qualifié. La fin de l'élément est définie par rapport au moment du déclenchement de l'événement répétition avec une valeur d'itération spécifiée.
accesskey-value : "accesskey(" character ")"( ( "+" | "-" ) Clock-value )?
Décrit une clé d'accès qui détermine la fin de l'élément. La fin de l'élément est déterminée par rapport au moment où le caractère correspondant à la touche d'accès est entré par l'utilisateur.
media-marker-value : Id-value ".marker(" marker-name ")"
Décrit la la valeur de fin comme un temps de marqueur nommé défini par un élément de média.
wallclock-sync-value : "wallclock(" wallclock-value ")"
Décrit la valeur de fin en tant que temps d'une horloge réelle. La syntaxe du temps d'une horloge réelle est basée sur la syntaxe définie dans la norme [ISO8601].
"indefinite"
La valeur de fin de l'élément sera déterminée par un appel à la méthodeendElement().
Les méthodes du DOM pour la temporisation et la synchronisation SMIL sont décrites dans la section « Les méthodes réservées du DOM ».

Si un attribut end est spécifié mais aucun des attributs dur, repeatCount ou repeatDur, la durée simple est définie comme étant "indefinite" et la valeur de end contraint la définition de la durée . Le comportement de la durée simple dans ce cas est défini dans « La sémantique de la valeur de dur », comme si l'attribut dur avait la valeur "indefinite".

Si la valeur de end est résolue pendant que l'élément est actif, et que le temps résolu est dans le passé, l'élément devrait immédiatement terminer sa durée active. Les dépendants temporels définis par rapport à la fin de cet élément devraient être résolus en utilisant la fin active calculée (qui peut se trouver dans le passé) et non pas la fin active observée.

Les valeur dépréciées smil-1.0-syncbase-values sont sémantiquement équivalentes aux types end-values SMIL 2.0 suivants :

Cette section est informative.

La valeur de end peut spécifier une liste de temps. Cela peut servir à spécifier plusieurs « façons » ou « règles » pour terminer un élément, par exemple, si l'un de plusieurs événements est déclenché. Une liste de temps peut aussi définir plusieurs temps de fin correspondant à plusieurs temps de début, permettant à un élément de jouer plus d'une fois (ce comportement peut être contrôlé - voir aussi « L'attribut restart »).

Dans l'exemple suivant, l'attribut dur n'est pas spécifié et ainsi la durée simple est définie comme étant la durée implicite du média. Dans ce cas (et dans ce cas seulement), la valeur de end va augmenter la durée active si l'attribut dur spécifie une durée plus grande que la durée implicite. La vidéo va être affichée pendant 8 secondes et ensuite la dernière image restera affichée encore 2 secondes.

<video end="10s" src="8-SecondVideo.mpg" .../>

Si un auteur désire spécifier une durée implicite en même temps qu'une contrainte de fin, l'attribut dur peut être spécifié comme "media". Dans l'exemple suivant, l'élément se terminera au plus tôt entre la durée intrinsèque et un clic de souris :

<html ...>
...
<video dur="media" end="click" src="movie.mpg" .../>
...
</html>

Ces cas peuvent naître de l'utilisation de valeurs négatives dans les formes avec base de synchronisation et base d'événementielle, et les auteurs devraient rester vigilants vis à vis des complexités qui peuvent en résulter. Voir aussi « La gestion des valeurs négatives pour end ».

Dans l'exemple suivant, la durée active se terminera au plus tôt entre les 10 secondes et la fin de l'élément "foo". Ceci est particulièrement pratique si "foo" est défini pour commencer ou finir en fonction d'un événement.

<audio src="foo.au" dur="2s" repeatDur="10s" 
	 end="foo.end" .../>

Dans l'exemple suivant, la durée active se terminera au bout de 10 secondes et raccourcira la durée simple définie pour 20 secondes. L'effet est que seule la première moitié de l'élément est effectivement jouée. Pour un élément média simple, l'auteur peut simplement spécifier cela en utilisant l'attribut dur. Quoiqu'il en soit dans d'autres cas, il est parfois important de pouvoir spécifier la durée simple indépendamment de la durée active.

<par>
   <audio src="music.au" dur="20s" end="10s" ... />
</par>

Dans l'exemple suivant, l'élément commence quand l'utilisateur active (i.e., clique sur) l'élément "gobtn". La durée active se terminera 30 secondes après que le temps du conteneur de temps parent a commencé.

<smil ...>
...
<par>
<audio src="music.au" begin="gobtn.activateEvent" repeatDur="indefinite"
          end="30s" ... />
     <img src="foo.jpg" dur="40s" ... />
</par>
...
</smil>

Notez que si l'utilisateur ne clique pas sur l'élément cible avant que les 30 secondes ne soient écoulées, l'élément ne sera jamais lancé. Dans ce cas, l'élément n'a ni durée active ni fin active.

Les valeurs par défaut pour la syntaxe des événements facilitent la définition d'un comportement interactif simple. Dans l'exemple suivant, l'image s'arrète quand l'utilisateur clique sur l'élément.

<html ...>
...
<img src="image.jpg" end="click" />
...
</html>

L'utilisation de l'attribut end avec une valeur d'événement permet aux auteurs de terminer un élément soit avec un événement interactif, soit avec une durée active maximum. Ceci est parfois appelé interaction paresseuse.

Dans cet exemple, une présentation décrit les processus d'une usine. Chaque étape est une vidéo prévue pour se répéter 3 fois afin que les choses soient claires. Chaque élément peut également être arrêté en cliquant sur la vidéo ou sur un certain élément "next" indiquant à l'utilisateur que l'étape suivante peut être visualisée.

<smil ...>
...
<seq>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
</seq>
...
</smil>

Dans ce cas, la fin active de chaque élément est définie pour intervenir au plus tôt entre 15 secondes (durée de 5s * 3 répétitions) après que l'élément a commencé et un clic sur "next". Cela donne à l'utilisateur le choix entre s'asseoir et regarder, et faire défiler la présentation à un rythme plus élevé.

La gestion des valeurs négatives pour end

Cette section est normative.

Les attributs min et max : un contrôle accru de la durée active

Cette section est informative.

Les attributs min/max permettent à l'auteur de contrôler les limites inférieure et supérieure de la durée active de l'élément.

Cette section est normative.

min
Spécifie la valeur minimum de la durée active.
La valeur de l'attribut peut être l'une des suivantes :
Clock-value
Spécifie la longueur de la valeur minimum de la durée active, mesurée en temps actif de l'élément.
La valeur doit être supérieure ou égale à 0.
"media"
Spécifie la valeur minimum de la durée active comme étant la durée intrinsèque du média. Cela n'est valide que pour les éléments définissant un média.

S'il y a la moindre erreur dans la syntaxe de la valeur de min, l'attribut sera ignoré (comme s'il n'avait pas été spécifié).

La valeur par défaut de min est "0". Cela ne contraint pas du tout la durée active.

max
Spécifie la valeur maximum de la durée active.
La valeur de l'attribut peut être l'une des suivantes :
Clock-value
Spécifie la longueur de la valeur maximum de la durée active.
La valeur doit être supérieure à 0.
"media"
Spécifie la durée maximum de la durée active comme étant la durée intrinsèque du média. Cela n'est valide que pour les éléments définissant un média.
"indefinite"
La valeur maximum de la durée active est indéfinie et n'est pas contrainte de ce fait.

S'il y a la moindre erreur dans la syntaxe de la valeur de max, l'attribut sera ignoré (comme s'il n'avait pas été spécifié).

La valeur par défaut de max est "indefinite". Cela ne contraint pas du tout la durée active.

Si la valeur "media" est spécifiée pour les attributs min ou max sur un élément qui ne définit pas de média (par exemple, sur les éléments conteneurs de temps SMIL 2.0 par, seq ou excl), l'attribut en question sera ignoré (comme s'il n'avait pas été spécifié). Les médias contenus, tels que les enfants d'un élément par, ne sont pas considérés comme des médias directement associés à l'élément.

Si à la fois les attributs min et max sont définis, alors la valeur de max doit être supérieure ou égale à celle de min. Si cette condition n'est pas remplie, les deux attributs seront ignorés.

La règle à appliquer, pour calculer la durée active d'un élément dont les attributs min ou max sont spécifiés, est la suivante : chaque fois que la durée active d'un élément est calculée (i.e., pour chaque intervalle de l'élément si celui-ci commence plus d'une fois), ce calcul est fait sans tenir compte des valeurs de min et max (en appliquant l'algorithme décrit dans « Le calcul de la durée active »). Le résultat de cette étape est comparé aux limites min et max. Si le résultat est à l'intérieur des limites, alors cette première valeur calculée est retenue. Sinon, deux cas de figures peuvent se présenter :

Cette section est informative.

Les exemples suivants illustrent quelques cas d'utilisation des attributs min et max :

Exemple 1. Dans l'exemple suivant, la vidéo va simplement être jouée pendant 10 secondes.

<smil ...>
...
<par >
   <video id="video_of_15s" max="10s".../>
</par>
...
</smil>

Exemple 2. Dans l'exemple suivant, si un événement d'activation se produit avant 10 secondes, cette activation (par exemple, un clic de souris) ne va pas interrompre la vidéo immédiatement, mais celle-ci va continuer pendant 10 secondes puis s'arrêter. Si un événement de clic se produit après les 10 secondes, la vidéo est jouée (en se répétant) jusqu'à ce que le clic survienne. Notez que l'événement endEvent ne se produit que si un clic a lieu après les 10 secondes et pas à la fin simple de chaque répétition.

<smil ...>
...
<par >
   <video id="video_of_15s" repeatDur="indefinite" end="activateEvent" min="10s".../>
</par>
...
</smil>

Exemple 3. Dans l'exemple suivant, si un événement d'activation se produit sur l'élément "foo" à 5 secondes, cet événement ne termine pas le conteneur de temps tout de suite, mais à 12 secondes. La durée simple est définie comme étant "indefinite" (car un attribut end est spécifié sans attribut dur) et, de ce fait, le conteneur de temps joue normalement jusqu'à la fin de ses 12 secondes.

<smil ...>
...
<par end="foo.activateEvent" min="12s" >
   <video id="video_of_15s" .../>
   <video id="video_of_10s" .../>
</par>
...
</smil>

Exemple 4. Dans l'exemple suivant, si l'on clique sur la première vidéo à 5 secondes, alors la durée simple du conteneur de temps est calculée comme étant de 5 secondes. D'après l'attribut fill pendant le temps qui sépare la fin de la durée simple et la fin de la durée active, les deux vidéos sont gelées entre 5 et 12 secondes.

<html ...>
...
<par endsync="first" min="12s" fill="freeze" >
   <video id="video_of_15s" end="click" ...>
   <video id="video_of_10s" .../>
</par>
...
</html>

Exemple 5. Dans l'exemple suivant, le conteneur de temps a une durée simple de 5 secondes et la contrainte de min définit la durée active comme étant de 12 secondes. Comme la valeur par défaut pour l'attribut fill est, dans ce cas, "remove", rien n'est affiché dans le conteneur de temps entre les secondes 5 et 12.

<par dur="5s" min="12s" >
   <video id="video_of_15s"/>
   <video id="video_of_10s" />
</par>
L'attribut min et les temps de début négatifs

Si un élément est défini pour commencer avant son parent (par exemple, avec une valeur de décalage négative simple), la durée de min est mesurée en fonction du temps de début calculé et pas le début observé (voir exemple 1 ci-dessous). Cela signifie que la valeur de min peut ne pas avoir d'effet observable (comme dans l'exemple 2 ci-dessous).

Exemple 1. Dans l'exemple suivant, l'image sera affichée à partir du début du conteneur de temps pendant 2 secondes.

<par> 
   <img id="img" begin="-5s" min="7s" dur="5s" .../>
</par>

Exemple 2. Dans l'exemple suivant, l'image ne sera pas affichée du tout.

<par>
   <img id="img" begin="-5s" min="4s" dur="2s" .../>
</par>

Voir aussi les sections « L'attribut min et la répétition » et « Les contraintes du conteneur de temps sur les durées des enfants ».

Les grammaires des valeurs des attributs de temporisation

Cette section est normative.

Les spécifications de la syntaxe sont définies en utilisant la notation EBNF comme défini dans [XML10].

Dans les spécifications de syntaxe qui suivent, les espaces blancs autorisés sont indiqués par un « S », défini comme suit (définition de « S » issue de [XML10]) :

S ::= (#x20 | #x9 | #xD | #xA)+
Les valeurs de begin

Cette section est normative.

Une valeur begin-value-list est une liste de spécifiants de temporisation séparés par des points-virgules :

begin-value-list ::= begin-value (S? ";" S? begin-value-list )?
begin-value	 ::= (offset-value | syncbase-value 
		      | event-value | repeat-value | accesskey-value
		      | media-marker-value | wallclock-sync-value
		      | "indefinite" )
Les valeurs de end

Cette section est normative.

Une valeur end-value-list est une liste de spécifiants de temporisation séparés par des points-virgules :

end-value-list ::= end-value (S? ";" S? end-value-list )?
end-value      ::= (offset-value | syncbase-value 
		      | event-value | repeat-value | accesskey-value
		      | media-marker-value | wallclock-sync-value
		      | "indefinite" )
L'analyse des spécifiants de temporisation

Plusieurs des valeurs de spécification de temporisation ont une syntaxe similaire. Pour l'analyse d'un élément individuel dans une liste de valeurs, une interprétation correcte est définie par l'approche suivante. De plus, les types Id-value et Event-symbol sont des valeurs NMTOKEN XML et, en tant que telles, peuvent contenir les caractères point « . » et tiret « - ». Le caractère barre oblique inverse « \ » doit être utilisé pour masquer ces deux caractères dans les valeurs Id-value et Event-symbol, sinon ceux-ci seront interprétés, respectivement, comme un séparateur et le signe de soustraction. Une fois ces règles interprétées, mais avant que les valeurs Id-value dans les valeurs de base de synchronisation, les valeurs d'événement ou les valeurs de marqueur de média ne soient prises en charge plus avant, tous les caractères d'échappement, ceux de têtre ou ceux incorporés, devraient être supprimés

  1. Supprimer tous les caractères blancs de tête, de queue ou intermédiaires ;
  2. Si la valeur commence par un nombre ou un indicateur de signe numérique (i.e., un « + » ou un « - », la valeur doit être interprétée comme la valeur d'un décalage ;
  3. Sinon, si la valeur commence par l'atome non masqué "wallclock", elle devrait être interprétée comme une valeur wallclock-sync-value ;
  4. Sinon, si la valeur commence par l'atome non masqué "indefinite", elle devrait être interprétée comme étant la valeur "indefinite" ;
  5. Sinon : construire une sous-chaîne d'atome jusqu'à l'indicateur de signe, sans l'inclure (i.e., retirer tout décalage, l'analyser séparément puis l'inclure au résultat de cette étape). Dans la suite, aucun caractère point « . », précédé du caractère d'échappement barre oblique inverse « \ », ne doit être traité comme un séparateur, mais comme un caractère d'atome normal.
    1. Si l'atome ne contient aucun séparateur « . », alors la valeur doit être interprétée comme une valeur event-value avec un élément de base d'événement non spécifié (i.e., par défaut) ;
    2. Sinon, si l'atome se termine par les chaînes non masquées ".begin" ou ".end", alors la valeur devrait être interprétée comme une valeur syncbase-value ;
    3. Sinon, si l'atome contient la chaîne non masquée ".marker(", alors la valeur devrait être interprétée comme une valeur media-marker-value ;
    4. Sinon, la valeur devrait être interprétée comme une valeur event-value (avec un événement de base d'événement spécifié).

Cette façon de faire permet aux implémentations de traiter les atomes wallclock et indefinite comme des ID d'élément réservés, et begin, end et marker comme des noms d'événement réservés, tout en conservant un mécanisme d'échappement pour que les éléments et événements avec ces noms puissent être appelés.

Les valeurs d'horloge

Les valeur d'horloge ont la syntaxe suivante :

Clock-value	 ::= ( Full-clock-value | Partial-clock-value | Timecount-value )
Full-clock-value    ::= Hours ":" Minutes ":" Seconds ("." Fraction)?
Partial-clock-value ::= Minutes ":" Seconds ("." Fraction)?
Timecount-value     ::= Timecount ("." Fraction)? (Metric)?
Metric		    ::= "h" | "min" | "s" | "ms"
Hours		    ::= DIGIT+; any positive number
Minutes 	    ::= 2DIGIT; range from 00 to 59
Seconds 	    ::= 2DIGIT; range from 00 to 59
Fraction		::= DIGIT+
Timecount	    ::= DIGIT+
2DIGIT			  ::= DIGIT DIGIT
DIGIT			     ::= [0-9]

Pour les valeurs de Timecount, le suffixe métrique par défaut est "s" (pour secondes) Aucun caractère blanc de séparation n'est autorisé dans les valeurs d'horloge même si les caractères blancs de tête et de queue seront ignorés.

Voici quelques exemples de valeurs d'horloge valides :

Les valeurs fractionnaires sont simplement des valeurs décimales en secondes (base 10) . Le nombre de chiffres après la virgule est illimité (bien qu'en réalité la précision varie d'une implémentation à l'autre).
Par exemple :

00.5s = 500 millisecondes
00:00.005 = 5 millisecondes
Les valeurs de décalage

Les valeurs de décalage servent à spécifier quand un élément devrait commencer ou finir par rapport à sa base de synchronisation.

Cette section est normative.

Une valeur de décalage a la syntaxe suivante :

offset-value   ::= (( S? "+" | "-" S? )? ( Clock-value )

La base de synchronisation implicite pour une valeur de décalage dépend du conteneur de temps :

Les valeurs de begin et de end de SMIL 1.0 

Déprécié.

smil-1-syncbase-value  ::= "id(" Id-value ")" 
			   ( "(" ( "begin" | "end" | Clock-value) ")" )?
Les valeurs de référence d'ID

Cette section est normative.

Les valeurs ID-reference sont des références à la valeur d'un attribut "id" d'un autre élément dans le document.

Id-value			::= Id-ref-value
Id-ref-value		 ::= IDREF | Escaped-Id-ref-value
Escaped-Id-ref-value	 ::= Escape-Char NMTOKEN
Escape-Char		::= "\"

Si l'élément référencé par IDREF est ignoré, comme décrit dans les modules de contrôle de contenu (par exemple, s'il spécifie un attribut de test évalué à "false" ), la valeur de temps associée (i.e., la valeur de base de synchronisation, ou de base d'événement, qui spécifie l'Id-value) sera considérée non valide.

Cette section est informative.

Les sémantiques des éléments ignorés pourraient changer dans les futures versions de SMIL. Une sémantique possible serait que les arguments des arcs de synchronisation associés ne seront pas non valides, mais plutôt toujours « non résolus ». Quand ce comportement a besoin d'être simulé dans cette version de la temporisation et de la synchronisation de SMIL, un auteur peut ajouter la valeur "indefinite" dans la liste des valeurs pour les attributs begin et end.

Les valeurs de base de synchronisation

Une valeur de base de synchronisation commence par un terme Syncbase-element définissant la valeur d'un attribut "id" d'un autre élément, appelé élément de base de synchronisation.

Cette section est normative.

Une valeur de base de synchronisation a la syntaxe suivante :

 Syncbase-value   ::= ( Syncbase-element "." Time-symbol )
                      ( S? ("+"|"-") S? Clock-value )? 
 Syncbase-element ::= Id-value
 Time-symbol      ::= "begin" | "end"

L'élément de base de synchronisation est qualifié par l'un des symboles de temps suivants :

begin
Spécifie le début de l'élément de base de synchronisation.
end
Spécifie la fin active de l'élément de base de synchronisation.

Exemples

  begin="x.end-5s"        : Commence 5 secondes avant la fin de "x"
  begin=" x.begin "       : Commence quand "x" commence
  end="x.begin + 1min"    : Fini 1 minute après que "x" a commencé

Les valeurs d'événement

Cette section est informative.

Une valeur d'événement commence par un terme Eventbase-element qui spécifie l'élément de base d'événement. L'élément de base d'événement est celui sur lequel l'événement est observé. D'après le DOM, l'élément de base d'événement peut être soit l'élément qui déclenche l'événement, soit un ancêtre de l'élément sur lequel l'événement qui a bouillonné peut être observé. Voir DOM-Level2-Events [DOM2Events] pour plus de détails.

Cette section est normative.

Une valeur d'événement a la syntaxe suivante :

  Event-value       ::= ( Eventbase-element "." )? Event-symbol 
                        ( S? ("+"|"-") S? Clock-value )? 
  Eventbase-element ::= ID

L'élément de base d'événement doit être un autre élément contenu dans le document hôte.

Si le terme Eventbase-element est manquant, l'élément de base d'événement est, par défaut, l'élément sur lequel la temporisation de base d'événement est spécifiée (i.e., l'élément courant).

La valeur d'événement doit spécifier un terme Event-symbol. Ce terme est un NMTOKEN XML qui spécifie le nom de l'événement déclenché par l'élément de base d'événement.   Le concepteur du langage hôte doit spécifier les événements pouvant être spécifiés.

Le dernier terme spécifie une valeur de décalage optionnelle qui est un décalage à partir du temps de l'événement.

Cette section est informative.

Si aucune disposition n'est associée à l'élément de base d'événement (par exemple, un conteneur de temps dans SMIL), alors certains événements de l'interface utilisateur peuvent ne pas être définis (par exemple, les événements de souris). Un concepteur de langage hôte peut surclasser la définition de l'élément de base d'événement par défaut. À titre d'exemple, les éléments d'animation de SMIL (animate, animateMotion, etc.) spécifient que l'élément de base d'événement par défaut est l'élément cible de l'animation. Voir aussi l'animation dans SMIL.

Ce module définit plusieurs événements qui peuvent être inclus dans l'ensemble de ceux gérés par un langage hôte, avec notamment beginEvent et endEvent. Ceux-ci ne doivent pas être confondus avec les valeurs de temps de base de synchronisation. Voir la section « Les événements et le modèle d'événement ».

La sémantique de la temporisation basée sur les événements est détaillée dans « La consolidation de la temporisation basée sur les événements et de la temporisation planifiée ». Les contraintes sur la sensibilité des événements sont détaillées dans « La sensibilité des événements ».

Exemples :

 begin=" x.load "        : Commence quand "load" est observé sur "x"
 begin="x.focus+3s"      : Commence 3 secondes après un événement "focus" sur "x"
 begin="x.endEvent+1.5s" : Commence 1 seconde et demi après un événement "endEvent" sur "x"
 begin="x.repeat"        : Commence chaque fois qu'un événement repeat est observé sur "x"

L'exemple suivant montre le fonctionnement de la valeur de base d'événement repeat :

<html ...>
...
<video id="foo" repeatCount="10" end="endVideo.click" ... />
<img id="endVideo" begin="foo.repeat(2)" .../>
...
</html>

L'image "endVideo" sera affichée quand la vidéo "foo" se répétera pour la deuxième fois. Cet exemple permet à l'utilisateur d'arrêter la vidéo après qu'elle a été jouée au moins deux fois.

Les valeurs de répétition

Les valeurs de répétition sont une variante des valeurs d'événement qui gèrent un événement de répétition qualifié. L'événement repeat, défini dans « Les événements et le modèle d'événement », admet un suffixe supplémentaire pour qualifier un événement en fonction d'une valeur d'itération.

Une valeur de répétition a la syntaxe suivante :

  Repeat-value       ::= ( Eventbase-element "." )? "repeat(" iteration ")"
                        ( S? ("+"|"-") S? Clock-value )? 
  iteration        ::= DIGIT+ 

Si cette structure qualifiée est utilisée, la valeur de base d'événement ne sera résolue que quand on observera une répétition dont la valeur d'itération corresponde à l'itération spécifiée.

La syntaxe qualifiée de l'événement repeat permet à l'auteur de ne traiter qu'une répétition individuelle d'un élément.

Les valeurs de clé d'accès

Les valeurs de clé d'accès permettent à un auteur d'associer un temps de début ou de fin à une touche particulière, indépendamment des questions de focus. Le fonctionnement est calqué sur la gestion de l'attribut accesskey de HTML. Contrairement à HTML, les agents utilisateurs ne devraient pas requérir qu'une touche modificatrice (telle que « ALT ») soit nécessaire pour activer le fonctionnement d'une clé d'accès.

Une clé d'accès a la syntaxe suivante :

  Accesskey-value  ::= "accesskey(" caractère ")"
                       ( S? ("+"|"-") S? Clock-value )? 

Le caractère est un seul caractère de la norme [ISO10646].

La valeur de temps est définie comme étant le moment où le caractère de la clé d'accès est entré par l'utilisateur.

Les valeurs de marqueur de média

Certains types de médias peuvent utiliser des valeurs de marqueur qui associent un nom à un point particulier (i.e., un temps) du média. La valeur de marqueur de média permet de définir un temps de début ou de fin en en fonction de ces valeurs de marqueur. Notez que si l'id référencé n'est pas associé à un média qui gère les marqueurs, ou si le nom de marqueur spécifié n'est pas défini par l'élément média, le temps correspondant peut ne jamais être résolu.

Cette section est normative.

 Media-Marker-value ::= Id-value ".marker(" S? marker-name S? ")"

Les valeurs de synchronisation avec le temps réel

Cette section est informative.

Les valeurs de synchronisation avec le temps réel ont la syntaxe suivante. Les valeurs autorisée sont basées sur plusieurs des « profils » décrits dans [DATETIME], qui se base sur la norme [ISO8601].

Cette section est normative.

wallclock-sync-value  ::= "wallclock(" S? (DateTime | WallTime | Date)  S? ")"
DateTime       ::= Date "T" WallTime
Date	       ::= Years "-" Months "-" Days
WallTime       ::= (HHMM-Time | HHMMSS-Time)(TZD)?
HHMM-Time      ::= Hours24 ":" Minutes
HHMMSS-Time    ::= Hours24 ":" Minutes ":" Seconds ("." Fraction)?
Years	       ::= 4DIGIT;
Months	       ::= 2DIGIT; intervalle de 01 à 12
Days	       ::= 2DIGIT; intervalle de 01 à 31
Hours24        ::= 2DIGIT; intervalle de 00 à 23
4DIGIT	       ::= DIGIT DIGIT DIGIT DIGIT
TZD	       ::= "Z" | (("+" | "-") Hours24 ":" Minutes )

Cette section est informative.

Date complète  avec heures et minutes :

   YYYY-MM-DDThh:mmTZD (e.g., 1997-07-16T19:20+01:00)

Date complète  avec heures, minutes et secondes :

   YYYY-MM-DDThh:mm:ssTZD (e.g., 1997-07-16T19:20:30+01:00)

Date complète  avec heures, minutes, secondes et fraction décimale de seconde :

   YYYY-MM-DDThh:mm:ss.sTZD (e.g., 1997-07-16T19:20:30.45+01:00)

Notez que la syntaxe pour les valeurs Minutes, Seconds, Fraction, 2DIGIT DIGIT est définie comme pour les valeurs Clock-value. Notez qu'aucun caractère de séparation n'est autorisé dans la spécification de date et d'heure.

Cette section est normative.

Il y a trois façons de gérer les décalages de fuseau horaire :

  1. Les heures sont exprimées en UTC (Temps Universel Coordonné), avec un indicateur spécial pour UTC ("Z") ;
  2. Les heures sont exprimées dans le temps local, accompagnées d'un décalage de fuseau horaire en heures et minutes. Un décalage de fuseau horaire de "+hh:mm" indique que la date/heure utilise un fuseau horaire qui est en avance de "hh" heures et "mm" minutes sur l'heure UTC. Un décalage de fuseau horaire de "-hh:mm" indique que la date/heure utilise un fuseau horaire qui est en retard de "hh" heures et "mm" minutes sur l'heure UTC ;
  3. Les heures sont exprimées dans le temps local, comme cela est défini pour le lieu où se trouve la présentation. Le fuseau horaire local de la plateforme de l'utilisateur est utilisé.

Le moteur de la présentation doit être capable de transformer les valeurs de temps réel dans le temps de la présentation.

Cette section est informative.

Notez que le début ou la fin obtenus peuvent se trouver avant le début ou après la fin du conteneur de temps parent. Ceci n'est pas une erreur, mais les contraintes du conteneur de temps sont toujours appliquées. Dans tous les cas, la sémantique des attributs begin et end dicte l'interprétation de la valeur de temps réel.

Exemples

Les exemples suivants spécifient tous un début à minuit, le 1 janvier 2000, UTC

begin="wallclock(2000-01-01Z)"
begin="wallclock( 2000-01-01T00:00Z )"
begin="wallclock( 2000-01-01T00:00:00Z )"
begin="wallclock( 2000-01-01T00:00:00.0Z )"
begin="wallclock( 2000-01-01T00:00:00.0Z )"
begin="wallclock( 2000-01-01T00:00:00.0-00:00 )"

L'exemple suivant spécifie un début à 15:30, le 28 juillet 1990, dans le fuseau horaire de la côte ouest des USA :

begin="wallclock( 1990-07-28T15:30-08:00 )"

L'exemple suivant spécifie un début à 8:00, où que soit présenté le document :

begin="wallclock( 08:00 )"

L'attribut endsync

Cette section est normative.

L'attribut endsync contrôle la durée implicite des conteneurs de temps en fonction des enfants. L'attribut endsync n'est valide que pour les éléments conteneurs de temps par et excl et les éléments médias ayant des enfants temporisés (par exemple, des éléments animate ou area). Les langages hôtes peuvent autoriser l'attribut endsync avec n'importe quel élément ayant une sémantique de conteneur de temps. L'attribut endsync est particulièrement pratique avec des enfants ayant une durée « inconnue », par exemple un film MPEG qui doit être joué avant de pouvoir déterminer sa durée, ou des éléments dont la fin est basée sur un événement.

endsync = " first | last | all | media | Id-value | smil1.0-Id-value"
Les valeurs autorisée pour l'attribut sont :
first
La durée implicite de par, excl, ou de l'élément média se termine en même temps que la fin active la plus précoce d'entre tous les éléments enfants. Cela ne se rapporte pas au premier enfant au sens lexical ni au premier enfant à démarrer, mais plutôt au premier enfant terminant sa (première) durée active.
last
La durée implicite de par, excl, ou de l'élément média se termine en même temps que la dernière fin active d'entre tous les éléments enfants. Cela ne se rapporte pas au dernier enfant au sens lexical ni au dernier enfant à démarrer, mais plutôt à la dernière fin active définie et résolue d'entre tous les enfants. Si le conteneur de temps n'a aucun enfant avec un temps de début résolu, le conteneur se termine tout de suite. Si les éléments enfants ont plusieurs temps de début, ou bien redémarrent, les éléments enfants doivent achever toutes les instances de leurs durées actives pour les temps de début résolus. Ceci est la valeur par défaut pour les éléments par et excl.
all
La durée implicite de par, excl, ou de l'élément média se termine quand tous les éléments enfants ont terminé leurs durées actives respectives. Les éléments ayant un début indéfini, ou non résolu, empêcheront la durée simple du conteneur de temps de se terminer.
Quand tous les éléments auront terminé leurs durées actives, une ou plusieurs fois, le conteneur de temps parent pourra se terminer.
media
La durée implicite de l'élément conteneur de temps se termine quand la durée intrinsèque du média se termine. Cela doit être défini par le langage hôte. Si l'élément conteneur de temps ne définit pas de durée intrinsèque de média, le langage hôte doit définir la durée simple de l'élément.
C'est la valeur par défaut pour les éléments médias conteneurs de temps.
Id-value
La durée implicite de par, excl, ou de l'élément média se termine quand l'enfant spécifié termine sa (première) durée active. L'id doit correspondre à l'un des enfants temporisés immédiats du conteneur de temps.
smil1.0-Id-value
Il s'agit d'une valeur d'identifiant de SMIL 1.0 de la forme "id(" IDREF ")". La sémantique est identique à celle de la valeur Id-value juste au-dessus. Cette syntaxe est dépréciée.

Sémantique de endsync avec dur et end :

Sémantique de endsync et la répétition :

Sémantique de endsync et des éléments en pause :

Cette section est informative.

Sémantique de endsync et les temps non résolus des enfants :

Cette section est normative.

Le pseudo-code suivant décrit l'algorithme de endsync :

// 
// boolean timeContainerHasEnded()
//
// method on time containers called to evaluate whether
// time container has ended, according to the rules of endsync.
// Note: Only supported on par and excl
//
// A variant on this could be called when a child end is updated to
// create a scheduled (predicted) end time for the container.
//
// Note that we never check the end time of children - it doesn't matter.
//
// Assumes: 
//     child list is stable during evaluation
//     isActive state of children is up to date for current time.
//	[In practice, this means that the children must all be
//	  pre-visited at the current time to see if they are done.
//	  If the time container is done, and repeats, the children
//	  may be resampled at the modified time.]
//
//   Uses interfaces: 
//   on TimedNode:
//     isActive()	      tests if node is currently active
//     hasStarted()	      tests if node has (ever) begun
//     begin and end	      begin and end TimeValues of node
//
//   on TimeValue	  (a list of times for begin or end)
//   is Resolved(t)	     true if there is a resolved time
//				       at or after time t
//

boolean timeContainerHasEnded()
{

TimeInstant now = getCurrentTime(); // normalized for time container

boolean assumedResult;

// For first or ID, we assume a false result unless we find a child that has ended
// For last and all, we assume a true result unless we find a disqualifying child

if( ( endsyncRule == first ) || ( endsyncRule == ID ) )
   assumedResult = false;
else
   assumedResult = true;

// Our interpretation of endsync == all:
//	    we're done when all children have begun, and none is active
//

// loop on each child in collection of timed children,
//  and consider it in terms of the endsyncRule

 foreach ( child c in timed-children-collection )
{
   switch( endsyncRule ) {
      case first:
	 // as soon as we find an ended child, return true.
	 if( c.hasStarted() & !c.isActive() )
	    return true;
	 // else, keep looking (assumedResult is false)
	 break;

      case ID:
	 // if we find the matching child, just return result
	 if( endsyncID == c.ID )
		 return( c.hasStarted() & !c.isActive() );
	 // else, keep looking (we'll assume the ID is valid)
	 break;

      case last:
	 // we just test for disqualifying children
	 // If the child is active, we're definitely not done.
	 // If the child has not yet begun but has a resolved begin,
	 // then we're not done.
	 if( c.isActive()
	     || c.begin.isResolved(now) )
	     return false;
	 // else, keep checking (the assumed result is true)
	 break;

      case all:
	 // we just test for disqualifying children
	// all_means_last_done_after_all_begin

	 // If the child is active, we're definitely not done.
	 // If the child has not yet begun then we're not done. 
	 // Note that if it has already begun,
	 // then we still have to wait for any more resolved begins
	 if( c.isActive() || !c.hasStarted()
	     || c.begin.isResolved(now) )
	     return false;
	 // else, keep checking (the assumed result is true)
	 break;

   } // close switch

} // close foreach loop

return assumedResult;

} // close timeContainerHasEnded()

Les attributs repeatCount, repeatDur et repeat : les éléments de répétition

Cette section est informative.

SMIL 1.0 a introduit l'attribut repeat qui est utilisé pour répéter un élément média ou tout un conteneur de temps. SMIL 2.0 introduit deux nouveau attributs pour contrôler les fonctionnalités de répétition qui supplantent l'attribut repeat de SMIL 1.0. Les nouveaux attributs repeatCount et repeatDur fournissent une sémantique qui correspond mieux aux cas d'utilisation typiques et offrent un meilleur contrôle de la durée des répétitions.

Répéter un élément implique que la durée simple soit « jouée » plusieurs fois à la suite. Cela va effectivement copier ou faire tourner en boucle le contenu de l'élément média (ou le plan de montage chronologique entier dans le cas d'un conteneur de temps). L'auteur peut spécifier soit combien de fois répéter, en utilisant repeatCount, soit combien de temps répéter, en utilisant repeatDur. Chaque itération de la répétition est une instance de « lecture » de la durée simple.

Cette section est normative.

repeatCount
Spécifie le nombre d'itérations de la durée simple. Cet attribut peut avoir les valeurs suivantes :
valeur numérique
C'est une valeur numérique décimale (base 10) qui spécifie le nombre d'itérations. Cela peut être des itérations partielles exprimées en valeurs fractionnaires. Une valeur fractionnaire décrit un morceau de durée simple. Les valeurs doivent être supérieures à 0.
"indefinite"
L'élément est défini pour se répéter indéfiniment (soumis aux contraintes du conteneur de temps parent).
repeatDur
Spécifie la durée totale de la répétition. Cet attribut peut avoir les valeurs suivantes :
Clock-value
Spécifie la durée, dans le temps actif de l'élément, pendant laquelle il faut répéter la durée simple.
"indefinite"
L'élément est défini pour se répéter indéfiniment (soumis aux contraintes du conteneur de temps parent).
Exemples

Dans l'exemple suivant, la durée implicite du son est contrainte par l'attribut repeatCount. Seule la première moitié de la séquence sera jouée ; la durée active sera de 1.5 secondes.

<audio src="3second_sound.au" repeatCount="0.5" /> 

Dans cet exemple, la durée (implicite) simple de 3 secondes sera jouée trois fois et ensuite sera contrainte par l'attribut dur du conteneur de temps parent par ; la durée active sera de 9 secondes.

<par dur="9s">
   <audio src="3second_sound.au" repeatCount="100" />
</par> 

Dans l'exemple suivant, la durée simple de 2.5 secondes sera répétée deux fois ; la durée active sera de 5 secondes.

<audio src="background.au" dur="2.5s" repeatCount="2" />

Dans l'exemple suivant, la durée (implicite) simple de 3 secondes sera répétée deux fois entièrement et la première moitié sera encore jouée une fois ; la durée active sera de 7.5 secondes.

<audio src="3second_sound.au" repeatCount="2.5" />

Dans l'exemple suivant, le son va se répéter pendant 7 secondes. Il sera joué entièrement 2 fois puis sera lu partiellement pendant 2 secondes. Cela est équivalent à un attribut repeatCount avec une valeur de 2.8.

<audio src="music.mp3" dur="2.5s" repeatDur="7s" />

Notez que si la durée simple est indéfinie, le comportement de répétition n'est pas défini (mais repeatDur participe toujours à la durée active). Dans l'exemple suivant, la durée simple est respectivement de 0 et indéfinie, et donc le repeatCount est ignoré. Néanmoins, cela n'est pas considéré comme une erreur. La durée active est égale à la durée simple : pour le premier élément la durée active vaut 0 et pour le second, elle est indéfinie.

<img src="foo.jpg" repeatCount="2" />
<img src="bar.png" dur="indefinite" repeatCount="2" />

Dans l'exemple suivant, la durée simple vaut 0 pour l'image et est indéfinie pour l'élément de texte, de ce fait, le comportement de répétition n'est pas significatif. La durée active vaut 0 pour le premier élément, mais pour le second, le durée active est déterminée par la valeur de repeatDur, elle est donc de 10 secondes. L'effet est que le texte est affiché pendant 10 secondes.

<img src="foo.jpg" repeatDur="10s" />
<text src="intro.html" dur="indefinite" repeatDur="10s" />

Dans l'exemple suivant, si le média audio dure plus que les 5 secondes de repeatDur, alors la durée active écourtera la durée simple.

<audio src="8second_sound.au" repeatDur="5s" />

Les attributs repeatCount et repeatDur peuvent aussi être utilisés pour répéter un plan de montage chronologique complet (i.e., la durée simple d'un conteneur de temps), comme dans l'exemple suivant. La séquence à une durée implicite simple de 13 secondes. Elle va commencer à jouer après 5 secondes et ensuite répétera trois fois la série de trois images. La durée active est donc de 39 secondes.

<seq begin="5s" repeatCount="3" >
   <img src="img1.jpg" dur="5s" />
   <img src="img2.jpg" dur="4s" />
   <img src="img3.jpg" dur="4s" />
</seq>
L'attribut min et la répétition :

L'attribut min n'empêche pas qu'un élément ne redémarre avant d'avoir atteint la durée minimum active. Si dans l'exemple suivant le "user.activateEvent" se produit une fois à 2 secondes, puis encore une fois à 5 secondes, l'élément "image" va commencer à 2 secondes, puis être joué pendant 3 secondes, enfin redémarrer à 5 secondes. L'intervalle redémarré ( commençant à 5 secondes) va faire s'afficher l'image jusqu'à la seconde 12.

<smil ...>
...
<par>
   <img id="image" begin="user.activateEvent" min="7s" dur="5s" 
	restart="always" fill="freeze".../>
</par>
...
</smil>
Le repeat de SMIL 1.0 ( déprécié )

L'attribut repeat de SMIL 1.0 se comporte de manière similaire à repeatCount, mais celui-ci définit la fonctionnalité comme une séquence contenant le nombre spécifié de copies de l'élément sans l'attribut repeat. Cette définition a entraîné des confusions parmi les auteurs et les implémenteurs. Voir aussi la spécification de [SMIL10].

En particulier, il y a eu confusion concernant le comportement de l'attribut end de SMIL 1.0, lorsqu'il était utilisé en association avec l'attribut repeat. SMIL 2.0 se conforme à l'usage répandu qui veut que l'attribut end définisse la durée simple de l'élément quand l'attribut déprécié repeat est utilisé. Seuls les agents utilisateurs de documents SMIL doivent gérer cette sémantique pour l'attribut end. Une seule « end » de SMIL 1.0 (i.e., une valeur offset-value ou smil-1.0-syncbase-value, mais aucune issue de la temporisation de SMIL 2.0), est autorisée lors de l'utilisation de l'attribut déprécié repeat. Si repeat est utilisé avec repeatCount ou repeatDur sur un élément, ou si repeat est utilisé avec une valeur non autorisée pour end, la valeur de repeat est ignorée.

Cette section est normative.

repeat
Cet attribut est déprécié dans SMIL 2.0 en faveur des nouveaux attributs repeatCount et repeatDur.
Cela a pour effet de faire jouer successivement l'élément le nombre de fois spécifié. Ceci est équivalent à un élément seq avec le nombre déclaré de copies de l'élément sans attribut repeat comme enfants. Tous les autres attributs de l'élément, y compris les délais de début, étant inclus dans les copies.
Les valeurs autorisées sont un nombre entier d'itérations supérieur à 0 et "indefinite".

L'attribut fill : la prolongation d'un élément

Cette section est informative.

Quand la durée active d'un élément se termine, il peut être gelé dans son état final, ou ne plus être présenté (i.e., être retiré de la présentation). Geler un élément le prolonge, en utilisant l'état final de la dernière instance de sa durée simple. Cela peut servir à combler des trous dans la présentation ou étendre un élément comme contexte pour la présentation (par exemple, avec une animation supplémentaire - voir [SMIL-ANIMATION]).

Cette section est normative

L'attribut fill permet à un auteur de de spécifier qu'un élément devrait être prolongé au-delà de sa durée active en gelant son état final. L'attribut fill est aussi utilisé pour déterminer le comportement d'un élément quand sa durée active est inférieure à la durée définie par l'attribut min. C'est pour cette raison, plutôt que de parler de fin de durée active, la spécification s'y réfère comme à « la dernière instance de la durée simple ».

La syntaxe de l'attribut fill est la même que dans SMIL 1.0, avec deux prolongements. De surcroît, l'attribut fill peut maintenant s'appliquer à n'importe quel élément temporisé, y compris les conteneurs de temps.

fill = ( remove | freeze | hold | transition | auto | default )
Cet attribut peut avoir les valeurs suivantes :
remove
Spécifie que l'élément ne sera pas prolongé au-delà de la fin de la dernière instance de sa durée simple.
freeze
Spécifie que l'élément sera prolongé au-delà de la fin de la dernière instance de sa durée simple en « gelant » l'état de l'élément à ce point. Le conteneur de temps parent de l'élément détermine combien de temps l'élément sera gelé (comme décrit ci-après).
hold
Utiliser cette valeur revient au même que d'utiliser "freeze", sauf que l'élément est toujours gelé jusqu'à la fin de la durée simple de l'élément conteneur parent (indépendamment du type de conteneur de temps). Pour les profils qui gèrent un modèle de disposition en couches (par exemple le profil de langage de SMIL 2.0), les éléments en suspens (les éléments avec fill=hold) rafraîchiront la zone d'affichage lorsqu'une couche est appliquée par-dessus, puis retirée.
transition
Utiliser cette valeur revient au même que d'utiliser "freeze", sauf que l'élément est retiré à la fin de la transition. Cette valeur n'est permise que pour les éléments directement associés à des médias. Si cette valeur est spécifiée dans n'importe quel autre élément (comme, par exemple, les conteneurs de temps des profils de langage de SMIL 2.0 ), il sera ignoré. Voir aussi « Le module des effets de transition de SMIL 2.0 ».
auto
Le comportement de remplissage de l'élément dépend du fait qu'il spécifie, ou non, l'un des attributs définissant une durée simple ou active :
  • Si aucun des attributs dur, end, repeatCount ou repeatDur n'est spécifié pour l'élément, alors celui-ci se comportera comme si l'attribut fill avait pour valeur "freeze" ;
  • Sinon l'élément se comportera comme si l'attribut fill avait pour valeur "remove".
default
Le comportement de remplissage de l'élément est déterminé par la valeur de l'attribut fillDefault.
Ceci est la valeur par défaut.
Si l'application de l'attribut fillDefault sur un élément entraîne une valeur non autorisée pour cet élément, alors il se comportera comme si l'attribut fill avait pour valeur "auto".

Notez que, étant données les valeurs par défaut pour les attributs fill et fillDefault, si l'attribut fill n'est pas spécifié pour un élément, et si l'attribut fillDefault n'est spécifié pour aucun ascendant de l'élément, le comportement de remplissage suivra la sémantique de "auto".

Un élément avec un comportement de remplissage "freeze" est prolongé en fonction du conteneur de temps parent :

Quand il est appliqué à un média, l'attribut fill n'a d'effet que sur les médias visuels. Les médias non-visuels (audio) seront simplement silencieux (bien qu'ils soient quand même gelés du point de vue de la temporisation).

L'attribut fillDefault

Cette section est normative.

fillDefault = ( remove | freeze | hold | transition | auto | inherit )
Définit la valeur par défaut pour le comportement de fill pour un élément et tous ses descendants.
Les valeurs "remove", "freeze", "hold", "transition" et "auto" spécifient que le comportement de fill pour l'élément correspond respectivement à la valeur.
inherit
Spécifie que la valeur de cet attribut (et son comportement de remplissage) est héritée de la valeur fillDefault de son élément parent. S'il n'y a pas d'élément parent, la valeur est "auto".
C'est la valeur par défaut.
La sensibilité des événements et l'attribut fill

Les effets de l'attribut fill ne s'appliquent qu'à la sémantique de temporisation. Si un élément est encore visible alors qu'il est gelé, il se comporte normalement par rapport aux autres sémantiques, tel que le traitement d'un événement de l'utilisateur. En particulier, les éléments tels que a et area restent sensibles à une activation par l'utilisateur (par exemple, un clic) quand ils sont gelés. Voir aussi la spécification de SMIL 1.0 [SMIL10].

Cette section est informative.

L'attribut fill peut être utilisé pour conserver la valeur d'un élément média après la fin de sa durée active :

<par endsync="last">
   <video src="intro.mpg" begin= "5s" dur="30s" fill="freeze" />
   <audio src="intro.au"  begin= "2s" dur="40s"/>
</par>

L'élément vidéo se termine 35 secondes après le début de son conteneur de temps, mais sa dernière image reste affichée jusqu'à la fin de l'élément audio. L'attribut « gèle » la dernière valeur de l'élément pour le reste de la durée simple du conteneur de temps.

Cette fonctionnalité est aussi pratique pour conserver l'élément affiché pendant que le suivant, dans un élément seq, se prépare à être affiché, comme dans cet exemple :

<seq>
   <video id="v1" fill="freeze" src.../>
   <video id="v2" begin="2s" src.../>
</seq>

La première vidéo est affichée et ensuite gelée pendant 2 secondes, jusqu'à ce que l'élément suivant commence. Notez que si le téléchargement ou la mise en mémoire tampon de "v2" prend plus de 2 secondes, "v1" restera quand même gelé jusqu'à ce que "v2" démarre effectivement.

L'attribut restart

Cette section est informative.

Notez qu'il existe plusieurs facons de redémarrer un élément. Le comportement (i.e., redémarrer ou non) est dans tous les cas contrôlé par l'attribut restart. Les différents cas de redémarrage sont :

Comme pour n'importe quel temps de début, si un élément est planifié pour redémarrer après la fin de durée simple de son conteneur de temps parent, il ne redémarrera pas.

Cette section est normative.

restart = "always | whenNotActive | never | default"

always
L'élément peut être redémarré n'importe quand.
whenNotActive
L'élément ne peut être redémarré que s'il est inactif (i.e., il peut être redémarré après sa fin active). Les tentatives pour redémarrer l'élément pendant sa durée active sont ignorées.
never
L'élément ne peut pas être redémarré pour tout le reste de la durée simple du conteneur de temps parent.
default
Le comportement de redémarrage de l'élément est déterminé par la valeur de l'attribut restartDefault.
C'est la valeur par défaut.

L'attribut restartDefault peut être utilisé pour contrôler le comportement par défaut de l'attribut restart. Ceci est décrit ci-dessous dans la section « Le contrôle du comportement par défaut de restart ».

Pour avoir des détails sur le moment et la façon dont l'attribut restart est évalué, voir « L'évaluation des listes des temps de début et de fin ».

L'utilisation de restart pour une activation en bascule

Cette section est informative.

Il arrive souvent que l'on veuille utiliser un même événement d'interface utilisateur pour démarrer un élément et l'arrêter. Ceci est parfois décrit comme une activation « en bascule », car l'événement d'interface utilisateur fait passer l'élément de « marche » à « arrêt », et inversement. L'attribut restart peut être utilisé pour cela de la manière suivante :

<smil ...>
...
<img id="foo" begin="bar.activateEvent" end="bar.activateEvent"
	      restart="whenNotActive" ... />
</smil ...>	       

Si "foo" était défini avec la valeur par défaut "always", un second activateEvent sur "bar" aurait pour effet de redémarrer l'élément. Cependant, comme le second activateEvent ne peut pas redémarrer l'élément quand restart vaut "whenNotActive", l'élément ignore la spécification "begin" de l'événement activateEvent. L'élément peut alors utiliser activateEvent pour terminer sa durée active et s'arrêter.

Notez que dans les documents SMIL, un élément SMIL ne peut être visible avant d'avoir commencé et donc pour begin="activateEvent" cela signifie qu'il ne démarrera jamais. Dans les langages gérant l'attribut timeAction, cela peut ne pas être le cas. Par exemple, ce qui suit est raisonnable :

<html ...>
...
<span begin="click" end="click" timeAction="class:surbrillance" restart="whenNotActive">
   Cliquer ici pour mettre en surbrillance et à nouveau pour l'enlever
</span>
...
</html>

Ceci est basé sur la sémantique de sensibilité des événements décrite dans « La sensibilité des événements » et « La consolidation de la temporisation basée sur les événements et de la temporisation planifiée ».

Le contrôle du comportement par défaut de restart

Cette section est normative.

L'attribut suivant est fourni pour spécifier le comportement par défaut de restart :

restartDefault = "always | whenNotActive | never | inherit"
Définit la valeur par défaut pour le redémarrage d'un élément.
Les valeurs "always", "whenNotActive" et "never" spécifient que l'élément se comporte comme l'indique les valeurs respectives lors d'un redémarrage.
inherit
Spécifie que la valeur de cet attribut (et son comportement de redémarrage) est héritée de la valeur restartDefault de son élément parent. S'il n'y a pas d'élément parent, la valeur est "always".
C'est la valeur par défaut.

Étant données les valeurs par défaut de cet attribut ("inherit") et de l'attribut restart ("default"), un document qui ne spécifie pas ces attributs aura un comportement qui correspond à restart="always" pour tous les éléments temporisés.

La réinitialisation de l'état d'un élément

Cette section est normative.

Quand un conteneur de temps se répète ou redémarre, tous les enfants descendants sont « réinitialisés » en regard d'un certain état :

  1. Tous les temps d'instance associés à des valeurs d'événement, de répétition ou de clé d'accès passées, ou ajoutée via des appels aux méthodes DOM sont retirées des listes des temps d'instance de début et de fin dépendantes. Dans les faits, tous les événements et appels à des méthodes DOM du passé sont effacés. Cela ne s'applique pas à une instance définissant le le début de l'intervalle en cours ;
  2. Tous les temps de base de synchronisation sont ré-évalués (i.e., la traduction entre espaces temporels doit être recalculée - voir « La conversion entre temps local et temps global ») ;
  3. Un temps de de base de synchronisation résolu est retiré de la liste des temps d'instance dépendants quand un ascendant commun à la base de synchronisation et à l'élément dépendant redémarre ou se répète ;
  4. Tout état associé à l'interprétation de la sémantique de restart est réinitialisé.

Cette section est informative.

Par exemple, si un élément spécifie restart="never", l'élément peut commencer à nouveau après une réinitialisation. Le paramétrage restart="never" n'est défini que pour l'étendue de la durée simple du conteneur de temps parent.

Cette section est normative.

Quand un élément redémarre, les règles 1 et 2 sont aussi appliquées à l'élément lui-même, même si la règle 4 (qui contrôle le comportement de redémarrage) ne soit pas appliquée.

Notez que quand un conteneur de temps termine sa durée simple (y compris quand il se répète), tous les enfants temporisés toujours actifs sont terminés. Voir aussi « Les contraintes du conteneur de temps sur les durées des enfants ».

Quand un conteneur de temps excl redémarre ou se répète, en plus de terminer tous les enfants actifs, le file d'attente des pauses de l'élément excl est effacée.

Les attributs syncBehavior, syncTolerance, et syncMaster : le contrôle de la synchronisation à l'exécution

Cette section est informative.

La nouvelle version SMIL 2.0 introduit un contrôle plus précis du comportement de synchronisation à l'exécution d'un document. L'attribut syncBehavior permet à un auteur de définir, pour chaque élément, si celui-ci doit conserver une relation de synchronisation rigide avec le conteneur de temps parent ou si l'élément média peut admettre un décrochage par rapport au conteneur de temps. Ainsi, si l'encombrement du réseau retarde ou interrompt la livraison du média pour un élément, l'attribut syncBehavior contrôle si l'élément média peut décrocher pendant que le reste du document continue de jouer, ou si le conteneur de temps doit aussi attendre que la livraison du média soit faite.

L'attribut syncBehavior peut aussi être appliqué aux conteneurs de temps. Cela contrôle la relation de synchronisation de tout le plan de montage chronologique du conteneur de temps. Dans cet exemple, les éléments audio et vidéo sont définis avec une synchronisation rigide, ou « verrouillée », pour maintenir une synchronisation des lèvres, mais le conteneur de temps par "speech" peut décrocher :

<par>
   <animation src="..." />
   ...
   <par id="speech" syncBehavior="canSlip" >
      <video src="speech.mpg" syncBehavior="locked" />
      <audio src="speech.au"  syncBehavior="locked" />
   </par>
   ...
</par>

Si l'un ou l'autre du son ou de la vidéo devait se mettre en attente à cause d'un problème de livraison, l'élément par "speech" entier se mettra en attente pour que le plan de montage chronologique dans son ensemble reste synchronisé. Cependant, le reste du document, y compris l'élément animation pourront continuer à jouer normalement. En utilisant l'attribut syncBehavior sur les élément et les conteneurs de temps, l'auteur peut vraiment décrire la « portée » du comportement de synchronisation à l'exécution, définissant ainsi des morceaux du document devant se jouer avec une relation de synchronisation rigide, sans pour autant que tout le document doivent être synchronisé de faç rigide.

Cette fonctionnalité s'applique aussi quand un élément commence initialement et que le média doit commencer à jouer. Si le média n'est pas encore prêt (par exemple, si un fichier image n'est pas encore téléchargé), l'attribut syncBehavior contrôle si le conteneur doit attendre jusqu'à ce que le média soit prêt ou si le début de l'élément peut décrocher jusqu'à ce que le média soit téléchargé.

Une extension supplémentaire permet à l'auteur de spécifier qu'un élément particulier devrait définir ou contrôler la synchronisation d'un conteneur de temps. Ceci est similaire au comportement par défaut de nombreux agents utilisateurs qui « asservissent » la vidéo et d'autres médias au son, pour accommoder les insuffisances du matériel audio et la sensibilité des auditeurs aux interruptions de la lecture du son. L'attribut syncMaster permet à l'auteur de définir explicitement qu'un élément définisse la « mesure » de la lecture pour le conteneur de temps, tous les autres éléments devant rester synchronisés sur l'élément avec l'attribut syncMaster.

Dans la pratique, un média linéaire a souvent besoin d'être le syncMaster (maître de la synchronisation), alors qu'un média non-linéaire peut plus facilement être ajusté pour conserver une synchronisation rigide. Cependant, un agent utilisateur ne peut pas toujours déterminer quel média est linéaire et quel média est non-linéaire. De plus, quand il y a plusieurs éléments linéaires actifs à un moment donné, l'agent utilisateur ne peut pas toujours prendre la « bonne » décision pour résoudre les conflits de synchronisation. L'attribut syncMaster permet à l'auteur de spécifier l'élément ayant un média linéaire, ou étant le « plus important », et qui ne devrait pas être compromis par le comportement de l'attribut syncBehavior d'autres éléments.

Cette section est normative.

syncBehavior = ( canSlip | locked | independent | default )
Définit le comportement de synchronisation à l'exécution pour un élément.
Les valeurs autorisées sont :
canSlip
Permet à l'élément associé de décrocher par rapport à son conteneur de temps.
Quand cette valeur est utilisée, tout attribut syncTolerance est ignoré.
locked
Oblige l'élément associé à garder la synchronisation avec le conteneur de temps parent. Cela peut être accompagné de l'utilisation de l'attribut syncTolerance.
independent
Déclare un plan de montage chronologique indépendant qui est planifié sur le graphe temporel, mais qui ignorera toutes les opérations de recherche sur le parent.
default
Le comportement de synchronisation à l'exécution de l'élément est déterminé par la valeur de l'attribut syncBehaviorDefault.
C'est la valeur par défaut.

La valeur independent est équivalente à déclarer syncBehavior="canSlip" et syncMaster="true", ainsi l'élément est planifié dans le graphe temporel, mais n'est pas affecté par les autres problèmes de synchronisation à l'éxécution. Déclarer syncBehavior="canSlip" et syncMaster="true" indique que l'élément est l'horloge de synchronisation maître et qu'il peut décrocher par rapport au plan de montage chronologique de son parent.

 
syncTolerance = ( Clock-value | default )
Cet attribut, pour les éléments temporisés et les conteneurs de temps, définit la tolérance de synchronisation avec l'élément associé. Cet élément n'a d'effet que si le comportement de synchronisation à l'exécution de l'élément est "locked". Cela permet à une relation de synchronisation verrouillée de tolérer une certaine quantité de glissement sans forcer une resynchronisation.
Clock-value
Spécifie la tolérance de synchronisation comme une valeur. La valeur d'horloge est mesurée dans le temps simple de l'élément.
default
La tolérance de synchronisation de l'élément est déterminée par la valeur de l'attribut syncToleranceDefault.
Il s'agit de la valeur par défaut.
syncMaster
Un attribut booléen des éléments médias et des conteneurs de temps qui force les autres éléments du conteneur de temps à synchroniser leur lecture sur celle de l'élément.
La valeur par défaut est false.
La propriété associée est en lecture seule et ne peut être affectée par un script.

Cette section est informative.

Notez que la sémantique de syncBehavior ne décrit pas ni ne nécessite d'approche particulière pour conserver la synchronisation ; l'approche dépendra de l'implémentation. Des solutions possibles pour résoudre un conflit de synchronisation peuvent inclure :

Un contrôle supplémentaire est fourni pour les synchronisations rigides en utilisant l'attribut syncTolerance. Cela spécifie la quantité de décrochement pouvant être ignorée pour un élément.  De petites variations dans la lecture du média (dues, par exemple, aux imprécisions du matériel) peuvent souvent être ignorées et permettre ainsi une performance globale qui paraît plus fluide.

Quand un élément est en pause (y compris les cas décrits précédemment pour les comportement de synchronisation à l'exécution), le temps de fin calculé pour l'élément peut changer ou même devenir résolu et le modèle temporel doit refléter ce fait. Ceci est détaillé dans « Les éléments en pause et la durée active ».

 

Le contrôle du comportement par défaut

Deux attributs sont définis pour spécifier le comportement par défaut de la synchronisation à l'exécution :

syncBehaviorDefault = ( canSlip | locked | independent | inherit )
Définit la valeur par défaut pour le comportement de synchronisation à l'exécution d'un élément.
Les valeurs "canSlip", "locked" et "independent" spécifient que l'élément se comporte respectivement comme l'indique la valeur.
inherit
Spécifie que la valeur de cet attribut (et la valeur du comportement de synchronisation à l'exécution de l'élément) est héritée de la valeur de syncBehaviorDefault de l'élément parent. S'il n'y a pas d'élément parent, la valeur dépend de l'implémentation.
Il s'agit de la valeur par défaut.
syncToleranceDefault = ( Clock-value | inherit )
Définit la valeur par défaut pour la tolérance de synchronisation à l'exécution d'un élément.
La valeur d'horloge spécifie que la tolérance de synchronisation pour l'élément correspond respectivement à la valeur.
inherit
Spécifie que la valeur de cet attribut (et la valeur du comportement de synchronisation à l'exécution de l'élément) est héritée de la valeur de syncToleranceDefault de l'élément parent. S'il n'y a pas d'élément parent, la valeur dépend de l'implémentation, mais ne devrait pas dépasser 2 secondes.
Il s'agit de la valeur par défaut.
Le décalage de synchronisation accumulé

Si un élément décroche dans la synchronisation par rapport à son parent, la quantité de décrochement est appelée décalage de synchronisation accumulé. Ce décalage est utilisé pour tenir compte de la sémantique de pause ainsi que des décrochages liés à l'exécution ou à la livraison. Cette valeur sert à ajuster la conversion entre les temps des éléments et des parents, comme décrit dans « La conversion entre temps local et temps global ». Le décalage est calculé de la facon suivante :

Soit tc(tps) le temps actif calculé pour un élément au temps simple du parent qui est tps, suivant les relations de synchronisation définies pour l'élément ;

Soit to(tps) le temps actif calculé pour un élément au temps simple du parent qui est tps.

Le décalage de synchronisation accumulé O vaut :

O = to(tps) - tc(tps)

Ce décalage est mesuré dans le temps simple du parent.

Ainsi un décalage de synchronisation accumulé de 1 seconde correspond à un élément joué 1 seconde « en retard » par rapport à sa planification. Un décalage de -0.5 seconde correspond à un élément joué une demi-seconde « en avance » sur le moment où il aurait dû l'être.

Les attributs pour l'intégration de la la temporisation : timeContainer et timeAction

La modularité des fonctionnalités de SMIL 2.0 permet aux concepteurs de langages d'intégrer la temporisation et la synchronisation de SMIL dans n'importe quel langage XML. De plus d'une simple planification des éléments médias comme dans les document SMIL, une temporisation peut être appliquée aux éléments du langage hôte. Par exemple, l'ajout d'une temporisation aux éléments HTML (i.e., XHTML) permet de contrôler la présentation des documents HTML au cours du temps, et de synchroniser le texte et la présentation avec des médias continus tels que le son et la vidéo.

Deux attribut ont été introduits pour gérer ces cas d'intégration. L'attribut timeContainer permet à l'auteur de spécifier que tout élément de langage XML se comporte comme un conteneur de temps. Par exemple, une liste ordonnée HTML <ol> peut être définie pour se comporter comme une succession de conteneurs de temps. L'attribut timeAction permet à l'auteur de spécifier quel type de gestion appliquer à l'élément donné.

L'attribut timeContainer

Les éléments de langage XML peuvent être déclarés pour avoir la sémantique d'un conteneur de temps en ajoutant l'attribut timeContainer. La syntaxe est la suivante :

timeContainer = ( par | seq | excl | none )
par
Définit un conteneur de temps parallèle.
seq
Définit un conteneur de temps séquentiel.
excl
Définit un conteneur de temps exclusif.
none
Définit l'élément courant pour qu'il ne soit pas un conteneur de temps (i.e., pour qu'il se comporte comme un élément temporisé simple).
Ceci est la valeur par défaut.

Les contraintes d'utilisation de l'attribut timeContainer sont :

L'attribut timeAction

L'attribut timeAction fournit un contrôle des effets de la temporisation sur un élément. Un langage hôte doit spécifier quelles valeurs sont permises pour chaque élément du langage. Un langage hôte doit spécifier le comportement de temporisation intrinsèque pour chaque élément sur lequel l'attribut timeAction peut être employé. De plus, un langage hôte peut spécifier des valeurs supplémentaires pour timeAction. La syntaxe est la suivante :

timeAction = ( intrinsic | display | visibility | style | class | none )
intrinsic
Spécifie qu'une temporisation contrôle le comportement intrinsèque de l'élément.
Il s'agit de la valeur par défaut.
display
Spécifie qu'une temporisation contrôle l'affichage de l'élément, comme défini par CSS. La temporisation de l'élément peut influer sur l'apparence de la présentation. Pour les langages utilisant les CSS, la propriété "display" des CSS peut être contrôlée à travers le temps.
visibility
Spécifie que le temps contrôle la visibilité de l'élément, comme défini par CSS. La gestion du temps de l'élément ne doit pas influer sur l'apparence de la présentation. Pour les langages utilisant CSS, la propriété "visibility" de CSS devrait être contrôlée au cours du temps.
style
Spécifie qu'une temporisation contrôle l'application d'un style défini par un attribut en-ligne "style".
class:nom de classe
Spécifie qu'une temporisation contrôle l'inclusion du nom de classe spécifié dans le jeu des classes associées à l'élément (i.e., la liste des valeurs de l'attribut class de XML).
none
Spécifie que la temporisation n'a aucun effet sur la présentation de l'élément.

Le comportement intrinsic est défini par le langage hôte. Par exemple, dans le langage SMIL, le comportement intrinsic des éléments médias est de planifier et de contrôler la visibilité du média. Pour certains éléments ou certains langages, le comportement intrinsic peut par défaut correspondre à l'un des autres comportements.

Sémantique et contraintes supplémentaires de timeAction :

Certains éléments particuliers peuvent avoir une sémantique spécifique pour intrinsic. Par exemple, les éléments de lien comme a et area peuvent avoir un comportement intrinsic qui contrôle la sensibilité des éléments à une action de l'utilisateur. Cela peut aussi avoir des effets secondaires sur la présentation. En XHTML par exemple, le fait de rendre ces éléments non sensibles a aussi pour effet que le style par défaut (par exemple, une couleur et un souligné), qui est appliqué aux liens sensibles, est supprimé quand l'élément n'est pas actif ou gelé.

Les concepteurs de langages hôte devraient considérer et définir soigneusement le comportement associé à l'application d'une temporisation sur un élément. Par exemple, les éléments script pourraient être définis pour s'exécuter quand l'élément commence ou le langage pourrait interdire l'attribut timeAction sur l'élément. De la même manière, les éléments link pourraient appliquer une feuille de style liée quand l'élément commence ou le langage pourrait interdire l'attribut timeAction sur link.

Pour plus de détails sur les propriétés visibility et display de CSS, voir [CSS2].

Exemples :

L'exemple suivant montre un cas simple de contrôle de la visibilité au cours du temps. Le texte est caché entre les secondes 0 et 3, montré normalement pendant 5 secondes, puis caché à nouveau.

<span timeAction="visibility" begin="3s" dur="5s">
   Montre brièvement le texte.
</span>

L'exemple suivant montre un cas simple de contrôle de l'affichage au cours du temps. Chaque élément de liste est montré pendant 5 secondes et est retiré de l'affichage quand il est non actif ou gelé. L'élément de liste ordonnée se présente comme un conteneur de temps séquentiel (notez que chaque élément de liste retient son numéro, même quand les autres ne sont pas joués) :

<ol timeContainer="seq" repeatDur="indefinite">
   <li timeAction="display" dur="5s">
      Vous verrez ceci en premier. </li>
   <li timeAction="display" dur="5s">
      Vous verrez ceci en second. </li>
   <li timeAction="display" dur="5s">
      Et finalement vous verrez ceci. </li>
</ol>

L'exemple suivant montre comment le style spécifique d'un élément peut être appliqué au cours du temps. Le style respectif est appliqué à chaque label HTML pendant 5 secondes après qu'un événement focus se produise sur l'élément :

<form ...>
...
   <label for="select_red" begin="focus" dur="5s" timeAction="style"
	  style="color:red; font-weight:bold" >
      Colore les choses en ROUGE.
   </label>
   <input id="select_red" .../>
   <label for="select_green" begin="focus" dur="5s" timeAction="style"
	  style="color:green; font-weight:bold" >
      Colore les choses en VERT.
   </label>
   <input id="select_green" .../>
...
</form>

10.3.2 Les Les éléments

Cette section est informative.

SMIL 2.0 spécifie trois types de conteneurs de temps. Ceux-ci peuvent être déclarés avec les éléments par, seq et excl, ou, dans certains profils d'intégration, avec un attribut timeContainer. Les éléments médias avec des enfants temporisés sont appelés « conteneurs de temps médias » et ont une sémantique basée sur la sémantique de par (voir aussi « Les attributs pour l'intégration de la temporisation : timeContainer et timeAction » et « La durée implicite des conteneurs de temps médias »).

Ce document se réfère en général aux conteneurs de temps par référence aux éléments, mais la même sémantique s'applique à ceux déclarés par un attribut et aux conteneurs de temps médias.

L'élément par

Cette section est normative.

par
Un conteneur de temps par, abréviation de « parallèle », définit un simple regroupement temporel dans lequel plusieurs éléments peuvent être joués en même temps.

La base de synchronisation pour les éléments enfants d'un par est le début de l'élément par. La valeur par défaut de begin pour les enfants d'un par est "0". Il s'agit du même élément que celui introduit dans SMIL 1.0.

L'élément par tous les éléments temporisés.

La durée implicite des conteneurs de temps par

La durée implicite d'un élément par est contrôlée par l'attribut endsync. Par défaut, la durée implicite d'un par est définie par endsync="last". La durée implicite se termine avec la dernière fin active des éléments enfants.

L'élément seq

Cette section est normative.

seq
Un conteneur seq définit une séquence d'éléments dans laquelle les éléments sont joués les uns après les autres.

C'est le même élément que celui introduit dans SMIL 1.0, mais la sémantique (et la syntaxe autorisée) pour les éléments enfants est clarifiée.

L'élément seq lui-même gère tous les éléments de temporisation, sauf endsync.

La durée implicite des conteneurs de temps seq

L'élément excl

SMIL 2.0 définit un nouveau conteneur de temps : excl.

Cette section est normative.

excl
Ceci définit un conteneur de temps dont la sémantique est basée sur celle de par, mais avec une contrainte supplémentaire, c'est qu'à tout instant, au plus un seul élément peut être joué. Si un élément commence à jouer alors qu'un élément est déjà en train de jouer, l'élément qui était en cours de lecture est soit mis en pause, soit arrêté. Dans un excl, les éléments sont regroupés en catégories et le comportement de pause/interruption de chaque catégorie peut être contrôlé en utilisant le nouvel élément de groupage priorityClass.

La base de synchronisation implicite des éléments enfants d'un excl correspond à l'attribut begin du excl. La valeur par défaut de begin pour les enfants du excl est "indefinite". Cela signifie que excl a une durée de 0, à moins qu'un enfant du excl n'ait été ajouté au graphe temporel.

L'élément excl lui même gère tous les éléments temporisés.

Cette section est informative.

Avec le conteneur de temps excl, certains cas d'utilisation courante qui étaient difficiles, voire impossibles, pour l'auteur sont maintenant plus simples et possibles à créer. Le conteneur de temps excl est utilisé pour définir un jeu de séquences s'excluant mutuellement et pour décrire les comportements de mise en pause et de reprise de lecture pour ces séquences. Voici quelques exemples :

juke-box interactif
Une sélection de séquences de médias est proposée au choix de l'utilisateur, une seule peut être lue à la fois. Une nouvelle sélection remplace la sélection courante.
descriptions sonores
Pour les utilisateurs non-voyants, la vidéo courante est mise en pause et une description sonore de la scène est jouée. La vidéo reprend quand la description sonore est finie.
sous-titrage vidéo interactif
Les sous-titres pour une vidéo sont disponibles en plusieurs langues. Une seule version peut être affichée à la fois, la sélection la plus récente remplace le choix de langue précédent, le cas échéant.

Le cas d'utilisation du juke-box interactif ci-dessus pourrait être réalisé en utilisant un par dont les sources ont un temps de début interactif et une fin basée sur des événements pour toutes les autres sources. Cela nécessiterait de maintenir une liste prohibitive de valeurs pour l'attribut end . Le conteneur de temps excl fournit un raccourci commode pour cela - les temps de début des éléments sont toujours interactifs, mais les les événements pour end n'ont pas besoin d'être spécifiés, puisque l'élément excl, par définition, ne permet la lecture que d'un seul élément enfant à la fois.

Le cas d'utilisation des descriptions sonores n'est pas réalisable sans le comportement de pause/reprise fourni par les éléments excl et priorityClass. Ce cas pourrait se réaliser avec un élément video et les descriptions sonores comme enfants du excl. L'élément video devrait être planifié pour démarrer en même temps que le excl et les descriptions sonores, correspondant à l'élément video, démarreraient à des temps de début planifiés ou en réponse à des événements déclenchés à des moments spécifiques.

Le cas d'utilisation du sous-titrage dynamique requiert le comportement « une lecture à la fois » de excl. De plus, les éléments enfants sont déclarés de manière à préserver la relation de synchronisation avec la vidéo :

<smil ...>
...
<par>
   <video id="vid1" .../>
   <excl>
	<par begin="englishBtn.activateEvent" >
	   <audio begin="vid1.begin" src="english.au" />
	</par>
	<par begin="frenchBtn.activateEvent" >
	   <audio begin="vid1.begin" src="french.au" />
	</par>
	<par begin="swahiliBtn.activateEvent" >
	   <audio begin="vid1.begin" src="swahili.au" />
	</par>
   </excl>
</par>
...
</smil>

Les trois éléments par sont enfants du excl, et ainsi un seul peut être joué à la fois. L'enfant audio de chaque par est défini pour commencer quand commence la vidéo. Chaque audio ne peut être activé que lorsque le conteneur parent (par) est actif, mais l'attribut begin continue de spécifier une relation de synchronisation. Cela signifie que lorsque chaque par démarre, le son va commencer à jouer à un certain point au milieu de la séquence audio et de façon synchronisée avec la vidéo.

Le conteneur de temps excl est utile pour de nombreux scénarios de création en fournissant une solution déclarative pour décrire des interactions complexes entre des séquences.

La durée implicite des conteneurs de temps excl

Cette section est normative.

L'élément priorityClass

Cette section est informative.

Utiliser des classes de priorité pour contrôler le comportement de mise en pause des enfants de conteneurs excl permet à l'auteur de regrouper un contenu en catégories de contenu et ainsi de décrire des règles pour indiquer comment chaque catégorie va interrompre ou être interrompue par les autres catégories. Les attributs du nouvel élément de groupage priorityClass décrivent les interactions prévues.

Chaque élément priorityClass décrit un groupe d'enfants et le comportement de ces enfants quand ils sont interrompus par d'autres enfants temporisés de excl. Le comportement est décrit en termes de pairs et d'éléments de priorité plus haute ou plus basse. Des pairs sont ceux des éléments qui ont le même élément priorityClass.

Quand un élément dans le excl commence (ou devrait normalement commencer) pendant qu'un autre est déjà actif, plusieurs comportements peuvent en résulter. L'élément actif peut être mis en pause ou arrêté, ou l'élément interrompant peut être différé ou simplement empêché de commencer.

Le choix attentif des valeurs par défaut rend les cas d'utilisations courantes très simples. Voir les exemples ci-dessous.

Cette section est normative.

priorityClass
Définit un groupe d'enfant temporisés de excl et le comportement de mise en pause/interruption de ces enfants. Si un élément priorityClass apparaît comme enfant d'un élément excl, alors le excl ne peut contenir que des éléments priorityClass (i.e., l'auteur ne peut mélanger des enfants temporisés et des éléments priorityClass dans un conteneur excl).

Si aucun élément priorityClass n'est utilisé, tous les enfants du excl sont considérés comme étant des pairs, leur attribut peers ayant une valeur de comportement "stop".

Les attributs peers, higher et lower

Cette section est informative.

Notez que les règles définissent le comportement de l'élément actif et celui de l'élément interrompant. Aucun des éléments de la file d'attente n'est affecté (sauf que leur position dans la queue peut changer en raison de nouvelles insertions ).

Cette section est normative.

peers = " stop | pause | defer | never "
Contrôle la façon dont les éléments enfants de ce priorityClass vont s'interrompre les uns les autres.
Les valeurs autorisées pour cet attribut sont :
stop
Si un élément enfant commence alors qu'un autre enfant est actif, l'élément actif est tout simplement arrêté.
Il s'agit de la valeur par défaut pour peers.
pause
Si un élément enfant commence alors qu'un autre enfant est actif, l'élément actif est mis en pause et reprendra quand le nouvel élément (interrompant) aura terminé sa durée active (selon les contraintes du conteneur de temps excl). L'élément mis en pause est ajouté à la file d'attente.
defer
Si un élément enfant essaye (i.e., devrait normalement) de commencer quand un autre enfant est actif, le nouvel élément (interrompant) est différé jusqu'à ce que l'élément actif ait terminé sa durée active.
never
Si un élément enfant essaye (i.e., devrait normalement) de commencer quand un autre enfant est actif, le nouvel élément (interrompant) est empêché de commencer. Le début du nouvel élément (interrompant) est ignoré.
higher = " stop | pause "
Contrôle la façon dont les éléments avec une plus haute priorité vont interrompre les éléments enfants de priorityClass.
Les valeurs autorisées pour cet attribut sont :
stop
Si un élément de priorité plus grande commence alors qu'un élément de ce priorityClass est actif, l'élément enfant actif est arrêté.
pause
Si un élément de priorité plus grande commence alors qu'un élément de ce priorityClass est actif, l'élément enfant actif est mis en pause et reprendra quand le nouvel élément (interrompant) aura terminé sa durée active (selon les contraintes du conteneur de temps excl). L'élément mis en pause est ajouté à la file d'attente.
Il s'agit de la valeur par défaut pour l'attribut higher.
lower = " defer | never "
Contrôle la façon dont les éléments avec une plus basse priorité vont interrompre les éléments enfants de priorityClass.
Les valeurs autorisées pour cet attribut sont :
defer
Si un élément de priorité plus basse essaye (i.e., devrait normalement) commencer alors qu'un élément enfant de ce priorityClass est actif, le nouvel élément (interrompant) est différé jusqu'à ce que l'élément actif termine sa durée active. Les règles pour l'ajout de l'élément dans la file d'attente sont décrites ci-dessous.
Il s'agit de la valeur par défaut pour l'attribut lower.
never
Si un élément de priorité plus basse essaye (i.e., devrait normalement) commencer alors qu'un élément enfant de ce priorityClass est actif, le nouvel élément (interrompant) est empêché de commencer. Le début du nouvel élément est ignoré et il n'est pas ajouté dans la file d'attente.

Quand le début d'un élément est bloqué (ignoré) à cause de la valeur "never", l'élément bloqué ne commence pas sur le modèle temporel. Le modèle temporel ne devrait pas propager les activations de début et de fin aux dépendants temporels pas plus qu'il ne devrait déclencher d'événements begin ou end.

L'attribut pauseDisplay

Cette section est informative.

L'attribut pauseDisplay contrôle le comportement durant la pause des enfants d'un élément priorityClass. Quand un enfant d'un élément priorityClass est mis en pause selon la sémantique de excl et priorityClass, l'attribut pauseDisplay contrôle si l'élément en pause doit continuer d'être affiché ou de s'appliquer (i.e., l'état de l'élément durant la période où il est en pause), ou s'il doit être retiré de la présentation (i.e., désactivé) durant la pause.

Cette section est normative.

pauseDisplay = " disable | hide | show "
Contrôle la façon dont les éléments enfants de l'élément priorityClass se comportent lorsqu'ils sont en pause. Cet attribut ne s'applique que si peers="pause" ou higher="pause".
Les valeurs autorisée pour cet attribut sont :
 
disable
Continue d'afficher les médias visuels quand l'élément est mis en pause par excl et priorityClass, mais apparaît comme étant désactivé. La façon dont les éléments désactivés apparaissent dépend de l'implémentation (rendu d'une manière différente pour le distinguer de l'élément actif, par exemple, en grisé). Les éléments désactivés ne répondent pas aux événement de souris.
hide
Supprime les effets de l'élément (y compris tout affichage) quand un élément est mis en pause par la sémantique de excl et priorityClass.
show
Continue à montrer les effets de l'élément (y compris l'affichage) quand un élément est mis en pause par la sémantique de excl et priorityClass. Cette valeur est sans effet sur un média sonore.
C'est la valeur par défaut.
Exemples d'utilisation avec les éléments excl et priorityClass

Cette section est informative.

Notez que grâce aux valeurs par défaut, les cas simples fonctionnent sans syntaxe supplémentaire. Dans les cas de base, tous les éléments sont par défaut des pairs et s'arrêtent les uns les autres :

<excl dur="indefinite">
   <audio id="song1" .../>
   <audio id="song2" .../>
   <audio id="song3" .../>
   ...
   <audio id="songN" .../>
</excl>

Ceci est équivalent à ce qui suit avec des affectations explicites :

<excl dur="indefinite">
   <priorityClass peers="stop">
     <audio id="song1" .../>
     <audio id="song2" .../>
     <audio id="song3" .../>
     ...
     <audio id="songN" .../>
   </priorityClass>
</excl>

Si l'auteur veut que les éléments soit mis en pause plutôt qu'arrêtés, la syntaxe est la suivante :

<excl dur="indefinite">
   <priorityClass peers="pause">
     <audio id="song1" .../>
     <audio id="song2" .../>
     <audio id="song3" .../>
     ...
     <audio id="songN" .../>
   </priorityClass>
</excl>

Le cas d'utilisation de la description sonore pour les utilisateurs visuellement défaillants serait très proche de l'exemple précédent :

<excl dur="indefinite">
   <priorityClass peers="pause">
     <video id="main_video" .../>
     <audio id="scene1_description" begin="20s"  dur="30s".../>
     <audio id="scene2_description" begin="2min" dur="30s" .../>
     ...
     <audio id="sceneN_description" .../>
   </priorityClass>
</excl>

Cet exemple montre un cas plus complexe d'un programme et de quelques insertions de publicités. Les vidéos du programme s'interromperont les unes les autres. Les publicités mettront le programme en pause, mais ne s'interromperont pas l'une l'autre.

<excl dur="indefinite">
   <priorityClass id="ads" peers="defer">
     <video id="advert1" .../>
     <video id="advert2" .../>
   </priorityClass>
   <priorityClass id="program" peers="stop" higher="pause">
     <video id="program1" .../>
     <video id="program2" .../>
     <video id="program3" .../>
     <video id="program4" .../>
   </priorityClass>
</excl>

L'exemple suivant illustre comment les règles de report et les groupes de priorités peuvent interagir. Quand "alert1" essaye de commencer à 5 secondes, le priorityClass "programme" va forcer "alert1" à être reporté, et ainsi "alert1" va être placé dans la file d'attente. Quand "alert2" essaye de commencer à 6 secondes, les même règles vont forcer "alert2" dans la file d'attente. Notez que bien que le priorityClass "alerts" définisse la règle de peers comme "never", "alert1" n'est pas actif à 6secondes et ainsi les règles d'interruption entre "alert1" et "alert2" ne sont pas évaluées. Le comportement résultant est que, quand "prog1" se termine à 20 secondes, "alert1" va jouer, puis, quand "alert1" va se terminer, "alert2" va jouer.

<excl dur="indefinite">
   <priorityClass id="program" lower="defer">
     <video id="prog1" begin="0" dur="20s" .../>
   </priorityClass>
   <priorityClass id="alerts" peers="never">
     <video id="alert1" begin="5s" .../>
     <video id="alert2" begin="6s" .../>
   </priorityClass>
</excl>

Cet exemple illustre le contrôle exercé par pauseDisplay. Quand un élément est interrompu par un pair, l'élément interrompu est mis en pause et apparaît dans un état désactivé. Il dépend de l'implémentation de décider comment est rendue une vidéo désactivée. Les éléments désactivés ne répondent pas aux événements de souris.

<excl dur="indefinite">
   <priorityClass peers="pause" pauseDisplay="disable">
      <video id="video1" .../>
      <video id="video2" .../>
      <video id="video3" .../>
      ...
      <video id="videoN" .../>
   </priorityClass>
</excl>

Dans cet exemple, quand un enfant d'un élément priorityClass de plus haute priorité interrompt un enfant du priorityClass "programme", l'enfant de "programme" est mis en pause et reste à l'écran. Si un pair du priorityClass "programme" interrompt un pair, l'élément qui se jouait se termine et n'est plus affiché.

<excl dur="indefinite">
   <priorityClass id="ads" peers="defer">
      <video id="advert1" .../>
      <video id="advert2" .../>
   </priorityClass>
   <priorityClass id="program" peers="stop" higher="pause" pauseDisplay="show">
      <video id="program1" .../>
      <video id="program2" .../>
      <video id="program3" .../>
      <video id="program4" .../>
   </priorityClass>
</excl>
La sémantique de la file d'attente

Cette section est normative.

Les éléments qui sont en pause ou différés sont placés dans une file d'attente d'éléments rangés par ordre de priorité. Quand un élément actif termine sa durée active, et que la file d'attente n'est pas vide, le premier élément de la file (i.e., celui ayant la plus haute priorité) est tiré de la file et reprend sa lecture ou est activé.

La sémantique de la file est décrite par un ensemble d'invariants et par des règles pour l'insertion et le retrait des éléments. Pour les besoin de la discussion, nous considérons que les éléments enfants d'un élément priorityClass ont la priorité de cet élément priorityClass et ont le comportement décrit par les attributspeers, higher et lower sur le parent priorityClass.

Les invariants de la file d'attente
  1. La file d'attente est triée selon la priorité, avec les éléments de plus haute priorité avant ceux de priorité plus basse ;
  2. Un élément ne peut apparaître dans la file d'attente plus d'une fois ;
  3. Un élément ne peut être simultanément actif et dans la file d'attente.
L'insertion et le retrait d'éléments
  1. Les éléments sont insérés dans la file d'attente en fonction de leur priorité (selon l'invariant 1) ;
    1. Les éléments en pause sont insérés avant les autres éléments de même priorité ;
    2. Les éléments différés sont insérés après les autres éléments de même priorité.
  2. Lorsque la sémantique définit qu'un élément actif doit être mis en pause, l'élément est mis en pause dans le temps simple courant (position) lorsqu'il est placé dans la file d'attente. Quand un élément en pause est tiré normalement de la file d'attente, il reprend à la position où il se trouvait au moment de la mise en pause ;
  3. Lorsque la sémantique définit qu'un élément doit être différé, l'élément est inséré dans la file d'attente, mais il n'a pas commencé. Quand l'élément sera tiré normalement de la file d'attente, il commencera (i.e., à être actif) ;
  4. Lorsqu'un élément est placé dans la file d'attente, toute instance précédente de cet élément est retiré de la file d'attente (selon l'invariant 2) ;
  5. Lorsque l'enfant actif (i.e., enfant temporisé) d'un élément excl se termine normalement (i.e., pas lorsqu'il est interrompu par un autre élément), l'élément en tête de file est retiré de la file d'attente et reprend ou commence (selon les invariants 2 et 3).

Notez que si un élément est actif ou reprend (selon les règles de l'attribut restart), il ne s'interrompt pas lui-même au sens où un pair l'interromprait. Plutôt, il redémarre simplement et la file n'est pas concernée.

Le comportement de synchronisation à l'exécution et la sémantique des valeurs pause/defer

Le comportement de synchronisation dynamique d'un élément ( décrit dans Les attributs syncBehavior, syncTolerance et syncMaster : contrôle de la synchronisation dynamique ) n'a pas d'effet sur la sémantique de la file. tout élément qui est en pause ou reporté se comporte comme décrit dans la sémantique de la file. Quand un élément en pause reprend, la relation de synchronisation est réétablie selon la sémantique de la synchronisation dynamique. La relation de synchronisation pour un élément reporté est établie quand il commence vraiment.

Les temps calculés et la sémantique des valeurs pause/defer

Quand un élément est mis en pause, le temps de fin calculé pour l'élément peut varier, ou même devenir résolu, et le modèle temporel doit refléter cette situation. Ceci est détaillé dans « Les éléments en pause et la durée active ». Dans certains cas, le temps de fin est défini par d'autres éléments non affectés par la sémantique de la file d'attente. Dans l'exemple suivant, l'élément "foo" va être mis en pause à 8 secondes, mais il s'arrêtera tout de même à 10 secondes (pendant qu'il est en pause) :

<img "joe" end="10s" .../>
<excl dur="indefinite">
   <priorityClass peers="pause">
      <img id="foo" end="joe.end" .../>
      <img id="bar" begin="8s" dur="5s" .../>
   </priorityClass>
</excl>

Si un élément se termine pendant qu'il est dans la file d'attente, il est simplement retiré de la file d'attente. Tous les éléments temporels qui en dépendent seront avertis normalement et l'événement de fin sera déclenché à l'instant de la fin, comme d'habitude.

Quand un élément est différé, le temps de début est également différé. Comme décrit dans « Les éléments en pause et la durée active », le temps de début d'un élément différé peut devenir non résolu, ou simplement différé. Dans l'exemple suivant, l'élément "bar" va initialement avoir un temps de début non résolu. Si l'utilisateur clique sur "foo" à 8 secondes, l'élément "bar" va se résoudre pour devenir 8 secondes, mais sera différé jusqu'à 10 secondes (quand "foo" se termine) :

<html ...>
...
<excl dur="indefinite">
   <priorityClass peers="defer">
      <img id="foo" begin="0s" dur="10s" .../>
      <img id="bar" begin="foo.click" .../>
   </priorityClass>
</excl>
...
</html>

S'il y a suffisamment d'information pour déterminer le nouveau temps de début (comme dans l'exemple précédent), une implémentation doit calculer le temps de début correct quand un élément est différé. Le changement de temps de début découlant du report d'un élément étant mis en pause doit être propagé à tous les dépendants temporels de l'arc de synchronisation (i.e., aux autres éléments avec un début ou une fin définis en fonction du début de l'élément différé). Voir aussi la section « La propagation des changement aux temps ».

Une exception au fonctionnement normal est faite concernant les éléments différés, pour simplifier le modèle : un élément différé ignore les changements propagés sur son temps de début. Ceci est détaillé dans la section « Les éléments différés et la propagation des changements sur le début ».

Les temps de début planifiés et excl

Bien que la valeur de début par défaut pour les enfants d'un excl soit indéfinie, les temps de début planifiés sont permis. Les temps de début planifiés sur les enfants d'un excl obligent l'élément à commencer au temps spécifié, mettant en pause ou arrêtant les autres frères en fonction des paramètres de l'élément priorityClass (et des valeurs par défaut).

La gestion des débuts simultanés avec excl

Si des enfants d'un excl essayent de commencer au même moment, l'évaluation se fait dans l'ordre du document. Pour chacun des éléments à son tour, la sémantique de priorityClass est considérée et les éléments peuvent être mis en pause, différés ou arrêtés.

Cette section est informative.

Les exemples suivants démontrent ce comportement (il peut résulter de n'importe quelle combinaison de temps planifiés, de temps interactifs, d'hyperliens ou d'activation DOM) :

<smil ...>
...
<excl>
   <img src="image1.jpg" begin="0s" dur="5s"/>
   <img src="image2.jpg" begin="0s" dur="5s"/>
   <img src="image3.jpg" begin="0s" dur="5s"/>
</excl>

<excl>
   <img id="img1" src="image1.jpg" begin="foo.activateEvent" dur="5s"/>
   <img id="img2" src="image2.jpg" begin="img1.begin" dur="5s"/>
   <img id="img3" src="image3.jpg" begin="img2.begin" dur="5s"/>
</excl>
...
</smil>

Dans le premier exemple, les images sont planifiées pour commencer immédiatement, alors que dans le second elles vont toutes commencer quand l'utilisateur activera l'élément "foo". Le résultat final des deux ( mis à part le temps de début) revient au même. Étant donnée la sémantique d'interruption par défaut pour excl, la première image va commencer et être immédiatement arrêtée par la seconde image, qui va à son tour être arrêtée par la troisième image. Le résultat est que seule la troisième image est vue et dure 5 secondes. Notez que les événements de début et de fin pour les deux premières images sont déclenchés et propagés à tous les dépendants temporels. Si le comportement est réglé sur "pause" comme dans cet exemple, l'ordre déclaré est en fait inversé :

<excl>
   <priorityClass peers="pause">
	<img src="image1.jpg" begin="0s" dur="5s"/>
	<img src="image2.jpg" begin="0s" dur="5s"/>
	<img src="image3.jpg" begin="0s" dur="5s"/>
   </priorityClass>
</excl>

Dans ce cas, la première image va commencer et être immédiatement mise en pause par la seconde image, qui va être immédiatement mise en pause par la troisième image. Le résultat est que la troisième image est affichée pendant 5 secondes, suivie par la seconde image pour 5 secondes, suivie par la première image pendant 5 secondes. Notez que les événements de début pour les deux premières images sont déclenchés et propagées à tous les dépendants temporels quand l'élément excl commence.

Dans le diaporama suivant, les images commencent au plus tôt de leur temps de début planifié ou quand elles sont activées par un événement utilisateur :

<html ...>
...
<excl>
   <img src="image1.jpg" begin="0s".../>
   <img src="image2.jpg" begin="10s; image1.click".../>
   <img src="image3.jpg" begin="20s; image2.click".../>
</excl>
...
</html>

Notez que certains résultats surprenants peuvent survenir lorsque l'on combine des temporisations planifiées et interactives dans un excl. Si, dans l'exemple précédent, l'utilisateur clique sur image1 et ensuite sur image2 avant que 10 secondes ne se soient écoulées, image2 va réapparaître à la seconde 10. Image3 va apparaître à 20 secondes. L'intention probable dans ce cas de figure aurait été sans doute mieux représentée au moyen d'un conteneur de temps seq.

Les effets secondaires de l'activation

Cette section est informative.

Les enfants d'un excl peuvent être activés par une temporisation planifiée, des liens hypertextes, des événements ou des appels aux méthodes de DOM. Pour toutes les activations, sauf les hyperliens, le conteneur de temps excl doit être actif pour que les éléments enfants du excl puissent être activés. Avec l'activation hypertextuelle, le document peut être sollicité pour forcer l'activation du excl parent et cette sollicitation peut survenir au temps de début de l'enfant cible si celui-ci a un temps de début résolu. Ce qui veut dire que la sémantique de sollicitation normale d'un hyperlien s'applique à un enfant temporisé d'un excl.

Cette section est normative.

Avec l'activation via un appel à une méthode DOM (par exemple, la méthode beginElement()), l'élément va être activé à l'instant courant (selon la sémantique de priorityClass), même si l'élément a un temps de début planifié. La sémantique exclusive du conteneur de temps (ne permettant qu'un élément actif à la fois) et toute la sémantique de priorityClass sont néanmoins respectées.

Voir aussi « Les hyperliens et la temporisation » et en particulier « Les implications de beginElement() et des hyperliens pour les conteneurs de temps seq et excl.

La durée implicite des conteneurs de temps des élémentsmédias

Cette section est normative.

La durée implicite d'un conteneur de temps de média combine la durée intrinsèque du média avec les enfants pour définir la durée simple implicite. Pour la valeur de endsync l'attribut "ID-REF", la sémantique est la même que pour un conteneur de temps normal. Pour la valeur de endsync "ID-REF", la durée implicite est égale à la durée intrinsèque du média directement associé à l'élément. Pour les valeurs "first", "last" et "all", l'élément média se comporte comme un conteneur de temps par, mais le média associé à l'élément est traité comme une condition supplémentaire jusqu'à ce que l'on puisse déterminer quand les critères des valeurs "first", "last" et "all" ont été satisfaites.

Si la durée implicite définie par endsync est plus longue que la durée intrinsèque de l'élément média continu, le dernier état du média (par exemple, la dernière image d'une vidéo) est affiché pour le reste de la durée implicite. Cela ne s'applique qu'aux médias visuels - les médias sonores arrêtent simplement de jouer.

Cette section est informative.

Cette sémantique est similaire au cas dans lequel un auteur spécifie une durée simple plus longue que la durée intrinsèque de l'élément média continu. Notez que dans les deux cas, bien que l'élément média soit effectivement gelé pour le reste de la durée simple, la durée simple du conteneur de temps n'est pas gelée pendant cette période et tous les enfants joueront normalement sans être affectés par la durée intrinsèque du média.

Exemples :

Dans les exemples suivants "vid1" dure 10 secondes.

La valeur par défaut de l'attribut endsync pour l'élément média est "media" et ainsi la durée simple dans l'exemple suivant est de 10 secondes. Cela va raccourcir à 8 secondes la durée simple de l'enfant animate :

<video src="vid1.mpg" >
   <animate begin="2s" dur="12s" .../>
</video>

La spécification endsync="first" dans l'exemple ci-dessous implique que la durée simple de la vidéo est de 10 secondes, ainsi le média se termine avant l'enfant animate :

<video src="vid1.mpg" endsync="first" >
   <animate begin="2s" dur="12s" .../>
</video>

La spécification endsync="last" dans l'exemple ci-dessous implique que la durée simple de la vidéo est de 14 secondes. La vidéo affichera une image fixe (la dernière image) pour les 4 dernières secondes :

<video src="vid1.mpg" endsync="last" >
   <set dur="8s" .../>
   <animate begin="2s" dur="12s" .../>
</video>

La spécification endsync="all" dans l'exemple ci-dessous implique que la durée simple de la vidéo dure au moins 10 secondes (la durée intrinsèque de la vidéo) et au plus jusqu'à 5 secondes après que l'utilisateur ait cliqué sur la vidéo. La vidéo montrera une image fixe pour toute durée dépassant 10 secondes :

<html ...>
...
<video src="vid1.mpg" endsync="all" >
   <set dur="8s" .../>
   <animate begin="click" dur="5s" .../>
</video>
...
</html>

Ainsi, si l'utilisateur clique sur la vidéo après une seconde, la durée simple sera de 10 secondes. Si l'utilisateur ne clique pas avant 15 secondes, la durée simple est de 20 secondes et la dernière image sera affichée entre les secondes 10 et 20. La vidéo peut cependant être cliquée même si elle se fige à 10 secondes.

Les conteneurs de temps des médias d'autres types

Dans les intégrations de certains langage, il sera possible de déclarer un conteneur de temps de média comme ayant une sémantique séquentielle ou exclusive, en plus de la sémantique parallèle par défaut définie précédemment. Par exemple :

<html ...>
...
<video src="vid1.mpg" timeContainer="seq" endsync="first" >
   <animate dur="4s" .../>
   <animate end="click" .../>
</video>
...
</html>

Les enfants animate de l'élément video vont être joués en séquence. La sémantique de endsync définit une durée simple pour l'élément video qui n'est de pas plus de 10 secondes (la durée intrinsèque de la vidéo) mais qui peut être juste au-delà de 4 secondes, si l'utilisateur clique sur video aussitôt que le dernier animate commence.

10.3.3 La sémantique du modèle temporel

Sauf précision contraire, cette section est entièrement normative

La résolution des temps

Un temps de début ou du fin est dit non résolu soit quand il est associé à un événement de début ou de fin qui ne s'est pas encore produit, soit quand le temps de début ou de fin dépend d'un autre temps de début ou de fin qui n'est pas résolu. Le temps devient résolu dès que le temps de l'élément avec lequel il doit se synchroniser est résolu, ou quand l'événement attendu se produit (selon les contraintes décrites dans « La sensibilité des événements »).

Si une valeur de début ou de fin est résolue comme faisant partie du passé, cette valeur est propagée autres dépendants de synchronisation. De la même façon, une durée simple ou active peut être non résolue mais peut devenir résolue quand les conditions de fin sont réunies ou quand le conteneur de temps parent contraint la durée de l'élément.

Les temps définis

Un temps résolu est dit défini si sa valeur n'est pas "indefinite".

La définition de la durée simple

La durée simple d'un élément est déterminée par l'attribut dur, la durée implicite de l'élément et une règle de cas particulier pour assurer la compatibilité ascendante avec SMIL 1.0. Appliquer la première règle du tableau qui satisfait au critère donné.

Le calcul de la durée simple est basé sur l'information disponible au moment ou le calcul est fait. Les valeurs non résolues peuvent imposer que la durée simple soit recalculée quand une valeur non résolue sera résolue.

 

dur Durée implicite de l'élément repeatDur et repeatCount Durée Simple
non spécifié (ignoré) non spécifié, end spécifié indefinite
Valeur d'horloge (ignoré) (ignoré) dur ou Clock-value
indefinite (ignoré) (ignoré) indefinite
non spécifié résolu (ignoré) durée implicite de l'élément
ou Clock-value
non spécifié non résolu (ignoré) non résolu
média résolu ou non-résolu (ignoré) durée implicite de l'élément

Tableau des durées simples

L'attribut repeatCount et la durée simple non résolue

Quand l'attribut repeatCount est spécifié, il représente un compteur d'itérations de durée simple. Chaque itération de la durée simple peut être différente et donc une simple multiplication de la valeur de repeatCount par une durée simple peut ne pas aboutir à une durée simple précise. Dans le cas d'un repeatCount partiel et d'une durée simple non résolue, la durée simple la plus récente devrait être multipliée par la fraction de repeatCount pour contraindre la dernière durée simple. Si autrement la dernière itération de la durée simple se termine avant ce temps, le repeatCount devrait être considéré comme accompli. Si un repeatCount vaut moins que 1 et que la durée simple est non résolue, le repeatCount ne peut être correctement respecté et se comportera comme si un repeatCount de "1" avait été spécifié.

Cette section est informative.

Si un élément spécifiant un média audio a une durée simple de 0 (par exemple à cause des valeurs de clipBegin et clipEnd), rien ne doit être joué même si repeatDur spécifie une durée active. Le modèle temporel se comporte comme décrit, mais aucun son ne devrait être joué.

Si un repeatDur est plus court que la durée simple, ou si repeatCount vaut moins de 1, la durée active peut raccourcir la durée simple définie.

Si repeatDur vaut "indefinite" et que soit repeatCount, soit end sont spécifiés, la durée active est indéfinie. Si repeatCount est indéfini, que la durée simple est plus grande que 0 et que soit repeatDur, soit end ne sont spécifiés, alors la durée active est indéfinie.

Notez que, contrairement à SMIL 1.0, quand un élément définit un décalage de début et un comportement de répétition avec repeatCount ou repeatDur, le décalage de début n'est pas inclus dans chaque répétition.

Le calcul de la durée active

La durée active d'un élément définit la période entière où le plan de montage chronologique de l'élément est actif. Cela prend en compte la durée simple de l'élément, définie ci-dessus, l'attribut end et tout comportement de répétition défini par les attributs repeatDur et repeatCount.

Les règles arithmétiques de la durée active

Le calcul de la durée active nécessite de définir des opérations arithmétiques sur toutes les valeurs possibles que la durée simple peut avoir.

Multiplication
Addition et soustraction
Fonction de minimisation

Avec n'importe quoi pouvant valoir valeur zéro, valeur non-zéro, indéfini ou non résolu.

Fonction de maximisation
L'algorithme de durée active

Cette section est informative.

Dans cette section, les références aux valeurs de begin et end doivent être comprises comme la valeur courante effective dans chaque liste de valeurs. Ces valeurs sont déterminées par les règles décrites dans « L'évaluation des listes des temps de début et de fin ».

Cette section est normative.

Les symboles suivants sont utilisés dans l'algorithme comme raccourcis :

B
Le début d'un élément.
d
La durée simple d'un élément.
PAD
La durée active préliminaire d'un élément, avant de prendre en compte les règles des attributs min et max.
AD
La durée active d'un élément.

Le calcul de la durée active est basé sur l'information disponible au moment où le calcul est fait. Les valeurs non résolues peuvent imposer que la durée simple soit recalculée quand une valeur non résolue le sera.

Pour calculer la durée active, on utilise l'algorithme suivant :

Si end est spécifié et que ni dur, repeatDur ou repeatCount ne le sont, alors la durée simple vaut indefinite, d'après le tableau ci-dessus, et la durée active est définie par la valeur de end, selon les cas suivants :

Si end est résolu en une valeur, alors PAD = end - B,

sinon, si end vaut indefinite, alors PAD = indefinite,

sinon, si end est non-résolue, alors PAD est non-résolu et devra être recalculé quand on disposera de plus d'informations.

Sinon, si aucune valeur n'est spécifiée pour end , ou que celle-ci est spécifiée comme valant indefinite, alors la durée active est déterminée à partir du calcul de la durée active intermédiaire donné ci-dessous :

PAD = Résultat du calcul de la durée active intermédiaire

Sinon, une valeur non égale à indefinite est spécifiée pour end avec au moins un des attributs dur, repeatDur ou repeatCount. La valeur de PAD est alors le minimum du résultat issu du calcul de la durée active intermédiaire, donné ci-dessous, et de la durée entre end et le début de l'élément :

PAD = MIN( Résultat du calcul de la durée active intermédiaire, end - B )

Finalement, la durée active calculée AD est obtenue en appliquant la sémantique des attributs min et max à la durée active préliminaire PAD. Dans l'expression suivante, s'il n'y a pas de valeur min, remplacez par une valeur de 0 et s'il n'y a pas de valeur max, remplacez par une valeur "indefinite" :

AD = MIN( max, MAX( min, PAD ))
Le calcul de la durée active intermédiaire

Nous définissons trois quantités intermédiaires p0, p1, et p2 et produisons un résultat intermédiaire, la Durée active Intermédiaire (IAD) servant pour les calculs précédents.

La quantité p0 est la durée simple issue de la table de durée simple donnée précédemment.

Si repeatCount n'est pas spécifié, la quantité p1 a la valeur indefinite. Sinon, p1 est la somme accumulée des durées simples des itérations de cet élément. La quantité p1 aura une valeur non résolue jusqu'à ce que la durée simple de chaque itération soit résolue. Les itérations partielles apporteront la fraction correspondante de leur durée simple à la somme. Ce produit peut être basé soit sur la durée simple connue d'un média, soit, si la durée est inconnue, sur l'itération précédente du jeu de répétitions courant. En général, pour les médias sans durée simple fixe, p1 ne sera pas résolu avant que le nombre entier d'itérations spécifié ne soient exécuté.

La quantité p2 est la valeur de repeatDur. Si repeatDur n'est pas spécifié, alors p2 aura la valeur indefinite.

Alors, IAD est donné par :

Si p0 vaut 0, alors

IAD = 0

Sinon, si repeatDur et repeatCount ne sont pas spécifiés, alors :

IAD = p0

sinon :

IAD = MIN( p1, p2, indefinite )

Cette section est informative.

À titre d'exemple, si un élément spécifie :

<smil ...>
...
<audio dur="5s" end="foo.activateEvent" .../>
...
</smil>

La durée active vaut initialement 5 secondes, basée sur la durée simple spécifiée. Si l'utilisateur active "foo" avant 5 secondes, la valeur de end devient résolue et la durée active est réévaluée. Cela entraîne la fin de l'élément au moment de l'activation.

Un certain nombre de règles et de résultats qui sont implicites dans l'algorithme et qu'il faudrait remarquer en particulier sont :

Il est possible de combiner une temporisation planifiée et une temporisation interactive. Par exemple :

<smil ...>
...
<par dur="30s">
   <img id="mutebutton" src="mute.jpg"/>
   <text  src="description.html" />
   <audio src="audio.au" end="mutebutton.activateEvent"/>
</par>
...
</smil>

L'image et le texte apparaissent pour la durée spécifiée de par (30 secondes). La durée active du son est initialement définie pour être indéfinie car son temps de fin est non résolu. Le son s'arrêtera plus tôt si l'image est activée (par exemple, si elle est cliquée) avant la fin implicite du son. Si l'image n'est pas activée, l'attribut dur du conteneur de temps parent contraindra la lecture.

Il est possible de déclarer à la fois une durée planifiée et une fin active basée sur un événement. Cela facilite ce que l'on appelle parfois dans certains cas d'utilisation « interaction paresseuse » , comme, par exemple, une présentation qui s'avance à la suite du clic d'un utilisateur ou d'elle-même après un certain temps :

<html ...>
...
<seq>
   <img src="slide1.jpg" dur="10s" end="click" />
   <img src="slide2.jpg" dur="10s" end="click" />
   <img src="slide3.jpg" dur="10s" end="click" />
   <!-- etc., etc. -->
</seq>
...
</html>

Dans ce cas, la fin active de chaque élément est définie pour être le premier qui survient entre la durée spécifiée et un clic sur l'élément. Cela donne au spectateur le choix entre s'asseoir et regarder, et faire défiler la présentation à un rythme plus élevé.

Les éléments en pause et la durée active

Un élément peut être mis en pause alors qu'il est actif. Cela peut se produire d'un certain nombre de façons, y compris l'appel à une méthode du DOM ou à cause de la sémantique de excl. Quand un élément est mis en pause, un temps de fin résolu pour l'élément peut changer ou devenir non résolu. La relation de synchronisation entre un élément en pause et son conteneur de temps parent est réétablie quand l'élément en pause reprend. Si, par exemple, l'élément ci-dessous est mis en pause suite à l'appel d'une méthode du DOM, il n'y a aucun moyen de savoir quand l'élément va se terminer, et donc le temps de fin doit être considéré comme non résolu :

<img dur="30s" .../>

Cependant, dans le cas suivant, l'élément "bar" va quand même se terminer à 10 secondes, bien qu'il ait été mis en pause à 8 secondes. Dans ce cas, le temps de fin ne change pas :

<img id="foo" dur="10s" .../>
<img id="bar" end="foo.end" .../>

Enfin, dans le cas suivant, l'élément "foo" est initialement prévu pour se terminer à 10 secondes. Si l'élément "bar" commence (i.e., si l'utilisateur active ou clique sur "foo"), à 8 secondes "foo" sera mis en pause. Cependant, puisque la durée de "bar" est connue et que la sémantique de la file d'attente de excl est clairement définie, la fin de "foo" peut être calculée pour survenir à 15 secondes :

<smil ...>
...
<excl dur="indefinite">
   <priorityClass peers="pause">
      <img id="foo" dur="10s" .../>
      <img id="bar" begin="foo.activateEvent" dur="5s" .../>
   </priorityClass>
</excl>
...
</smil>

S'il y a suffisamment d'informations pour calculer le nouveau temps de fin (comme dans l'exemple précédent), une implémentation doit calculer le bon temps de fin quand un élément est en pause. Tout changement du temps de fin découlant de la mise en pause d'un élément doit être propagé à tous les dépendants temporels dans l'arc de synchronisation (i.e., aux autres éléments dont le début ou la fin dépendent de la fin active de l'élément mis en pause). Voir aussi la section « La propagation des changements de temps ».

De plus, quand un élément est mis en pause, le décalage de synchronisation accumulé augmentera pour refléter la modification de la relation de synchronisation. Voir aussi « Le décalage de synchronisation accumulé ».

Enfin, quand un élément est mis en pause, il peut se terminer à cause de la fin de son conteneur de temps parent. Dans ce cas, tout comportement de remplissage est interprété en utilisant le temps actif de l'élément, quand l'élément se termine (i.e., il va utiliser le temps actif de l'élément, au moment de la mise en pause, pour déterminer ce qui doit être affiché).

L'évaluation des listes des temps de début et de fin

Cette section est informative.

Les enfants de conteneurs de temps par et excl peuvent avoir plusieurs valeurs de début et de fin. Nous devons spécifier la sémantique associée aux débuts et fins multiples et comment le modèle de graphe temporel dynamique fonctionne avec ces temps multiples.

Le modèle est basé sur l'idée d'intervalles pour chaque élément. Un intervalle est défini par un temps de début et de fin. Quand un graphe temporel est joué, plus d'un intervalle peuvent être créés pour un élément avec plusieurs temps de début et de fin. À chaque instant, il y a un intervalle courant associé à chaque élément. Les intervalles sont créés en interprétant une liste de temps de début et une liste de temps de fin, chacune étant basée sur les conditions décrites par les attributs begin et end de l'élément.

La liste de temps de débuts et la liste de temps de fin utilisées pour calculer les nouveaux intervalles sont appelées listes de « temps d'instance ». Chaque temps d'instance dans l'une des listes est associé avec la spécification de début, ou de fin, définie dans la syntaxe de l'attribut. Certaines conditions - comme par exemple les valeurs de décalage - n'ont qu'une seule instance dans la liste. D'autres conditions peuvent avoir de multiples instances si la condition peut se produire plus d'une fois. Par exemple, une valeur de base de synchronisation peut avoir de multiple temps d'instance si l'élément de base de synchronisation a joué plusieurs intervalles et une valeur d'événement peut avoir de multiple temps d'instance si l'événement s'est produit plus d'une fois.

Les listes de temps d'instance de chaque élément sont initialisées quand le graphe temporel est initialisé et existent pendant toute la vie du graphe. Certains temps d'instance, tels que ceux définis par une valeur de décalage, restent dans la liste pour toujours, alors que d'autres peuvent y entrer et en sortir. Par exemple, les temps associés aux valeurs d'événement ne sont ajoutés que lorsque l'événement se produit et sont retirées quand l'élément est réinitialisé, comme décrit dans « La réinitialisation de l'état d'un élément ». De la même facon, les temps d'instance pour une valeur de base de synchronisation sont ajoutés à la liste à chaque création d'un nouvel intervalle pour l'élément base de synchronisation, mais ces temps d'instance ne sont pas retirés lors de la réinitialisation et restent dans la liste.

Quand le graphe temporel est réinitialisé, chaque élément essaye de créer un premier intervalle courant. Le temps de début est en général résolu, mais le temps de fin peut souvent être non résolu. Si l'élément peut redémarrer pendant qu'il est actif, l'intervalle courant peut se terminer (tôt) au prochain temps de début. Cet intervalle jouera et, quand il se terminera, l'élément examinera les listes de temps d'instance de début et de fin. Si l'élément devait à nouveau être joué, un autre intervalle sera créé et ce nouvel intervalle devient l'intervalle courant. L'histoire d'un élément peut être vu comme un ensemble d'intervalles.

Comme les temps de début et de fin peuvent dépendre d'autres temps pouvant changer, l'intervalle courant peut changer au cours du temps. Par exemple, si l'une quelconque des instances de temps de fin change pendant que l'intervalle courant est joué, la fin de l'intervalle courant sera recalculée et peut changer. Néanmoins, une fois qu'un temps a eu lieu, il est fixé. Ainsi, une fois que l'intervalle courant a commencé, son temps de début ne peut plus changer et une fois que l'intervalle courant s'est terminé, le temps de fin ne peut plus changer. Pour qu'un élément puisse redémarrer, il doit terminer son intervalle courant puis en créer un nouveau pour effectuer le redémarrage.

Quand une condition de début ou de fin définit une dépendance temporelle à un autre élément (par exemple, avec une valeur de base de synchronisation), la dépendance temporelle est généralement considéré comme une relation entre les deux éléments. Ce niveau de dépendance est important pour le modèle quand un élément crée un nouvel intervalle courant. Cependant, pour les besoins de la propagation des changements aux temps individuels, les dépendances temporelles sont plus spécifiquement une dépendance d'un intervalle de l'élément de base de synchronisation donné à un temps d'intance particulier dans une des listes de temps d'instance de l'élément dépendant. Comme seuls les temps de début et de fin de l'intervalle courant peuvent changer, seul l'intervalle courant générera des indications de changement de temps et les propagera aux temps d'instance dépendante.

Quand cette section fait référence à des temps de début et de fin pour un élément, les temps sont décrits comme faisant partie de l'espace de durée simple du parent. Tous les arcs de synchronisation, les arcs d'événement, les valeurs d'horloge de temps réel, etc. doivent être convertis dans cet espace de temps pour une comparaison facile. Ceci est spécialement important quand on fait référence à des temps de début « avant 0 », ce qui suppose que "0" est le début de la durée simple du parent. Le modèle ne dépend pas de cette définition - par exemple, une implémentation pourrait tout effectuer dans le temps global du document.

Les boucles dans le graphe temporel doivent être détectées et cassées pour permettre un bon fonctionnement de l'implémentation. Un modèle pour y parvenir dans le cas général est décrit (cela peut s'appliquer aussi à SMIL 1.0). Un mécanisme de gestion de certaines dépendances cycliques utiles découle du modèle.

Le reste de cette section détaille la sémantique des listes des temps d'instance, du cycle de vie d'un élément et des mécanismes de gestion des relations et des cycles de dépendance.

Les listes des temps d'instance

Cette section est normative.

Des listes d'instances sont associées à chaque élément et existent pour la durée du document (i.e., il n'y a pas de cycle de vie pour les listes d'instances). Les listes d'instances peuvent changer et parfois des temps peuvent être ajoutés ou retirés, mais les listes de temps d'instance de début et de fin sont persistantes.

Chaque élément peut avoir un attribut begin qui défini une ou plusieurs conditions qui peuvent démarrer l'élément. De plus, le modèle temporel décrit un ensemble de règles pour déterminer la fin de l'élément, incluant les effets d'un attribut end qui peut avoir plusieurs conditions. De facon à calculer les temps qui devraient être utilisés pour un intervalle donné de l'élément, nous devons convertir les temps de début et de fin dans le temps simple du parent, trier chaque liste de temps (indépendamment) et enfin trouver un couple de temps approprié pour définir un intervalle.

Les temps d'instance peuvent être résolus ou non. Dans le cas de la liste de fin, une valeur spéciale supplémentaire "indefinite" est autorisée. Les listes sont maintenues dans l'ordre de tri, avec les "indefinite" triés placés après tous les autres temps résolus et les temps non-résolus triés à la fin de la liste.

Pour les débuts, l'interprétation de la liste est directe, puisque les temps de début sont basés sur les conditions de l'attribut ou sur la valeur par défaut s'il n'y a pas d'attribut begin. Cependant, quand une condition de début est une valeur de base de synchronisation, l'élément de base de synchronisation peut avoir plusieurs intervalles et l'on doit prendre en compte cela dans la liste des temps de débuts associée aux conditions.

Pour les fins, le cas est un peu plus complexe, puisque les conditions de fin ne forment qu'une partie du calcul de la fin d'une durée active. Les listes d'instances de temps de fin sont utilisées ensemble avec les autres sémantiques de temporisation de SMIL pour calculer le temps de fin effectif pour un intervalle.

Si une instance de temps était définie comme valeur de base de synchronisation, l'instance de temps maintiendra une relation de dépendance temporelle avec l'intervalle associé pour l'élément de base de synchronisation. Cela signifie que si le temps de début ou de fin associé à l'intervalle de base de synchronisation courant change, alors le temps de l'instance dépendante change également.

Quand un élément crée un nouvel intervalle, il prévient les dépendants temporels et leurs fournit les temps de début et de fin qui ont été calculés en fonction de la sémantique décrite dans « Le calcul de la durée active ». Chaque élément dépendant va créer un nouveau temps d'instance attaché (i.e., avec une relation de dépendance) au nouvel intervalle courant de base de synchronisation.

La construction des listes de temps d'instance

La traduction des conditions de début ou de fin en temps d'instance dépend du type de condition :

S'il n'y a aucun attribut, les valeurs de début par défaut doivent être évaluées. Pour les enfants d'un élément par, cela est équivalent à une valeur de décalage de 0 et produit une valeur de temps d'instance persistante. Pour les enfants d'un élément excl, ceci est équivalent à "indefinite" et donc ne produit pas de temps d'instance.

Si un appel à une méthode du DOM est fait pour le début ou la fin de l'élément (beginElement(), beginElementAt(), endElement() ou endElementAt()), chaque appel de méthode crée temps d'instance (dans la liste des temps d'instance appropriée). Ces temps d'instance sont effacés lors d'une réinitialisation comme pour les temps d'événements. Voir « La réinitialisation de l'état d'un élément ».

Quand un nouveau temps d'instance est ajouté à la liste de débuts, l'intervalle courant va évaluer la sémantique de redémarrage et peut ignorer ce nouveau temps ou il peut terminer l'intervalle courant (ceci est détaillé dans « L'interaction avec la sémantique de restart »). Par contre, quand un temps d'instance dans une liste de débuts change parce que le temps de base de synchronisation (de l'intervalle courant) change, cela ne fait pas appel à la sémantique de redémarrage, mais peut changer le temps de début courant : si l'intervalle courant n'a pas encore démarré, le changement d'un temps d'instance dans la liste de débuts implique la réévaluation des listes de temps d'instance de début, qui peut impliquer un changement du temps de début de l'intervalle. Si le temps de début de l'intervalle change, un avis de changement de temps doit être propagé à tous les dépendants et la fin de l'intervalle courant doit aussi être réévaluée.

Quand un nouveau temps d'instance est ajouté à la liste de fins, ou quand un temps d'instance change dans la liste de fins, l'intervalle courant va réévaluer son temps de fin. Si cela change, il doit en informer les les dépendants.

Si un élément a déjà joué tous ses intervalles, il peut ne plus y avoir d'intervalle courant. Dans ce cas, les ajouts dans n'importe quelle liste de temps d'instance aussi bien que le changement de tout temps d'instance impliquent que l'élément réévalue les listes comme il devrait le faire à la fin de chaque intervalle (comme décrit ci-dessous dans « La fin d'un intervalle »). Cela peut, ou non, conduire à la création d'un nouvel intervalle pour l'élément.

Quand des temps sont ajoutés aux listes de temps d'instance, ils peuvent, ou non, être résolus. S'ils sont résolus, ils seront convertis dans l'espace de temps simple du parent. Si une instance de temps passe de non résolue à résolue, elle sera convertie de la même manière.

Il y a une différence entre un temps d'instance non résolu et une condition de début ou de fin qui n'a pas d'instance associée. Si, par exemple, une condition de valeur d'événement est spécifiée dans un attribut end, mais qu'un tel événement ne s'est pas produit, il n'y aura pas de temps d'instance associé dans la liste de fins. Cependant, si une condition de valeur de base de synchronisation est spécifiée pour end et si l'élément de base de synchronisation a un intervalle courant, il y aura un temps d'instance associé dans la liste de fins. Comme la condition de valeur de base de synchronisation peut être liée à la fin de l'élément de base de synchronisation et que la fin de l'intervalle courant de la base de synchronisation peut ne pas être résolue, le temps d'instance associé dans la liste de fins peut ne pas être résolu. Une fois que l'intervalle courant de la base de synchronisation se termine, le temps d'instance dépendante dans la liste de fins recevra un avis de changement de temps pour la résolution de la fin de l'intervalle de base de synchronisation. Le temps d'instance dépendante va ensuite convertir cette nouvelle valeur de base de synchronisation résolue dans le temps simple de son parent. Si les listes d'instances n'incluaient pas les temps d'instance non résolus, un mécanisme supplémentaire devrait être défini pour ajouter les temps d'instance de fin quand l'intervalle courant de l'élément de base de synchronisation s'est effectivement terminé et a résolu son temps de fin.

La liste de temps résolus inclut les temps historiques définis par rapport aux éléments de base de synchronisation et ainsi peut grossir au court du temps si la base de synchronisation a beaucoup d'intervalles. Les implémentations peuvent filtrer la liste de temps pour une optimisation, tant que cela ne modifie pas la sémantique définie ici.

Les principes de construction et d'élagage des intervalles

Cette section est informative.

L'ensemble de principes qui suit est à l'origine du modèle d'intervalle. Ce n'est pas un modèle complet - le but est de fournir une vue supplémentaire du modèle.

Nous définissons tout d'abord les termes d'élagage et de coupe d'un intervalle - ces concepts ne doivent pas être confondus.

Dans certains cas, après qu'un intervalle a été créé, il doit plus tard être élagué (effacé/retiré du graphe temporel) quand plus d'informations sont connues et que les contraintes de sémantique doivent être appliquées. Quand un intervalle est élagué, il ne sera pas montré, il ne déclenchera pas d'événement de début ni de fin et tous les temps d'instance associé pour les dépendants temporels de base de synchronisation doivent être retirés des listes de temps d'instance respectives. C'est comme si l'intervalle élagué n'avait pas été spécifié.

Dans d'autres cas, en particulier ceux liés à des temps de débuts négatifs par rapport aux conteneurs de temps parents, un intervalle valide pour un enfant ne peut être montré, même si celui-ci respecte les contraintes de temps imposées par le parent. Par exemple :

<par begin="-10s" dur="20s">
   <img id="slide1" src="slide1.jpg" dur="3s" />
   <img id="slide2" src="slide2.jpg" begin="slide1.end+3s" dur="10s" />
   <img id="note1" src="note1.jpg" begin="slide1.beginEvent" dur="20s" />
</par>

L'image "slide1" sera découpée, mais pas élaguée. Elle est découpée car l'élément par ne peut avoir commencé 10 secondes avant son conteneur de temps parent et, à la place, va commencer à 0 seconde dans le temps de son parent, synchronisé à 10 secondes dans sa durée simple. L'image "slide1" va commencer et finir avant 10 secondes dans le par et ainsi ne peut être montrée et est « découpée ». Les intervalles qui sont « découpés » ne sont pas montrés et ne déclenchent pas d'événement de début ni de fin, mais créent tout de même des temps d'instance valides pour tous les dépendants temporels de base de synchronisation. Par contre, l'image "slide2" va être montrée (l'intervalle va de moins 4 secondes à 6 secondes ), mais "note1" ne sera pas montré.

Les principes jetant les bases du modèle de cycle de vie d'un intervalle sont :

  1. Essayer de construire l'intervalle courant aussitôt que possible ;
    1. Le « prochain » intervalle ne peut être calculé qu'à la fin de l'intervalle courant.
  2. Ne changer aucun temps d'intervalle passé. Ne pas élaguer un intervalle qui a déjà commencé. Notez que cela se rapporte aux intervalles et pas aux temps d'instance ;
  3. Lors de la construction d'un intervalle à partir d'un jeu de temps d'instance, si la durée est résolue et négative, rejeter l'intervalle ; ne pas propager l'intervalle aux dépendants temporels ;
    1. Quand l'intervalle courant n'a pas encore commencé, si les temps de l'intervalle changent de telle façon que la durée devienne négative, élaguer l'intervalle.
  4. Lors de la construction d'un intervalle à partir d'un jeu de temps d'instance, si la fin est résolue et est <= 0 (dans la durée simple du parent), rejeter l'intervalle ; ne pas propager l'intervalle aux dépendants temporels ;
    1. Quand l'intervalle courant n'a pas encore commencé, si les temps de l'intervalle changent de telle façon que la fin soit <= 0, élaguer l'intervalle.
  5. Lors de la construction d'un intervalle à partir d'un jeu de temps d'instance, si le début de l'intervalle est >= à la fin (résolue) simple du conteneur de temps parent, rejeter l'intervalle ;
    1. Quand l'intervalle courant n'a pas encore commencé, si les temps de l'intervalle changent de telle façon que le début soit >= à la fin simple du conteneur de temps parent, élaguer l'intervalle ;
    2. Quand l'intervalle courant n'a pas encore commencé, si le temps de fin simple du parent change de telle façon que le début de l'intervalle courant soit >= à la fin simple du conteneur de temps parent, élaguer l'intervalle.

Une implication du principe 5 est que nous n'auront pas d'intervalle avec un temps de début non résolu, puisque ceux-ci vont obligatoirement se comparer (>=) à la fin simple du parent.

Le cycle de vie d'un élément

Cette section est normative.

Le cycle de vie d'un élément peut se résumer par les étapes suivantes :

  1. Démarrage - Obtenir le premier intervalle
  2. En attendant de commencer l'intervalle courant
  3. Temps actif - jouer un intervalle
  4. Fin d'un intervalle - calculer le prochain intervalle et informer les dépendants
  5. Après la durée active - effectuer tout remplissage et attendre un éventuel intervalle suivant

Les étapes 2 à 5 peuvent boucler autant de fois qu'il y a d'intervalles définis avant la fin de la durée simple du parent. À tout moment de l'étape 2, le temps de début pour l'intervalle courant peut changer et à tout moment au cours des étapes 2 ou 3, le temps de fin de l'intervalle courant peut changer. Quand l'un ou l'autre se produit, les changements sont propagés aux dépendants temporels.

Quand le document et le graphe temporel associé sont initialisés, les listes d'instances sont vides. Les valeurs de décalage simples et toute valeur "indefinite" dans un attribut end peuvent être ajoutées aux listes respectives durant l'initialisation, car elles sont indépendantes du temps de début du temps simple des parents.

Quand un élément a joué toutes les instances autorisées, on peut le considérer comme coincé à l'étape 5. Cependant, tout changement dans les listes d'instances pendant cette période renvoie l'élément à l'étape 4 et entraîne la création d'un nouvel intervalle courant.

Démarrage - Obtenir le premier intervalle

Le cycle de vie d'un élément commence avec le début de la durée simple du conteneur de temps parent de l'élément. En fait, à chaque fois que le conteneur parent (et plus généralement, tout conteneur de temps ascendant) se répète ou redémarre, l'élément se réinitialise (voir aussi « La réinitialisation de l'état d'un élément ») et commence une nouvelle « vie ».

Trois choses sont importantes à propos du début du cycle de vie :

  1. Tous les temps résolus définis comme valeurs d'événement, valeurs de répétition, valeurs de clé d'accès ou ceux ajoutés via un appel à une méthode de DOM sont effacés ;
  2. Tous les temps résolus définis comme valeurs de base de synchronisation, valeurs de synchronisation d'horloge de temps réel ou valeurs de marqueur de média doivent être reconvertis de l'espace temporel de base de synchronisation dans l'espace de temps simple du parent ;
  3. Le premier intervalle courant est calculé.

L'action 1) est aussi décrite dans « La réinitialisation de l'état d'un élément ». Cette action se produit aussi à chaque fois qu'un élément redémarre, bien que, dans ce cas, l'élément ne doive pas effacer un temps d'événement qui définit le début courant de l'intervalle.

L'action 2) met simplement à jour les valeurs pour refléter les relations de synchronisation courantes de la durée simple du parent avec le reste du document.

La troisième action nécessite une attention particulière pour les listes de temps, mais reste relativement directe. Elle est similaire, mais pas identique, à l'action effectuée quand l'élément se termine (ceci est décrit dans « La fin d'un intervalle »). L'idée de base est de trouver le premier intervalle pour l'élément et d'en faire l'intervalle courant. Le modèle doit gérer trois cas limites :

  1. L'élément peut commencer avant le temps de début simple du parent (i.e., avant 0 dans le temps simple du parent) et, ainsi, apparaître comme commençant au milieu de son plan de montage chronologique (un peu comme l'effet de clipBegin sur un élément média). Le modèle doit gérer les temps de début avant le début du parent ;
  2. L'élément a un ou plusieurs intervalles définis qui commencent et se terminent avant le début simple du parent (i.e., avant 0). Ceux-ci doivent être filtrés et écartés du modèle ;
  3. L'élément a un ou plusieurs intervalles définis qui commencent après la fin simple du parent. Ceux-ci doivent être filtrés et écartés du modèle. Notez que si la fin simple du parent est non résolue, tout temps de début résolu arrive avant la fin simple du parent.

La définition stricte du premier intervalle acceptable pour l'élément est le premier intervalle qui se finisse après le début simple du parent et qui commence avant la fin simple du parent. Voici un pseudo-code pour obtenir le premier intervalle pour un élément. On suppose un type abstrait "Time" qui dispose d'une fonction de comparaison. Cela peut être une valeur numérique résolue, la valeur spéciale INDEFINITE (utilisée uniquement avec end) et cela peut être la valeur spéciale UNRESOLVED. La valeur INDEFINITE est « est plus grande que » toute valeur résolue et UNRESOLVED est « est plus grande que » les valeurs résolues et la valeur INDEFINITE. Le code utilise les listes de temps d'instance associées aux attributs begin et end, comme décrit dans la section précédente.

// Utility function that returns true if the end attribute specification
// includes conditions that describe event-values, repeat-values or accesskey-values.
boolean endHasEventConditions();
// Calculates the first acceptable interval for an element
// Returns:
//    Interval if there is such an interval
//    FAILURE if there is no such interval
Interval getFirstInterval()
{
Time beginAfter=-INFINITY;

while( TRUE ) // loop till return
{
   Set tempBegin = the first value in the begin list that is >= beginAfter.
   If there is no such value  // No interval
      return FAILURE;

   If tempBegin >= parentSimpleEnd // Can't begin after parent ends
      return FAILURE;

   If there was no end attribute specified
      // this calculates the active end with no end constraint
      tempEnd = calcActiveEnd( tempBegin );
   else
   {
      // We have a begin value - get an end
      Set tempEnd = the first value in the end list that is >= tempBegin.
      // Allow for non-0-duration interval that begins immediately
      // after a 0-duration interval.
      If tempEnd == tempBegin && tempEnd has already been used in 
	an interval calculated in this method call
      {
	 set tempEnd to the next value in the end list that is > tempEnd
      } 	
      If there is no such value
      {
	 // Events leave the end open-ended. If there are other conditions
	 // that have not yet generated instances, they must be unresolved.
	 if endHasEventConditions()
	    OR if the instance list is empty
	    tempEnd = UNRESOLVED;
	 // if all ends are before the begin, bad interval
	 else
	    return FAILURE;
      }
      // this calculates the active dur with an end constraint
      tempEnd = calcActiveEnd( tempBegin, tempEnd );
   }

   // We have an end - is it after the parent simple begin? errata-E14
   if( tempEnd > 0 )
      return( Interval( tempBegin, tempEnd ) );

   else
      // Change beginAfter to find next interval, and loop
      beginAfter = tempEnd;

} // close while loop

} // close getFirstInterval

Notez que l'on pourrait considérer le cas restart=always séparément de restart=whenNotActive, cela demanderait juste plus de travail car il nous faut trouver un intervalle qui commence après tempEnd.

Si le modèle ne produit pas de premier intervalle pour l'élément, celui-ci ne commencera jamais et il n'y a donc rien de plus à faire pour l'instant. Cependant, s'il y a un intervalle valide, l'élément doit informer tous les dépendants temporels qu'il y a un nouvel intervalle de l'élément. C'est un avis de cet élément vers tous les éléments qui sont directement dépendants temporellement. Ceci est différent de la propagation d'un changement de temps.

Quand un élément dépendant reçoit un avis de « nouvel intervalle », cela inclus une référence au nouvel intervalle. Le nouvel intervalle aura en général un temps de début résolu, et peut avoir un temps de fin résolu. Un temps d'instance correspondant va être ajouté à la liste de temps d'instance de début, ou de fin, pour l'élément dépendant et ce nouveau temps d'instance va maintenir une relation de dépendance temporelle avec l'intervalle de base de synchronisation.

En attendant de commencer l'intervalle

Cette période ne survient que si l'intervalle courant ne commence pas immédiatement quand celui-ci est créé (ou avant qu'il ne le soit). Pendant qu'un intervalle attend pour commencer, tout changement des temps de l'intervalle courant de l'élément de base de synchronisation sera propagé aux listes d'instances et peut occasionner un changement de l'intervalle courant.

Si l'élément reçoit un avis de nouvel intervalle pendant qu'il attend de commencer, il va ajouter le temps associé (i.e., le temps de début ou de fin de l'intervalle de base de synchronisation) à la liste des temps résolus correspondante.

Quand un temps d'instance change, ou quand un nouveau temps d'instance est ajouté à l'une des listes, l'élément va ré-évaluer le temps de début, ou de fin, de l'intervalle courant (en utilisant l'algorithme décrit dans la section précédente). Si cette réévaluation produit un changement de l'intervalle, les avis de changement de temps seront envoyés aux dépendants associés.

Il est possible, pendant cette étape, que les temps de début et de fin puisse changer de telle façon que l'intervalle ne commence jamais (par exemple, la fin de l'intervalle se situe avant son début). Dans ce cas, l'intervalle doit être élagué et tous les temps d'instance des dépendants doivent être retirés des listes d'instances respectives des éléments dépendants. Ces changements sur les listes d'instances vont provoquer une réévaluation des intervalles courants des éléments dépendants, de la même facon que le ferait un temps d'instance modifié.

Une exception au fonctionnement normal a lieu pour les éléments qui sont différés d'après la sémantique d'interruption de l'élément excl : un élément différé ignore les changements propagés à son temps de début. Ceci est détaillé dans la section « Les éléments différés et la propagation des changements sur le début ».

Temps actif - jouer un intervalle

Cette période survient quand l'intervalle courant est actif (i.e., une fois qu'il a commencé et jusqu'à ce qu'il se termine). Pendant cette période, le temps de fin de l'intervalle peut changer, mais le temps de début ne le peut pas. Si un temps d'instance change dans la liste de débuts après que l'intervalle courant a commencé, le changement n'affectera pas l'intervalle courant. C'est différent du cas de l'ajout d'un nouveau temps d'instance à la liste de débuts qui peut provoquer un redémarrage.

Si l'élément reçoit un avis de « nouvel intervalle » pendant qu'il est actif, il ajoutera le temps associé (i.e., le temps de début ou de fin de l'intervalle de base de synchronisation) dans la liste correspondante de temps résolus. Si le nouvel intervalle ajoute un temps à la liste de débuts, la sémantique de redémarrage est appliquée et cela peut terminer l'intervalle courant.

Si l'attribut restart vaut "always", alors l'intervalle courant sera terminé en avance s'il y a un temps d'instance dans la liste de débuts qui est avant (i.e., plus tôt que) la fin définie de l'intervalle courant. Terminer de cette manière déclenchera aussi l'envoi d'un signal de changement de temps à tous les dépendants temporels pour l'intervalle courant. Voir aussi « L'interaction avec la sémantique de restart ».

Fin d'un intervalle

Si un élément spécifie restart="never", alors aucune autre action n'est faite à la fin de l'intervalle et l'élément se retrouve dans l'état « post intervalle », à moins et jusqu'à ce qu'un conteneur de temps ascendant ne redémarre ou se répète.

Si un élément spécifie d'autres valeurs pour restart, quand l'intervalle courant se termine, l'élément doit reconsidérer les listes de débuts et de fins résolus. S'il y a un autre intervalle autorisé défini pour commencer à la fin, ou juste après la fin, du précédent, un nouvel intervalle est créé. Quand un nouvel intervalle est créé, il devient l'intervalle courant et un avis de nouvel intervalle est envoyé à tous les dépendants temporels.

L'algorithme utilisé est très similaire à celui utilisé à l'étape 1, sauf que nous cherchons à trouver un intervalle qui commence après la fin la plus récente.

// Calculates the next acceptable interval for an element
// Returns:
//    Interval if there is such an interval
//    FAILURE if there is no such interval
Interval getNextInterval()
{
// Note that at this point, the just ended interval is still the "current interval"
Time beginAfter=currentInterval.end;

   Set tempBegin = the first value in the begin list that is >= beginAfter. errata-E15
   If there is no such value  // No interval
      return FAILURE;

   If tempBegin >= parentSimpleEnd // Can't begin after parent ends
      return FAILURE;

   If there was no end attribute specified
      // this calculates the active end with no end constraint
      tempEnd = calcActiveEnd( tempBegin );
   else
   {
      // We have a begin value - get an end
      Set tempEnd = the first value in the end list that is >= tempBegin.
      // Allow for non-0-duration interval that begins immediately
      // after a 0-duration interval.
      If tempEnd == currentInterval.end
      {
	 set tempEnd to the next value in the end list that is > tempEnd
      } 	
      If there is no such value
      {
	 // Events leave the end open-ended. If there are other conditions
	 // that have not yet generated instances, they must be unresolved.
	 if endHasEventConditions()
	    OR if the instance list is empty
	    tempEnd = UNRESOLVED;
	 // if all ends are before the begin, bad interval
	 else
	    return FAILURE;
      }
      // this calculates the active dur with an end constraint
      tempEnd = calcActiveEnd( tempBegin, tempEnd );
   }

   return( Interval( tempBegin, tempEnd ) );

} // close getNextInterval
Après la durée active

Cette période peut s'étendre de la fin d'un intervalle jusqu'au début du suivant, ou jusqu'à la fin de la durée simple du parent ( celle qui survient en premier). Pendant cette période, tout comportement de remplissage est appliqué à l'élément. Les temps pendant cet intervalle ne peuvent plus changer. Les implémentations peuvent choisir, pour optimisation, de casser les relations de dépendances temporelles puisqu'elles ne peuvent plus produire de changement.

L'interaction avec la sémantique de restart

Il y a deux cas dans lesquels la sémantique de restart doit être prise en compte :

  1. Quand l'intervalle courant est joué, si restart="always", alors tout temps d'instance ( appelé T ) de la liste de débuts qui est après (i.e., plus tard que) le début de l'intervalle courant, mais plus tôt que la fin de l'intervalle courant, va provoquer la fin de l'intervalle courant au temps T. C'est la première étape dans le redémarrage de l'élément : quand l'intervalle courant se termine, ce qui finalement va créer un intervalle suivant ;
  2. Quand un nouveau temps d'instance est ajouté à la liste de débuts, les règles de redémarrage s'appliquent. Les nouveaux temps d'instance peuvent provenir d'une condition de début qui spécifie une des conditions de valeur de base de synchronisation, pour laquelle un avis de nouvelle instance est reçu. Cela peut aussi provenir d'une condition de début qui spécifie une des conditions de valeur d'événement, pour laquelle l'événement associé se produit.
    Dans tous les cas, les paramètres de redémarrage et l'état de l'intervalle courant contrôlent le comportement résultant. Le nouveau temps d'instance est calculé (par exemple, à partir du temps de l'intervalle courant de base de synchronisation ou du temps d'un événement ou encore d'un décalage) et ajouté à la liste de débuts. Alors :
Les dépendances cycliques dans le graphe temporel

Il y a deux types de cycles qui peuvent être créés avec SMIL 2.0 : les cycles fermés et les cycles ouverts, ou cycles de propagation. Un cycle fermés apparaît quand un ensemble d'éléments a des conditions mutuellement dépendantes temporellement et qu'aucune autre condition sur les éléments affectés ne peut affecter ou changer cette relation de dépendance, comme dans les exemples 1 et 2 ci-dessous. Un cycle ouvert, ou cycle de propagation, apparaît quand un ensemble d'éléments a des conditions mutuellement dépendantes temporellement, mais au moins une des conditions engagées a plus d'une condition résolue. Si un seul des éléments dans le cycle peut générer plus d'un intervalle, le cycle peut se propager. Dans certains cas, tel que celui décrit dans l'exemple 3, cela peut être très utile.

Les temps définis dans un cycle fermé sont non résolus, à moins que certains mécanismes externes ne viennent résoudre l'une des valeurs de temps d'un élément (par exemple, un appel à une méthode DOM ou le suivi d'un lien hypertexte ciblant l'un des éléments). Si cela se produit, le temps résolu va se propager à travers le cycle, résolvant toutes les valeurs de temps associées.

Les cercles fermés sont une erreur et peuvent entraîner l'échec de tout le document. Dans certaines implémentations, des éléments dans le cycle peuvent juste ne pas pouvoir commencer ou se terminer correctement. Les exemples 1 et 2 décrivent le comportement le plus tolérant, mais les implémentations peuvent simplement rejeter un document contenant un cycle fermé.

La détection des cycles

Les implémentations peuvent détecter les cycles dans le graphe temporel en utilisant un drapeau visité sur chaque élément dans le fonctionnement de propagation des changements de temps. Au fur et à mesure que l'avis de changement de temps est propagé, les éléments dépendants sont marqués comme ayant été visités. Si le changement d'un temps d'instance dépendante implique un changement de l'intervalle courant pour cet élément, ce changement va se propager à son tour à ses dépendants. Ce second avis chaîné se produit dans le contexte du premier avis de changement de temps qui l'a causé. L'effet est comme une pile qui se construit alors que les changements se propagent à travers le graphe et ensuite se se déconstruit quand tous les changements ont été propagés. S'il y a un cycle de dépendances, le chemin de propagation va traverser deux fois un élément pendant une chaîne de propagation donnée. Cette technique est courante dans les parcours des graphes.

Une approche similaire peut être utilisée quand on construit les chaînes de dépendances durant l'initialisation du graphe temporel et pendant la propagation des avis de nouvel intervalle - les variations sur ce thème seront spécifiques à chaque implémentation.

Quand un cycle est détecté, la propagation du changement est ignorée. L'élément qui détecte second passage ignore le second avis et ainsi casse le cycle.

Exemples

Exemple 1 : Dans l'exemple suivant, les 2 images définissent des temps de début qui sont mutuellement dépendants. Il n'y a aucun moyen de résoudre cela et donc les images ne commenceront jamais.

<img id="foo" begin="bar.begin" .../>
<img id="bar" begin="foo.begin" .../>

Exemple 2 : Dans l'exemple suivant, les 3 images définissent un cycle moins évident de temps de début et de fin mutuellement dépendants. Il n'y a aucun moyen de résoudre cela. L'image "joe" va commencer mais ne se terminera jamais et les images "foo" et "bar" ne commenceront jamais.

<img id="foo" begin="joe.end" .../>
<img id="bar" begin="foo.begin" dur="3s" .../>
<img id="joe" begin="0" end="bar.end" .../>

Exemple 3 : Dans l'exemple suivant, les 2 images définissent des temps de début qui sont mutuellement dépendants, mais la première a plusieurs conditions de début qui permettent au cycle de se propager. L'image "foo" sera d'abord affichée de 0 à 3 secondes, avec la seconde image "bar" affichée de 2 à 5 secondes. Quand chaque nouvel intervalle courant de "foo" et "bar" sont créés, ils vont ajouter un nouveau temps d'instance à la liste de débuts de l'autre élément et ainsi le cycle continue d'avancer. Comme sinon ce comportement de recouvrement « ping-pong » n'est pas facile à créer, ces types de cycles ne sont pas empêchés. En outre, le comportement exact tombera en-dehors du modèle décrit précédemment.

<img id="foo" begin="0; bar.begin+2s" dur="3s" .../>
<img id="bar" begin="foo.begin+2s" dur="3s" .../>

Exemple 4 : Dans l'exemple suivant, un cycle ouvert est décrit et se propage. Le comportement attendu ne s'écarte pas du modèle et n'est pas géré. Dans cet exemple, cependant, à chaque fois que le conteneur de temps parent se répète, les éléments video vont commencer une seconde plus tôt que pour l'itération précédente du conteneur parent. Ceci est dû au fait que les temps d'instance de début, associés aux conditions de valeurs de base de synchronisation, ne sont pas effacés quand le parent se répète. À la dernière itération du conteneur parent, les deux vidéos vont commencer si tôt qu'elles vont être entièrement découpées par les contraintes de début du conteneur.

<par dur="10s" repeatCount="11" >
   <video id="foo" begin="0; bar.begin-1s" dur="10s" .../>
   <video id="bar" begin="foo.begin-1s" dur="10s" .../>
</par>

La temporisation et le temps du monde réel

Cette section est informative.

Dans cette spécification, les éléments sont décrits comme ayant une « heure » locale. En particulier, de nombreux décalages sont calculés dans le temps simple du conteneur parent. Cependant, les durées simples peuvent être répétées et les éléments peuvent commencer et redémarrer de nombreuses façons.

Cette section est normative.

La temporisation d'un intervalle

Cette section est informative.

Le modèle de temporisation de SMIL suppose le modèle le plus répandu pour la temporisation d'un intervalle.

Cette section est normative.

Cette section est informative.

Cela est aussi appelé temporisation avec extrêmité finale exclue. Ce modèle fait que l'arithmétique des intervalles fonctionne correctement et fournit des modèles rationnels pour les séquences d'intervalles.

Les fondements rationnels

Dans le monde réel, cela est équivalent à la façon dont les secondes s'additionnent pour produire des minutes et les minutes des heures. Bien qu'une minute soit définie comme faisant 60 secondes, une horloge digitale ne montrera jamais plus de 59 secondes. Ajouter 1 seconde à "00:59" ne produit pas "00:60" mais "01:00", ou 1 minute et 0 seconde. Le temps de fin théorique de 60 secondes, qui décrit un intervalle d'une minute, est exclus de l'intervalle.

Dans l'univers des médias et des plans de montage chronologiques, la même chose s'applique : soit "A" une séquence vidéo, une séquence audio ou une animation. Supposons que "A" commence à 10 et joue jusqu'à 15 (quelle que soit l'unité - cela n'a pas d'importance ). Si "B" est défini pour suivre "A", alors il commence à 15 (et non pas à 15 plus un certain intervalle minimal). Quand l'environnement d'exécution rend effectivement des images (ou des échantillons audios) et doit jouer le temps 15, celui-ci ne devrait pas montrer à la fois une image de "A" et une de "B", mais plutôt ne montrer que le nouvel élément "B". C'est la même chose pour le son ou pour tout intervalle dans un plan de montage chronologique. Si le modèle n'utilise pas une temporisation avec extrêmité finale exclue, il va se créer des superpositions des images, ou des échantillons audio, des animations successives, etc.

Notez que les transitions de "A" vers "B" exploitent aussi le modèle de temporisation des intervalles. Celles-ci nécessitent absolument que "A" ne se termine pas effectivement à 15 et que les deux éléments se chevauchent effectivement. Néanmoins, la durée de "A" est simplement prolongée par la durée de transition (par exemple, 1 seconde). Cette nouvelle durée pour "A" est également exclusive de l'extrêmité finale - à la fin de cette nouvelle durée. La transition sera accomplie et seul "B" devrait être affiché - "A" ne sert plus.

Les implications pour le modèle temporel

Pour le modèle temporel, cela a plusieurs conséquences importantes : la définition de la répétition et l'état de l'élément quand il est « gelé ».

Lors de la répétition de la durée simple d'un élément, l'arithmétique suit le modèle avec extrêmité finale exclue. Voyez l'exemple :

<video dur="4s" repeatCount="4" .../>

Au temps 0, la durée simple vaut aussi 0 et la première image de la vidéo est affichée. C'est le début inclusif de l'intervalle. La durée simple se déroule normalement jusqu'à 4 secondes.

Cette section est normative.

En utilisant cela, un temps de 4 (ou 8 ou 12) correspond à un temps de 0 dans la durée simple. L'extrêmité finale de la durée simple est exclue de la durée simple (i.e., non échantillonnée dans celle-ci).

Pour la plupart des médias continus, cela correspond au modèle interne du média et ainsi, aucune image (ou échantillon audio) n'est jamais exclue. Cependant, pour les médias avec un plan de montage chronologique échantillonné (comme les animations), la distinction est importante et nécessite une sémantique spécifique pour les éléments gelés.

L'effet de cette sémantique sur les fonctions d'animation est détaillé dans le module [SMIL-ANIMATION].

La sensibilité des événements

Cette section est informative.

Le modèle de temporisation de SMIL 2.0 gère une synchronisation basée sur des événements imprévisibles, tels que les événements DOM ou les événements générés par l'interface utilisateur. Le modèle pour la gestion des événements est que la notification de l'événement est livrée à l'élément de temporisation et que l'élément de temporisation utilise un ensemble de règles pour résoudre toute synchronisation dépendant de l'événement. errata-E13

Cette section est normative.

La sémantique de la sensibilité des éléments aux événements est décrite par l'ensemble de règles suivant :

  1. Quand un conteneur de temps n'est pas actif (i.e., avant que le conteneur de temps ne commence ou après qu'il a terminé sa durée active), les éléments enfants ne répondent pas aux événements (selon le modèle temporel). Notez que pendant qu'un conteneur de temps parent est gelé, il n'est pas actif et donc les enfants ne gèrent pas les spécifications d'événements de début et de fin ;
    1. Si un élément et un conteneur de temps ascendant sont tous deux spécifiés pour commencer avec le même événement, le comportement n'est pas prévisible ( selon la sémantique des événements de DOM). Les auteurs sont priés de ne pas créer de tels cas.
  2. Si un élément n'est pas actif (le conteneur de temps parent étant lui actif), alors seuls les événements de début sont gérés. Ainsi, si un événement est déclenché et que l'attribut begin spécifie cet événement, l'élément commence. Pendant que l'élément n'est pas actif, toute spécification d'un événement par un attribut end est ignorée ;
  3. Si un élément est (déjà) actif quand un événement est déclenché et que cet événement est spécifié par un attribut begin, alors le comportement dépend de la valeur de l'attribut restart :
    1. Si restart="always", alors un nouveau temps de début est résolu pour l'élément en fonction du temps de l'événement. Toute spécification de l'événement dans l'attribut end est ignorée pour cette instance de l'événement ;
    2. Si restart="never" ou restart="whenNotActive", alors toute spécification de l'événement par l'attribut begin est ignorée pour cette instance de l'événement. Si l'attribut end spécifie cet événement, une valeur de fin est résolue à partir du temps de l'événement et la durée d'activité est ré-évaluée (selon les règles dans « Le calcul de la durée active »).

Il est important de noter qu'en aucun cas une seule occurence d'un événement ne sert à la fois à résoudre les temps de début et de fin d'un même élément.

Cette section est informative.

La règle 1a déconseille l'utilisation de cas tels que :

<smil ...>
...
<par id="bad_exemple" begin="link9.activateEvent">
   <img begin="link9.activateEvent" .../>
</par>
...
</smil>

Diverses approches alternatives peuvent être suivies. L'une des approches possibles est de définir l'élément descendant pour qu'il commence par rapport au début de son ascendant, comme dans l'exemple suivant (la règle de début pour l'image pourrait être plus simple, mais cela illustre le cas général) :

<smil ...>
...
<par id="better_exemple" begin="link9.activateEvent">
   <img begin="better_exemple.begin" .../>
</par>
...
</smil>

Les règles de sensibilité des événements peuvent être utilisées avec l'attribut restart pour décrire les cas d'utilisation pour une activation « en bascule », comme décrit dans la section « L'utilisation de restart pour une activation en bascule ».

Puisque la même instance d'un événement ne peut servir à résoudre à la fois les temps de début et de fin d'un même élément, l'utilisation qui suit peut ne pas sembler intuitive à certaines personnes :

<html ...>
...
<audio src="bounce.wav" begin="foo.click" 
	  end="foo.click+3s" restart="whenNotActive"/>
...
</html>

Cet exemple va commencer à répéter la séquence audio quand "foo" est cliqué et arrêter la séquence audio 3 secondes après que "foo" a été cliqué une seconde fois. Il serait faux d'interpréter cet exemple comme jouer la séquence audio pendant 3 secondes après que "foo" a été cliqué. Pour obtenir ce comportement, il faudrait utiliser le balisage suivant :

<html ...>
...
<audio src="bounce.wav" begin="foo.click" dur="3s"
	  restart="whenNotActive"/>
...
</html>
La sensibilité des événements de l'utilisateur et la temporisation

Le modèle de temporisation et le modèle des événements de l'utilisateur sont fortement divergents. Alors que le modèle de temporisation fait référence aux événements de l'utilisateur, il ne définit pas comment ces événements sont générés et, en particulier, ne définit pas les sémantiques de focus du clavier, de l'environnement de la souris, de « cliquabilité » et des questions y afférentes. Puisque la temporisation peut affecter la présentation des éléments, elle peut aussi influer sur les règles pour le traitement des événements de l'utilisateur, dans la mesure seulement où seule la présentation de l'élément est affectée.

En particulier, de nombreux modèles d'événements de l'utilisateur ne feront pas de distinction entre un élément qui est « en train de jouer » et un élément qui est « gelé ». Les effets de l'attribut fill ne s'appliquent qu'à la sémantique de temporisation. Si un élément est encore visible quand il est gelé, il se comporte normalement par rapport aux autres sémantiques, comme celle du traitement d'un événement de l'utilisateur. En particulier, des éléments comme a et area sont toujours sensibles aux activations par l'utilisateur (par exemple, un clic) quand ils sont gelés.

L'activation par lien comparée à l'activation par événement

Apparentée à l'activation par événement, il y a l'activation par lien. SMIL 1.0 définit la sémantique de l'hyperlien comme la recherche d'un document à un point dans le temps. Quand ils sont combinés avec une temporisation interactive (par exemple, begin="indefinite" ), les hyperliens offrent une variante pour l'interactivité du contenu avec l'utilisateur.

Cette section est normative.

Les détails sur les moments où les hyperliens activent un élément et et où ceux-ci explorent le plan de montage chronologique du document sont présentés dans la section « Les hyperliens et la temporisation ».

La conversion entre temps local et temps global

Cette section est normative.

Pour convertir le temps du document dans le temps local d'un élément, le temps original est converti en un temps simple pour chaque conteneur de temps, en descendant du conteneur de temps racine jusqu'au conteneur de temps parent de l'élément. Cet algorithme récursif permet un modèle simple de conversion à partir du temps simple du parent vers le temps simple et le temps actif de l'élément. La première étape consiste dans le calcul du temps actif de l'élément et la seconde dans celui du temps simple de l'élément.

Les étapes ci-dessus supposent que les temps associés soient résolus et non indéfinis. Si un temps requis n'est pas résolu ou est indéfini, alors la conversion n'est pas définie et ne peut être effectuée.

Le calcul du temps actif d'un élément

Le temps donné en entrée est dans le temps simple du parent. Il est normalisé dans la durée active de l'élément, en ajustant en fonction du décalage de synchronisation accumulé (décrit dans « Le décalage de synchronisation accumulé »).

Soit tps un temps dans le temps simple du parent, B le temps de début pour un élément et O le décalage de synchronisation accumulé pour un élément, mesuré dans le temps simple du parent.

Le temps actif de l'élément ta pour tous les éléments enfants est :

ta = tps - B - O
Le calcul du temps simple d'un élément

Le temps simple de l'élément est le temps qui est utilisé pour établir la synchronisation à l'exécution pour un élément média, ou pour calculer la valeur d'entrée d'une fonction d'animation ou d'un temps d'échantillonnage. Si l'élément est un conteneur de temps, c'est aussi le temps qui est vu par tous les enfants du conteneur (comme temps simple du conteneur de temps).

Pour calculer le temps simple de l'élément ts à partir du temps actif de l'élément ta, il faut tenir compte de tout comportement de répétition :

S'il n'y a pas de comportement de répétition :
ts = ta

Sinon, le temps simple de l'élément est juste calculé à partir du temps de début de l'itération la plus récente - appelons cela tlast-repeat. Certains autres mécanismes doivent noter quand la durée simple se termine et réinitialiser la valeur de tlast-repeat. Si l'élément ne s'est pas encore répété, une valeur de 0 est utilisée à la place de tlast-repeat.

ts = ta - tlast-repeat

Notez que la sémantique précédente couvre le cas spécial (idéal) où la durée simple dur est fixée et ne varie pas. Dans ce cas (et seulement dans ce cas) tlast-repeat peut être obtenu directement de la durée simple dur et ainsi l'expression peut être réduite à :

ts = REMAINDER( ta, dur )

avec REMAINDER( t, d ) défini comme (t - d*floor(t/d)).

La conversion des valeurs d'horloge réelle

Quand le document commence, le temps d'horloge réelle courant est noté et enregistré comme twallclock-begin. Pour convertir une valeur d'horloge twc en un temps simple actif d'un élément ts, il faut d'abord convertir twc dans le temps global du document tra (i.e., un temps actif d'élément pour le conteneur de temps racine) :

tra = twc - twallclock-begin

Ceci peut produire un temps négatif si la valeur d'horloge réelle est un temps d'avant le début du document. Néanmoins, c'est une valeur autorisée.

Le temps tra est ensuite converti normalement dans le temps actif de l'élément, ou le temps local de l'élément selon le besoin.

La conversion du temps d'un événement dans celui d'un élément

Les temps d'événement sont généralement estampillés avec un temps relatif au temps système ou à celui du début du document. La conversion est comme pour les valeurs d'horloge réelle, dans la mesure où le temps d'événement est converti dans le temps actif du conteneur de temps racine et ensuite converti normalement dans le temps de l'élément.

La conversion du temps d'un élément dans celui d'un autre élément

Pour convertir un temps d'élément vers un autre, le temps du premier élément te1 doit d'abord être converti dans le temps simple du conteneur ascendant le plus proche contenant les deux éléments. Convertir un temps d'élément vers un temps de conteneur de temps parent est l'inverse du processus décrit précédemment. Encore une fois, il s'agit d'une opération récursive et donc les conversions sont décrites de d'une manière générique à partir du temps simple d'un élément vers le temps actif de l'élément et à partir du temps actif de l'élément vers le temps simple de son parent.

Pour convertir à partir du temps simple d'un élément vers son temps actif, il faut le temps de début de l'itération la plus récente, tlast-repeat. Si l'élément ne se répète pas ou ne s'est pas encore répété, une valeur de 0 est utilisée à la place de tlast-repeat.

ta = ts + tlast-repeat

La conversion du temps actif de l'élément vers le temps simple du parent utilise le début associé de l'élément et le décalage de synchronisation accumulé.

tps = ta + B + O
Les conversions de temps et l'échantillonnage du graphe temporel

Notez que les conversions pures ne prennent pas en compte la constriction des durées actives, pas plus que les effets de remplissage (quand le temps est gelé). Les conversions de temps globaux vers des temps locaux, utilisées pour les traduction entre espaces temporels, doivent ignorer ces questions et, de cette façon, peuvent produire un temps dans l'espace temporel local de destination qui se situe bien avant ou bien après la durée simple de l'élément.

Une forme alternative de la conversion est utilisée lorsque l'on échantillonne effectivement le graphe temporel. Un conteneur de temps n'est échantillonné que s'il est actif ou gelé et, ainsi, aucun temps ne sera produit se situant avant qu'un conteneur de temps ne commence. Si la conversion de temps global vers temps local pour un conteneur de temps produit un temps pendant lequel le conteneur est gelé, le temps est contraint à la valeur de la fin active.

Les hyperliens et la temporisation

Cette section est informative.

La sémantique des hyperliens doit être spécifiquement définie dans le modèle temporel afin d'assurer un comportement prévisible. Les sémantiques d'hyperlien antérieures, telle que celle définie par SMIL 1.0, ne suffisent pas car elles ne gèrent pas les temps non résolus ni les restrictions de redémarrage forcés par l'auteur. Nous avons étendu la sémantique de SMIL 1.0 pour une utilisation dans les présentations, avec des éléments utilisant une temporisation non résolue (y compris une temporisation interactive) et les restrictions de redémarrage forcés par l'auteur.

Cette section est normative.

Un hyperlien peut cibler un élément en spécifiant la valeur de l'attribut id d'un élément dans la partie fragment du localisateur du lien. Le suivi d'un hyperlien qui référence un élément temporel va entraîner un comportement qui obéit aux règles suivantes :

  1. Si l'élément cible est actif, chercher dans le temps du document en remontant jusqu'au temps de début de l'intervalle de l'élément ;
  2. Sinon, si le temps de début de l'élément cible est résolu (i.e., il y a au moins un intervalle défini pour l'élément), chercher dans le temps du document (en avant ou en arrière, c'est selon) le temps de début du premier intervalle de l'élément cible. Notez que le temps de début peut être résolu du fait d'une activation précédente d'un hyperlien, du DOM ou d'un événement. Une fois le temps de début résolu (et jusqu'à ce que l'élément soit réinitialisé, par exemple, quand le parent se répète), la recherche se poursuit. Pour des détails à propos de la réinitialisation, voir « La réinitialisation de l'état d'un élément ». Notez aussi que, pour que le début d'un élément soit résolu, le temps de début de tous les éléments ancêtres doit aussi être résolu ;
  3. Sinon (i.e., il n'y a pas d'intervalle défini pour l'élément), le temps de début de l'élément cible doit être résolu. Cela peut nécessiter une recherche et/ou une résolution des éléments ancêtres également. Cela est fait récursivement à partir de l'élément cible jusqu'au plus proche ancêtre ayant un temps de début résolu. Ensuite, la récursion « se déroule », et, pour chaque ancêtre à tour de rôle (en-dessous de l'ancêtre résolu) ainsi que pour l'élément cible, les étapes suivantes sont réalisées :
    1. Si le temps de début de l'élément est résolu, chercher dans le temps du document (en avant ou en arrière, c'est selon) le temps de début du premier intervalle de l'élément cible ;
    2. Sinon (si le temps de début n'est pas résolu), résoudre simplement le temps de début de l'élément au temps courant dans son conteneur de temps parent (suivant la position courante dans le document). Ne pas s'occuper des bases de synchronisation ou d'événement de l'élément et ne pas propager « en arrière » de logique de temporisation pour résoudre l'élément, mais plutôt le traiter comme s'il était défini avec begin="indefinite" et simplement résoudre le temps de début par rapport au temps courant du parent. Cela devrait créer un intervalle et se propager aux dépendants temporels.

Dans les règles ci-dessus, la contrainte supplémentaire doit aussi être respectée :

  1. Si un temps de début devant être utilisé comme cible recherchée se produit avant le début du conteneur de temps parent, le temps cherché est contraint au temps de début du conteneur de temps parent. Cette contrainte est appliqué récursivement à tous conteneur de temps ascendants ;
  2. Si un temps de début devant être utilisé comme cible recherchée se produit après la fin de la durée simple de n'importe quel conteneur de temps ascendant, alors le temps cherché est contraint au temps de fin simple du conteneur de temps parent.

Cette section est informative.

Notez que la première contrainte signifie qu'un hyperlien vers un enfant d'un conteneur de temps ne cherchera jamais un temps antérieur au début du conteneur de temps parent. La seconde contrainte implique qu'un hyperlien vers un enfant qui commence après la fin de la durée simple de son conteneur de temps parent recherchera la fin du parent et poursuivra à partir de celle-ci. Bien que cela puisse produire des résultats surprenants, c'est la sémantique de repli la plus raisonnable pour ce qui est essentiellement une erreur de présentation.

Si une recherche du temps de la présentation est requise, il peut être nécessaire de chercher soit en avant, soit en arrière, selon le temps de début résolu de l'élément et le temps courant de la présentation au moment de l'activation de l'hyperlien.

Cette section est normative.

L'effet net est que l'exploration en avant vers un temps de présentation met le document dans un état très proche de celui-ci, comme si le temps de présentation du document avait avancé sans perturbation jusqu'au temps cherché. Si la présentation est créée sans temporisation basée sur les événements beginEvent, endEvent ou repeatEvent et sans hyperliens automatiques, alors l'état d'un document après une recherche devrait être identique à celui-ci, si le temps de présentation du document avait avancé sans perturbation jusqu'au temps recherché.

Si le temps d'activation résolu pour un élément, ciblé par un hyperlien, survient dans le passé, le temps de présentation doit être exploré en arrière. L'exploration à rebours rembobinera tous les éléments actifs au moment de l'activation de l'hyperlien.

Cette section est informative.

Cette sémantique des hyperliens suppose qu'un enregistrement des temps de début résolus de tous les éléments soit gardé et que cet enregistrement soit disponible pour être utilisé afin de déterminer le temps de présentation correct à rechercher. Par exemple :

<html ...>
...
<par begin="0">
   <img id="A" begin="10s" .../>
   <img id="B" begin="A.begin+5s" .../>
   <img id="C" begin="B.click" .../>
   <img id="D" begin="C.begin+5s" .../>
   ...
   <a href="#D">Begin image D</a>
</par>
...
</html>

Le temps de début des éléments A et B peut être immédiatement résolu à respectivement 10 et 15 secondes. Le début des éléments C et D est non résolu quand le document commence. C'est pourquoi l'activation de l'hyperlien n'aura aucun effet sur le temps de la présentation ou sur les éléments C et D. Maintenant, supposons que B soit cliqué à 25 secondes dans la présentation. Le clic sur B résout le début de C ; ce qui à son tour résout D pour qu'il commence à 30 secondes. Partant de là, le suivi de l'hyperlien entraînera une recherche du temps de présentation à 30 secondes.

Si à 60 secondes dans la présentation, l'utilisateur clique encore sur B, l'élément D sera à nouveau résolu en un temps de présentation de 65 secondes. Une activation subséquente de l'hyperlien alors que D est actif résultera dans une exploration de la présentation à 65 secondes. Si l'hyperlien est activé alors que D n'est plus actif, la présentation cherchera le temps de début le plus précoce de D à 30 secondes.

Les implications de beginElement() et des hyperliens pour les conteneurs seq et excl

Cette section est normative.

Pour un enfant d'un conteneur de temps séquentiel, si un hyperlien ciblant l'enfant est activé, cela explore la séquence jusqu'au début de l'enfant.

Cette section est informative.

Notez que si un hyperlien cible (ou si des méthodes beginElement() ou beginElementAt() sont appelées pour) un élément A, défini pour commencer quand un autre élément B se termine et que l'autre élément B a (par exemple) une fin qui repose sur un événement ou une synchronisation, l'hyperlien ou l'appel de méthode ne termineront pas l'élément B. Cela ne fera qu'activer l'élément A. Si les deux éléments sont frères dans un même conteneur de temps seq, ou excl, le conteneur de temps parent fait respecter sa sémantique et arrête (ou met en pause) l'élément en cours.

Si un hyperlien cible un enfant d'un conteneur de temps excl, activer le lien cherchera le début calculé le plus précoce. Cela signifie que la sémantique d'empilement pause/defer n'a pas besoin d'être prise en compte pour un lien vers un élément. Plutôt, le plan de montage chronologique du document sera simplement exploré vers le premier temps résolu de l'élément, ou vers le début du conteneur de temps et l'élément cible est simplement démarré s'il n'y a pas de temps de début résolu.

La propagation des changements de temps

Cette section est informative.

Il y a plusieurs cas dans lesquels les temps peuvent changer alors que le document est présenté. En particulier, quand le temps d'un élément est défini par rapport à un événement, le temps (i.e., le début, ou la fin active de l'élément) est résolu quand l'événement se produit. Un autre cas apparaît avec le comportement de redémarrage - l'élément reçoit un nouveau temps de début et un nouveau temps de fin active quand il redémarre. Comme les temps de début et de fin active d'un élément peuvent être définis par rapport à ceux d'autres éléments, tout changement de temps doit être propagé à travers le document.

Quand un élément "foo" a un temps de début, ou de fin active, qui spécifie un élément de base de synchronisation (par exemple, "bar" ci-dessous ) :

<img id="foo" begin="bar.end" .../>

nous disons que "foo" est un dépendant temporel de "bar" - le temps de début de "foo" dépend du temps de fin active de "bar". Tout changement du temps de fin active de "bar" doit être propagé au début de "foo", ainsi "foo" démarrera bien quand "bar" se terminera. L'effet sur "foo" du changement propagé dépend de l'état de "foo" quand le changement se produit.

Cette section est normative.

Les éléments différés et la propagation des changements sur le début

Une exception au fonctionnement normal est faite pour les éléments qui sont différés selon les règles d'interruption de l'élément excl. Cette exception est faite pour simplifier le modèle : une fois qu'un élément est différé, il interrompra la gestion normale des avis de changement de temps qui sont propagés aux conditions de début des éléments, en tant que dépendants temporels d'élecute;ments de base de synchronisation. C'est-à-dire, par rapport au comportement de l'élément en tant que dépendant temporel, l'élément se comporte comme s'il avait déjà commencé. Cette exception est faite de façon à ce que l'élément différé ne puisse pas changer son temps de début à cause des changements de l'élément de base de synchronisation, pendant qu'il est différé. En effet, l'élément devrait avoir commencé au moment où il a été différé et donc ne devrait plus gérer les avis de changement de temps.

Cette section est informative.

Le redémarrage et la propagation des changements de temps

Dans certains cas, la sémantique de l'attribut restart peut empêcher la propagation correcte des changements de temps, comme dans l'exemple suivant :

<html ...>
...
<par>
   <img id="img1" dur="10s" end="click" .../>
   <video begin="img1.end-3s" restart="whenNotActive" .../>
</par>
...
</html>

Si l'utilisateur clique sur l'image à 8 secondes, l'image va se terminer à ce moment et le changement de temps de fin va se propager à la vidéo. Cependant, la vidéo aura commencé à 7 secondes (3 secondes avant la fin calculée à 10 secondes) et ne peut pas redémarrer. Le changement propagé sera ignoré. Voir aussi « L'interaction avec la sémantique de restart » dans la section « L'évaluation des listes des temps de début et de fin ».

La durée d'un conteneur de temps

Cette section est informative.

La durée implicite d'un conteneur de temps est définie par rapport aux enfants du conteneur. Les enfants peuvent être vus comme le « média » qui est « joué » par l'élément conteneur de temps. Les sémantiques sont spécifiques à chaque type de conteneur de temps défini et sont décrites dans leurs sections respectives : « L'élément par », « L'élémentseq » et « L'élémentexcl ».

Notez que le terme « valeurs calculées » ne devrait pas être confondu avec les valeurs de temps dynamiques dans le graphe temporel. Dans l'exemple suivant, la vidéo sera raccourcie si l'utilisateur l'active (par exemple, clique) avant 10 secondes. Si l'utilisateur ne clique pas, l'élément par a une durée simple de 10 secondes. Si l'utilisateur active la vidéo à 5 secondes, le par a une durée simple de 8 secondes. Bien que le temps de fin original pour la vidéo puisse être calculé par une implémentation comme valant 10 secondes, la sémantique de l'attribut endsync doit être évaluée avec les temps mis à jour en tenant compte des événements de l'utilisateur.

<smil ...>
...
<par endsync="last" >
   <audio dur="8s" .../>
   <video begin="0" dur="10s" end="click" .../>
</par>
...
</smil>

Les contraintes du conteneur de temps sur les durées des enfants

Cette section est informative

Les conteneurs de temps placent certaines contraintes de surclassement sur les éléments enfants. Ces contraintes peuvent raccourcir la durée active de n'importe quel élément enfant.

Cette section est normative.

Tous les conteneurs de temps partagent la contrainte de surclassement de base :

Cette section est informative.

Alors qu'un enfant peut définir une relation de synchronisation qui place son début avant celui de ses parents, l'enfant n'est pas actif avant que le parent ne commence. Ceci est équivalent à la sémantique décrite dans « Les délais négatifs de début ».

Si l'enfant définit une durée active (ou par le même atome une durée simple) qui s'étend au-delà de la fin de durée simple de son parent, la durée active de l'enfant sera raccourcie quand la durée simple du parent se terminera. Notez que cela n'implique pas que la durée de l'enfant soit automatiquement raccourcie ou que la durée simple du parent soit « héritée » par l'enfant.

Par exemple :

<par dur="10s" repeatDur="25s">
   <video dur="6s" repeatCount="2" .../>
   <text id="text1" begin="5s" dur="indefinite" .../>
   <audio begin="text1.end" .../>
</par>

La vidéo va jouer une fois pendant 6 secondes et ensuite une seconde fois mais seulement pour 4 secondes - les 2 dernières secondes seront raccourcies et ne seront pas vues. Le texte est affiché pour les 5 dernières secondes du par et la durée indéfinie est raccourcie à la fin de la durée simple du par. Le son ne sera pas joué du tout, car il est défini pour commencer à la fin de la durée active de l'élément précédent (l'élément text). Comme l'élément text se termine quand le conteneur se termine, le son devrait commencer après la fin du conteneur et donc n'est pas entendu. Quand le par se répète pour la première fois, tout s'est déroulé comme la première fois (avant la première répétition). Cependant, la dernière répétition est partielle (5 secondes) et seule la vidéo sera vue, mais elle ne sera pas répétée et la dernière seconde sera même raccourcie.

En plus, les conteneurs de temps excl ne permettent qu'à un seul enfant à la fois d'être joué. Soumise à la sémantique de priorityClass, la durée active d'un élément peut être raccourcie quand un autre élément du conteneur de temps commence.

L'attribut min et les contraintes du conteneur de temps sur les durées des enfants

L'attribut min n'a aucun effet sur les contraintes des conteneurs de temps sur les durées des enfants. Cette contrainte s'applique toujours, même si une durée active ne satisfait pas une contrainte de valeur min. Dans l'exemple suivant, l'image est jouée entre 0 et 5 secondes.

<par dur="5s">
   <img id="img" min="7s" dur="4s" .../> 
</par> 

Les contraintes du conteneur de temps sur les arcs de synchronisation et les événements

Cette section est informative.

SMIL 1.0 a défini des contraintes sur la définition des arcs de synchronisation (par exemple, begin="id(image1)(begin)"), permettant seulement de référencer les frères qualifiés. SMIL 2.0 retire explicitement cette contrainte. SMIL 2.0 ajoute aussi une temporisation basée sur les événements. Les arcs de synchronisation et la temporisation basée sur les événements sont tous deux contraints par le conteneur de temps parent de l'élément associé, comme décrit ci-dessus.

Les caractéristiques des arcs de synchronisation

Cette section est normative.

Alors qu'un arc de synchronisation est explicitement défini par rapport à un élément particulier, si cet élément n'est pas un élément frère, alors la synchronisation est résolue comme une relation de synchronisation avec le parent (i.e., par rapport à un décalage du début du parent).

Cette section est informative.

Notez que, en particulier, un élément avec un début défini selon un arc de synchronisation ne va pas automatiquement obliger le conteneur de temps parent (ou n'importe quel ancêtre) à commencer.

Pour le cas où un élément avec un arc de synchronisation est dans un conteneur de temps parent (ou un ancêtre) qui se répète : pour chaque itération du parent, ou de l'ancêtre, l'élément est joué comme si c'était la première fois que le plan de montage chronologique du parent, ou de l'ancêtre, était joué. À chaque répétition du parent, l'arc de synchronisation sera recalculé pour garder un temps de début qui corresponde au conteneur de temps parent. Voir aussi la section « La réinitialisation de l'état d'un élément ».

Les caractéristiques de la temporisation en relation avec les événements

Cette section est informative.

Les caractéristiques de la temporisation liée aux événements sont décrites dans la section « La sensibilité des événements ».

Le comportement des éléments de durée 0

Cette section est normative.

Qu'un média sans durée ni période de remplissage soit, ou non, ramené et/ou joué brièvement est dépendant de l'implémentation.

10.3.4 Les clarifications et les résultats surprenants

Quand un élément commence, tous les temps de début basés sur des événements sont effacés. Dans l'exemple suivant , si un événement d'activation survient et que, une seconde après, l'élément "bar" se termine, alors "foo"commence immédiatement, et l'élément ne redémarre pas 4 secondes plus tard, indépendamment des paramètres de redémarrage. Cependant, si un événement d'activation se produit et que "bar" ne se termine pas dans les 5 secondes qui suivent, l'élément va redémarrer à la fin de ce temps.

<audio id="foo" begin="bar.end; activateEvent+5s".../>

Voir « L'évaluation des listes des temps de début et de fin ».

10.4 L'intégration de la temporisation et de la synchronisation de SMIL dans un langage hôte

Cette section est informative.

Cette section décrit ce qu'un concepteur de langage doit effectivement faire pour intégrer la gestion de la temporisation et de la synchronisation de SMIL dans un langage hôte. Cela comprend les définitions de base, les contraintes sur la spécification et les événements permis/gérés.

10.4.1 Les définitions requises pour le langage hôte

Cette section est informative.

Le concepteur du langage hôte doit définir certains concepts de base dans le contexte particulier du langage hôte. Ceux-ci fournissent la base pour les sémantiques de temporisation et de présentation.

Cette section est normative

10.4.2 Les définitions et contraintes requises pour la temporisation des éléments

Cette section est normative.

Les événements reconnus pour la temporisation en fonction des événements

Cette section est normative.

10.4.3 La sémantique de la gestion des erreurs

Cette section est normative.

10.5 La gestion du modèle objet du document

Cette section est informative.

Tout langage XML, qui intègre une temporisation SMIL, hérite des interfaces de base définies dans le DOM [DOM2]. La temporisation de SMIL spécifie l'interaction entre les fonctionnalités de la temporisation et le DOM. La temporisation de SMIL définit aussi les contraintes sur les interfaces DOM de base. Un document séparé définira des interfaces DOM spécifiques pour la gestion de la temporisation de SMIL, cependant, ce document suppose l'existence de mécanismes pour démarrer et terminer les éléments et pour les mettre en pause et les faire reprendre.

Cette section est normative.

Aucune gestion de syntaxe n'est requise pour les interfaces présumées, bien que la valeur d'argument "indefinite" dans les attributs begin et end puisse être utilisée pour décrire la temporisation qui sera initiée par des méthodes DOM. Dans tous les cas, les actions des méthodes de temporisation du DOM seront soumises aux contraintes du modèle temporel décrit dans ce document.

Un langage intégrant la temporisation et la synchronisation de SMIL ne requière pas une implémentation DOM.

10.5.1 Les manipulations, mutations et contraintes des éléments et attributs

Si les attributs de temporisation des éléments temporisés sont manipulés par les interfaces DOM pendant que le graphe temporel fonctionne, le comportement n'est pas défini dans ce document. De la même façon, si des éléments temporisés sont insérés ou retirés du document pendant que le graphe temporel fonctionne, le comportement n'est pas défini. Les comportement et les contraintes en rapport seront spécifiées dans un document futur.

10.5.2 Les événements et le modèle événementiel

Cette section est informative.

La temporisation des événements de SMIL suppose que le langage hôte gère les événements et que les événements puissent être encadrés de manière déclarative. La spécification des événements de DOM niveau 2 [DOM2Events] décrit les fonctionnalités pour cette gestion.

Cette section est normative.

Les événements spécifiques gérés sont définis dans le langage hôte. Si aucun événement n'est défini par le langage hôte, la temporisation des événements sera ignorée.

Ce module définit un jeu d'événements qui peuvent être inclus dans un langage hôte. Ceux-ci comprennent :

beginEvent
Cet événement est déclenché quand le plan de montage chronologique local de l'élément commence à jouer. Il sera déclenché à chaque fois que la durée active de l'élément commencera (i.e., quand il redémarre, mais pas quand il se répète). Il peut être déclenché aussi bien dans le cours normal (i.e., planifié ou interactif) de la lecture du plan de montage chronologique que dans le cas où l'élément était démarré par une méthode DOM.
endEvent
Cet événement est déclenché à la fin active de l'élément. Notez que cet événement n'est pas déclenché à la fin de la durée simple de chaque répétition. Cet événement peut être déclenché aussi bien dans le cours normal (i.e., planifié ou interactif) de la lecture du plan de montage chronologique que dans le cas où l'élément était arrêté par une méthode DOM.
repeat
Cet événement est déclenché quand le plan de montage chronologique local de l'élément se répète. Il sera déclenché à chaque fois que l'élément se répète, après la première itération. Un entier, associé à cet événement, indique quelle itération commence. Cet entier commence à 0, mais comme l'événement n'est pas déclenché à la première itération, et ainsi les valeurs observées seront >= 1.

Si un élément est en train de jouer quand il est redémarré, l'élément déclenchera un endEvent et ensuite un beginEvent quand il redémarrera.

Pour que le modèle puisse fonctionner de manière cohérente et pour supprimer l'effet des écarts de synchronisation dans une chaîne de temps d'événements, la valeur d'estampille associée aux événements, tels que les événements beginEvent, endEvent, et repeat, n'est pas (nécessairement) le temps réel où l'événement a été déclenché ni le temps où un dépendant temporel a été avisé de l'événement. L'estampille de l'événement correspond plutôt au temps le plus précoce où l'événement pourrait être déclenché (selon la sémantique du modèle temporel et en supposant que les éléments commencent et terminent précisément quand ils sont définis pour le faire). Il y a trois cas de base correspondant aux conditions de début et de fin avec des décalages respectivement, de zéro, positifs et négatifs :

Exemple 1

Ces exemples supposent que les médias audio et vidéo enregistrés sont en parfaite synchronisation l'un avec l'autre.

<par dur="indefinite">
  <img id="foo" end="click" .../>
  <video id="bar" begin="foo.endEvent" .../>
  <audio id="copy" begin="foo.end" .../>
</par>

L'image "foo" se terminera quand l'utilisateur cliquera dessus. Le temps de fin défini est vraiment le temps de l'événement click (même si cela prend un certain temps pour propager l'événement click dans le mécanisme de présentation). L'élément "foo" déclenchera un endEvent avec une estampille valant le temps de l'événement click. Le comportement, dans cet exemple, est que "bar" et "copy" seront en parfaite synchronisation (bien que "bar" puisse commencer très légèrement en retard, car la propagation des événements dans le système peut prendre un certain temps).

Exemple 2

<par dur="indefinite">
  <img id="foo" .../>
  <video id="bar" begin="foo.click+3s" .../>
  <audio id="copy" begin="bar.beginEvent" .../>
</par>

La vidéo "bar" commencera 3 secondes après que l'utilisateur aura cliqué sur "foo". Le beginEvent de "bar" aura une estampille valant l'événement "foo.click" plus 3 secondes. Le comportement est, dans l'exemple ci-dessus, que "bar" et "copy" seront en synchronisation parfaite (bien que "copy" puisse commencer très légèrement en retard, car la propagation des événements dans le système peut prendre un certain temps).

Exemple 3

<par dur="indefinite">
  <img id="foo" .../>
  <video id="bar" begin="foo.click-3s" .../>
  <audio id="copy" begin="bar.beginEvent" .../>
</par>

La vidéo "bar" commence quand l'utilisateur clique sur "foo". La vidéo commencera à jouer avec un décalage de 3 secondes dans son contenu effectif, car elle est prévue pour commencer 3 secondes avant le click. Cependant comme "bar" ne peut pas commencer plus tôt que le « maintenant » du déclenchement de l'événement, il va déclencher un beginEvent qui a le même temps que l'événement "foo.click". C'est pourquoi, dans ce cas, l'élément audio "copy" sera exactement 3 secondes derrière (désynchronisé d'avec) la vidéo.

Les contraintes supplémentaires du modèle temporel peuvent entraîner une différence entre l'estampille de l'événement beginEvent (ou endEvent) et le temps de début (ou de fin) calculé pour un élément. Par exemple, l'élément peut spécifier un temps de début avant le début de son conteneur de temps parent (soit avec une valeur de décalage négative, soit avec un temps de base de synchronisation qui est résolu en un temps avant le début du parent). Dans ce cas, un dépendant temporel du temps de base de synchronisation pour begin sera défini par rapport au temps de début calculé. Cependant, l'élément est effectivementcontraint à ne pas commencer avant le début du conteneur de temps parent. L'événement beginEvent sera déclenché quand l'élément commencera effectivement - dans l'exemple, quand le conteneur de temps parent commence. De la même façon, l'événement endEvent est déclenché quand l'élément se termine effectivement, ce qui peut différer du temps de fin calculé (par exemple, quand la fin est spécifiée pour être après la fin de la durée simple du parent).

La distinction entre les temps de base de synchronisation et d'événement peut être utile dans certaines situations. Observez l'exemple suivant :

<par>
  <par begin="5s">
    <par begin="-5s">
      <img id="foo" begin="1s; 8s" dur="3s" .../>
    </par>
  </par>
  <img id="bar" begin="foo.begin" dur="1s" .../>
  <audio id="beep" begin="foo.beginEvent" dur="1s" .../>
</par>

L'élément "foo" définit deux intervalles. Le dernier élément par (le plus proche de "foo") découpe - mais n'élague pas - le premier intervalle, car le dernier par est contraint par le par interne et ne peut pas effectivement commencer avant 5 secondes dans le document. Cependant, le dernier par est synchronisé avec le temps 0 du document. De ce fait, "bar" sera joué 2 fois : une fois à 1 seconde, et encore une fois à 8 secondes, car les valeurs de base de synchronisation utilisent les temps d'intervalles calculés. Cependant, le son "beep" ne sera joué qu'une fois à 8 secondes, ce qui correspond au moment où "foo" est effectivement affiché, car les intervalles découpés ne déclenchent pas d'événement.

Alors qu'il est peu probable que les auteurs produisent l'exemple précédent, des cas similaires peuvent très facilement naître de l'utilisation d'une temporisation avec base de synchronisation. Quand il est important de distinguer le temps de début observé du temps de début planifié, une temporisation avec les valeurs des événements beginEvent ou endEvent peut être utilisée. Cependant, l'auteur doit être attentif aux contraintes des valeurs de temps d'événement. Ceci inclus les contraintes de sensibilités des événements et le fait que de nombreuses implémentations n'optimiseront pas aussi bien la planification et la préparation des médias pour les éléments utilisant une temporisation avec des valeurs d'événement que pour les éléments utilisant une temporisation avec des valeurs de base de synchronisation planifiée. Voir aussi « La propagation des changements de temps ».

10.5.3 Les méthodes réservées du DOM

Cette section est normative.

La temporisation de SMIL réserve quatre méthodes DOM pour contrôler la temporisation des éléments : beginElement(), beginElementAt(), endElement() et endElementAt() et décrit leur effet sur le modèle temporel. La définition complète de ces méthodes est laissée à un document futur décrivant les fonctionnalités DOM.

Les quatre méthodes DOM sont utilisées pour commencer et terminer la durée active d'un élément. Les auteurs peuvent (mais ne sont pas obligés de) déclarer les paramètres de temps pour répondre au DOM en utilisant la syntaxe suivante :

<img begin="indefinite" end="indefinite" .../>

Les méthodes beginElement(), beginElementAt(), endElement() et endElementAt() sont toutes sujettes aux contraintes du conteneur de temps de façon semblable aux temps basés sur les événements. Si l'une de ces méthodes est appelée quand le conteneur de temps parent n'est pas actif, la méthode restera sans effet.

Si un appel à une méthode DOM est faite pour commencer ou terminer un élément (beginElement(), beginElementAt(), endElement() ou endElementAt()), chaque appel à une méthode crée un seul temps d'instance (dans la liste d'instances appropriée). Ces temps sont alors interprétés comme faisant partie de la sémantique des listes de temps, comme décrit dans « L'évaluation des listes des temps de début et de fin ». Ces temps d'instance sont effacés lors d'une réinitialisation tout comme pour les temps d'événements.

10.6 Glossaire

10.6.1 Les concepts généraux

Cette section est informative.

Les concepts suivants représentent les termes de base utilisés pour décrire le modèle temporel.

Les relations de synchronisation

Une relation de synchronisation est définie par l'auteur pour exprimer que la lecture de deux ou plusieurs éléments est synchronisée.

Le graphe temporel

Un graphe temporel est utilisé pour représenter les relations temporelles entre les éléments dans un document avec une temporisation SMIL. Les nœuds du graphe temporel représentent les éléments du document. Les nœuds parents peuvent "contenir" des enfants et les enfants ont un seul parent. Les frères sont des éléments qui ont un parent commun. Les liens ou « arcs » du graphe temporel représentent les relations de synchronisation entre les nœuds du graphe.

Les termes descriptifs des temps

La description du modèle temporel utilise un ensemble de qualificatifs pour décrire des concepts particuliers de la temporisation :

implicite
Ceci décrit un temps qui est défini intrinsèquement par l'élément média (par exemple, basé sur la longueur d'un film), ou par la sémantique du modèle temporel (par exemple, la durée du conteneur de temps par).
explicite
Ceci décrit un temps qui est spécifié par l'auteur, en utilisant la syntaxe de SMIL.
désiré
Ceci est un temps que l'auteur attendait - c'est généralement le temps explicite, s'il y en a un, ou le temps implicite, s'il n'y a pas de temps explicite.
effectif
Ceci est un temps qui est vraiment observé à la lecture du document. Il reflète à la fois les contraintes du modèle temporel et les aléas du monde réel comme, par exemple, la livraison des médias.
défini
Un temps est défini s'il est résolu en une valeur finie (non indéfinie).

Le temps local et le temps global

Le temps global est défini par rapport à la référence commune pour tous les éléments, la racine du document. Ceci est aussi parfois appelé temps du document.

Dans un document, quand un élément donné est actif ou « joue », les contenus de cet élément progressent du début de la durée active jusqu'à la fin de la durée active. Il y aura aussi une progression du début à la fin de chaque durée simple (la distinction est plus claire quand l'élément se répète). Il est souvent pratique de parler des temps en termes de durée simple ou durée active d'un élément. Ceci est génériquement appelé temps local, signifiant que les temps ont une référence locale à un élément.

Les termes suivants sont employés pour qualifier plus précisément les temps locaux :

temps actif
Temps qui se mesure par rapport à la durée active de l'élément. Un temps est mesuré comme un décalage par rapport au début actif de l'élément.
temps simple
Temps qui se mesure par rapport à la durée simple de l'élément. Un temps est mesuré comme un décalage par rapport au début d'une instance particulière de la durée simple.
temps du média
Temps qui se mesure par rapport à la durée du média de l'élément. Un temps est mesuré comme un décalage par rapport au début du média, avec les modifications dues aux éventuels attributs clipBegin ou clipEnd.

Pour avoir un sens, ces termes sont décrits par rapport à un certain élément. Par exemple, quand on décrit une sémantique de temporisation, le temps actif de l'élément se rapporte à la durée active de l'élément en question et le temps simple du parent fait référence au temps simple du parent de cet élément.

La conversion du temps global (document) vers un temps d'élément, ou d'un temps d'élément vers un autre temps d'élément, est décrite dans « La conversion entre temps local et temps global ».

Quand on mesure ou calcule un temps, un élément de référence et le type de temps local ( actif, simple ou média) sont spécifiés. Le temps mesuré, ou durée, est défini en termes de progression du temps de l'élément. Par exemple, si l'élément de référence est mis en pause, cela peut influer sur la sémantique des temps ou durées mesurées par rapport à l'élément.

Les médias linéaires et non linéaires

Un média linéaire est un média continu qui ne peut pas être joué en y accédant de manière aléatoire. Par exemple, la plupart des flux vidéos et audios sont linéaires.

Un média non linéaire peut être joué en y accédant de manière aléatoire. Par exemple, une animation algorithmique est non linéaire. Un média discret peut se comporter de manière non linéaire.

Le comportement linéaire ou non linéaire du média n'est pas fonction du type du média, mais plutôt du moteur de rendu ou de lecture et dépend souvent du mécanisme de livraison du média.

La temporisation planifiée

Un élément est considéré obéir à une temporisation planifiée si le temps de début de l'élément est donné par rapport au début ou à la fin active d'un autre élément. Un élément planifié peut être inséré directement dans le graphe temporel.

Cette section est normative.

début du document

Le début de l'intervalle dans lequel le document est présenté est appelé début du document.

fin du document

La fin de l'intervalle dans lequel le document est présenté est appelée fin du document.

durée du document

La différence entre le début et la fin est appelée durée du document.

Cette section est informative.

Les événements et la temporisation interactive

Les temps de début et de fin active dans SMIL 2.0 peuvent être spécifiés par rapport à des événements déclenchés dans l'environnement de lecture du document. Cela gère une temporisation déclarative et interactive. Par interactive, on comprend les événements de l'utilisateur, tels que les clics de souris, les événements déclenchés par les lecteurs de médias, comme un événement mediaComplete, et les événements déclenchés par le moteur de présentation lui-même, tel qu'un événement pause.

Les bases de synchronisation

Dans une temporisation planifiée, les éléments sont temporisés par rapport aux autres éléments. La base de synchronisation pour un élément A est l'autre élément B auquel l'élément A est relatif. Plus précisément, c'est le début ou la fin active de l'autre élément. La base de synchronisation n'est pas simplement un point planifié dans le temps, mais plutôt un point du graphe temporel.

Les arcs de synchronisation

Les arcs de synchronisation sont utilisés pour relier des nœuds dans le graphe temporel et pour définir les relations de temporisation entre les nœuds. Un arc de synchronisation relie un élément à sa base de synchronisation. L'arc de synchronisation peut être défini implicitement par le contexte, explicitement par une valeur d'Id ou un nom d'événement, ou logiquement avec une syntaxe spéciale.

Les horloges

Une horloge est une référence à un plan de montage chronologique particulier qui peut être utilisée pour la synchronisation. Un exemple d'utilisation courante, avec le temps local du monde réel, est désigné par temporisation avec horloge de temps réel (par exemple, pour spécifier 10:30 en heure locale). D'autres horloges peuvent aussi être gérées par un environnement de présentation donné.

UTC: Temps Universel Coordonné

Le « Temps Universel » (abrégé en UT) est aussi parfois appelé « Temps Moyen de Greenwich » (abrégé en GMT). Les deux termes sont souvent utilisés approximativement pour désigner l'heure du méridien de Greenwich (longitude zéro). Les temps donnés en UT sont presque toujours donnés en terme d'horloge de 24 heures. Ainsi, 14:42 est 2:42 p.m., et 21:17 est 9:17 p.m.

Les hyperliens et la temporisation

Un hyperlien pointant vers ou à l'intérieur d'un document temporisé peut entraîner une recherche du temps courant de la présentation ou peut activer un élément (si cela ne viole aucune règle du modèle temporel).

L'activation

Pendant la lecture, un élément peut être activé automatiquement par la progression du temps, via un hyperlien, ou en réponse à un événement. Quand un élément est activé, la lecture de l'élément commence.

Les médias discrets et les médias continus

SMIL inclut une gestion de la déclaration de médias, en utilisant la syntaxe de l'élément, définie dans « Le module d'objet média de SMIL ». Le média qui est décrit par ces éléments est décrit comme étant soit discret, soit continu :

discret
Le média n'a pas de temporisation intrinsèque, ou de durée intrinsèque. Ces médias sont parfois décrits comme médias « rendus » ou « synthétiques ». Cela inclus les images, le texte et certains médias vectoriels.
continu
Le média est naturellement basé sur le temps et a généralement une gestion intrinsèque de la temporisation et une notion intrinsèque de durée (bien que cette durée puisse être indéfinie). Cela inclus le son, les films et les animations basées sur le temps.

10.6.2 Les concepts de la temporisation

Les conteneurs de temps

Les conteneurs de temps regroupent les éléments dans le temps. Ils définissent des relations de synchronisation communes et simples pour un groupe d'éléments enfants. De plus, les conteneurs de temps contraignent le temps pendant lequel les enfants peuvent être actifs. Plusieurs conteneurs sont définis, chacun avec des sémantiques et contraintes propres sur leurs enfants.

Les éléments de contenu et les éléments médias

La gestion de la temporisation et de la synchronisation de SMIL contrôle finalement un ensemble d'éléments de contenu et d'éléments médias. Les contenus comprennent des choses comme de la vidéo et de l'audio, des images et des graphiques vectoriels aussi bien que du texte ou du contenu HTML. Les documents SMIL utilisent les éléments médias de SMIL pour référencer ce contenu. Les documents XML et HTML qui intègrent les fonctionnalités de SMIL 2.0 peuvent utiliser les éléments médias de SMIL et/ou le contenu décrit dans le langage intégré (par exemple, des paragraphes en HTML).

Le balisage de base

Tous les éléments - les éléments de contenu/éléments médias comme les conteneurs de temps - gèrent un balisage de temporisation pour décrire un temps de début et une durée ainsi qu'une possibilité de lecture à répétition. Il y a plusieurs façons de définir un temps de début. La sémantique varie selon le conteneur de temps de l'élément.

La durée simple et la durée active

Le modèle temporel définit deux concepts de durée pour chaque élément - la durée simple et la durée active. Ces définitions sont apparentées au concept de jouer une chose donnée de façon répétée.

durée simple
C'est la durée définie par le balisage de base de début et de durée. Cela n'inclut aucun des effets de lecture répétée ou de remplissage. La durée simple est définie par le début et la durée explicites, si l'une est spécifiée. Si aucun temps explicite n'est spécifié, la durée simple est définie comme étant la durée implicite de l'élément.
durée active
C'est la durée pendant laquelle l'élément joue normalement. Si aucun comportement de répétition n'est spécifié et que la fin n'est pas spécifiée, la durée active est la même que la durée simple. Si l'élément est défini pour jouer de façon répétée, la durée simple est répétée pour le cours de la durée active, comme défini par le balisage de répétition.
La durée active n'inclut pas l'effet de remplissage, sauf quand l'effet de l'attribut min prolonge une durée active plus courte. Voir « Les attributs min et max : un contrôle accru de la durée active ».

Les contraintes d'un conteneur de temps parent peuvent forcer la durée de ses enfants. En particulier, un élément enfant ne peut pas jouer au-delà de la fin simple du conteneur de temps.

Les termes pour ces durées peuvent être précisés selon « Les termes descriptifs des temps », pour mieux distinguer les aspects graphe temporel.

La synchronisation rigide et la synchronisation souple

SMIL 1.0 a introduit la notion de comportement de synchronisation, en décrivant le comportement de l'agent utilisateur selon qu'il implémente soit une « synchronisation rigide », soit une « synchronisation souple ». En utilisant une synchronisation rigide, toute la présentation est contrainte à la description stricte des relations de synchronisation du graphe temporel. La synchronisation souple permet un fonctionnement plus lâche (selon l'implémentation) du document.

Quand un document est joué, l'encombrement du réseau et d'autres facteurs vont parfois interférer avec la lecture des médias. Dans un environnement de synchronisation SMIL 1.0 rigide, cela aura un effet sur le comportement de tout le document. Afin de fournir un meilleur contrôle aux auteurs, SMIL 2.0 étend les modèles de synchronisations rigide et souple aux éléments individuels. Cela permet aux auteurs de définir quels éléments et conteneurs de temps doivent rester en synchronisation rigide, ou stricte, et quels éléments et conteneurs de temps peuvent avoir une relation de synchronisation souple, ou glissante, avec leur conteneur de temps parent.

Voir aussi la section « Les attributs syncBehavior, syncTolerance, et syncMaster : le contrôle de la synchronisation à l'exécution ».

L'élagage et l'élimination d'un intervalle

Les concepts d'élagage et de coupe d'un intervalle sont distincts et ne doivent pas être confondus.

Dans certains cas, après qu'un intervalle a été créé, il doit être élagué (effacé/retiré du graphe temporel) quand plus d'informations sont connues ou que des contraintes doivent être appliquées. Quand un intervalle est élagué, il ne sera pas joué, il ne déclenchera pas d'événements de début ni de fin et tous les temps d'instance, associés aux dépendants temporels de base de synchronisation, doivent être retirés des listes de temps d'instance respectives. C'est comme si l'intervalle élagué n'avait pas été spécifié.

Dans d'autres cas, particulièrement ceux liés aux temps de début négatifs par rapport aux conteneurs de temps parents, un intervalle valide pour un enfant peut ne pas être joué, même si il est conforme aux contraintes de temps des parents. Ces intervalles sont dits coupés.

Par exemple :

<par begin="-10s" dur="20s">
   <img id="slide1" src="slide1.jpg" dur="3s" />
   <img id="slide2" src="slide2.jpg" begin="slide1.end+3s" dur="10s" />
   <img id="note1" src="note1.jpg" begin="slide1.beginEvent" dur="20s" />
</par>

L'image "slide1" va être coupée, mais n'est pas élaguée. Elle est coupée car le par ne peut pas avoir démarré 10 secondes avant son conteneur de temps parent et aura plutôt été démarrée à 0 seconde dans le temps du parent, qui est synchronisé à 10 secondes dans sa propre durée simple. L'image "slide1" va commencer et finir avant ces 10 secondes dans l'élément par, et donc elle ne peut être montrée et elle est coupée. Les intervalles qui sont coupés ne sont pas joués, ne déclenchent pas d'événements de début ni de fin, mais créent tout de même des temps d'instance valides pour les éventuels dépendants temporels de base de synchronisation. Bien que "slide2" soit joué (l'intervalle va de moins 4 secondes à 6 secondes et donc il sera affiché pendant 6 secondes, de 0 secondes à 6 secondes), "note1" ne sera pas affiché.

10.7 Annexe A : Les modules de temporisation et de synchronisation de SMIL

Cette section est normative.

Cette section définit les 19 modules de de temporisation de SMIL 2.0, ce qui comprend le module BasicInlineTiming et 18 autres modules qui se combinent pour fournir la gestion complète de la temporisation de SMIL 2.0. Le découpage des modules de temporisation de SMIL 2.0 est fondé sur le regroupement de l'expression syntaxique des fonctionnalités utilisant les éléments, attributs et valeurs d'attributs. Inclure un module dans un profil ajoute à la fois la syntaxe et la sémantique associée, définie ailleurs dans cette spécification.

AccessKeyTiming
Ce module définit la syntaxe de valeur d'attribut pour les attributs begin et end qui permettent aux éléments de commencer et de se terminer à partir de l'activation par l'utilisateur de la clé d'accès désignée.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs begin et end avec les valeurs de clé d'accès.
Autres exigences pour l'intégration spécifique du module
La clé d'accès requise par l'auteur peut ne pas être disponible pour le lecteur (par exemple, elle peut ne pas exister sur le périphérique utilisé, ou être utilisée par l'agent utilisateur lui-même). Par conséquent, l'agent utilisateur devrait rendre la clé spécifiée disponible, mais peut faire correspondre la clé d'accès à un autre comportement interactif. L'agent utilisateur doit fournir un moyen pour identifier les clés d'accès qui peuvent être utilisées dans une présentation. Cela peut être réalisé de diverses façons par différentes implémentations, par exemple, au travers d'une interaction directe avec l'application ou via le guide de l'utilisateur.
BasicInlineTiming
Ce module définit les attributs qui fondent la gestion de base de la temporisation pour ajouter une temporisation aux éléments XML.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs dur (avec toutes les valeurs autorisées), begin et end, avec des valeurs de décalage simples et "indefinite".
Autres exigences pour l'intégration spécifique du module
Aucune.
BasicTimeContainers
Ce module définit les éléments conteneurs de temps de base, les attributs qui décrivent le comportement de lecture d'un élément dans un conteneur de temps et les conditions de fin pour les conteneurs de temps.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les éléments par et seq, les attributs fill et endsync.
Autres exigences pour l'intégration spécifique du module
La spécification fill="transition" n'est gérée que quand les modules BasicTransitions ou InlineTransitions sont inclus dans le profil de langage. Si le module FillDefault n'est pas inclus dans le profil, fill="default" est interprété de la même façon que fill="auto".
EventTiming
Ce module définit la syntaxe de valeur d'attribut pour les attributs begin et end qui permettent aux éléments de commencer et terminer en réponse à un événement.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs begin et end, avec des valeurs d'événement.
Autres exigences pour l'intégration spécifique du module
Aucune. Un langage hôte peut spécifier qu'il ne gère pas les décalages pour les valeurs d'événement.
ExclTimeContainers
Ce module inclut un conteneur de temps qui définit un ensemble d'éléments en exclusion mutuelle et décrit la sémantique d'interruption entre ces éléments.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les éléments excl et priorityClass, les attributs fill et endsync.
Autres exigences pour l'intégration spécifique du module
La spécification fill=transition n'est géré que quand les modules BasicTransitions ou InlineTransitions sont inclus dans le profil de langage. Si le module FillDefault n'est pas inclus dans le profil, fill="default" est interprété de la même façon que fill="auto".
FillDefault
Ce module définit la syntaxe pour spécifier le comportement d'affichage par défaut pour les éléments.
Dépendances du module
BasicTimeContainers ou ExclTimeContainers ou TimeContainerAttributes.
Fonctionnalités incluses
L'attribut fillDefault.
Autres exigences pour l'intégration spécifique du module
La spécification fill="transition" n'est gérée que quand les modules BasicTransitions ou InlineTransitions sont inclus dans le profil de langage.
MediaMarkerTiming
Ce module définit la syntaxe de valeur d'attribut pour les attributs begin et end qui permettent aux éléments de commencer et de se terminer en fonction des marqueurs contenus dans la source du contenu.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs begin et end, avec des valeurs de marqueurs de média.
Autres exigences pour l'intégration spécifique du module
Aucune.
MinMaxTiming
Ce module définit les attributs qui permettent de définir les limites minimum et maximum de la durée active d'un élément.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs max et min.
Autres exigences pour l'intégration spécifique du module
Aucune.
MultiArcTiming
Ce module étend la syntaxe de valeur d'attribut pour les attributs begin et end afin de permettre des valeurs multiples séparées par des points-virgules. Toutes les combinaisons des types de valeur simples des attributs begin et end fournis par les autres modules de temporisation inclus dans le profil sont autorisées.
Dépendances du module
Au moins l'un d'entre les modules : AccessKeyTiming, BasicInlineTiming, EventTiming, MediaMarkerTiming, RepeatValueTiming, SyncbaseTiming, WallclockTiming.
Fonctionnalités incluses
Toute combinaison de valeurs individuelles des attributs begin et end inclus dans le profil, séparées par des points-virgules.
Autres exigences pour l'intégration spécifique du module
Aucune.
RepeatTiming
Ce module définit les attributs permettant de répéter un élément pour une durée donnée ou un nombre d'itérations donné.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs repeatDur, repeatCount et repeat.
Autres exigences pour l'intégration spécifique du module
L'attribut repeat est déprécié et ne requiert une inclusion que dans les profils conformes au langage hôte SMIL.
RepeatValueTiming
Ce module définit la syntaxe de valeur d'attribut pour les attributs begin et end qui permettent aux éléments de commencer et de se terminer en réponse à des événements répétés avec une certaine valeur d'itération.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs begin et end, avec des valeurs d'itération.
Autres exigences pour l'intégration spécifique du module
Aucune.
RestartDefault
Ce module définit la syntaxe pour spécifier la sémantique de redémarrage par défaut des éléments.
Dépendances du module
RestartTiming.
Fonctionnalités incluses
L'attribut restartDefault.
Autres exigences pour l'intégration spécifique du module
Aucune.
RestartTiming
Ce module définit un attribut pour contrôler le comportement de début d'un élément qui a commencé précédemment.
Dépendances du module
Aucune.
Fonctionnalités incluses
L' attribut restart.
Autres exigences pour l'intégration spécifique du module
Si ce module n'est pas inclus, le profil d'intégration doit définir la sémantique de tentative de redémarrage d'un élément qui a déjà commencé.
SyncBehavior
Ce module définit la syntaxe pour spécifier le comportement de synchronisation à l'exécution entre les éléments.
Dépendances du module
BasicTimeContainers ou ExclTimeContainers ou TimeContainerAttributes.
Fonctionnalités incluses
Les attributs syncBehavior et syncTolerance.
Autres exigences pour l'intégration spécifique du module
Aucune.
SyncBehaviorDefault
Ce module définit la syntaxe pour spécifier le comportement de synchronisation par défaut pour les éléments et tous leurs descendants.
Dépendances du module
SyncBehavior.
Fonctionnalités incluses
Les attributs syncBehaviorDefault et syncToleranceDefault.
Autres exigences pour l'intégration spécifique du module
Aucune.
SyncbaseTiming
Ce module définit la syntaxe de valeur d'attribut pour les attributs begin et end qui permettent aux éléments de commencer et de se terminer les uns par rapport aux autres.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs begin et end, avec des valeurs de base de synchronisation.
Autres exigences pour l'intégration spécifique du module
Aucune.
SyncMaster
Ce module définit la syntaxe pour spécifier le maître de synchronisation pour un plan de montage chronologique.
Dépendances du module
SyncBehavior.
Fonctionnalités incluses
L'attribut syncMaster.
Autres exigences pour l'intégration spécifique du module
Aucune.
TimeContainerAttributes
Ce module définit les attributs servant à ajouter la gestion des conteneurs de temps à n'importe quel élément d'un langage XML.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs timeContainer, timeAction, fill et endsync.
Autres exigences pour l'intégration spécifique du module
Le profil doit définir sur quels éléments ces attributs peuvent être utilisés. La spécification fill="transition" n'est gérée que quand les modules BasicTransitions ou InlineTransitions sont inclus dans le profil de langage. Si le module FillDefault n'est pas inclus dans le profil de langage, fill="default" est interprété de la même façon que fill="auto".
WallclockTiming
Ce module définit la syntaxe de valeur d'attribut pour les attributs begin et end qui permettent aux éléments de commencer et terminer par rapport à une horloge de temps réel.
Dépendances du module
Aucune.
Fonctionnalités incluses
Les attributs begin et end, avec des valeurs de temps d'horloge de temps réel.
Autres exigences pour l'intégration spécifique du module
Aucune.

10.8 Annexe B : Exemples annotés

10.8.1 Exemple 1 : Une temporisation simple dans un conteneur de temps parallèle

Cette section comprend un ensemble d'exemples illustrant à la fois l'utilisation de la syntaxe de SMIL et la sémantique de constructions spécifiques. Cette section est informative.

Note : Dans les exemples ci-dessous, la syntaxe supplémentaire, liée à la disposition et aux questions propres aux types de document individuels sont omises dans un but de simplification.

Tous les enfants d'un élément par commencent par défaut quand le par commence. Par exemple :

<par>
   <img id="i1" dur="5s"  src="img.jpg" />
   <img id="i2" dur="10s" src="img2.jpg" />
   <img id="i3" begin="2s" dur="5s" src="img3.jpg" />
</par>

Les éléments "i1" et "i2" commencent tous deux dès que le par commence, ce qui est le temps de début par défaut. La durée active de "i1" se termine à 5 secondes dans le par. La durée active de "i2" se termine à 10 secondes dans le par. Le dernier élément "i3" commence à 2 secondes puisqu'il a un décalage de début spécifique et a une durée active de 5 secondes, ce qui signifie que sa durée active se termine 7 secondes après le début du par.

10.8.2 Exemple 2 : Une temporisation simple dans un conteneur de temps séquentiel

Chaque enfant d'un élément seq commence quand l'élément précédent se termine. Par exemple :

<seq>
   <img id="i1" begin="0s" dur="5s" src="img1.jpg" />
   <img id="i2" dur="10s" src="img2.jpg" />
   <img id="i3" begin="1s" dur="5s" src="img3.jpg" />
</seq>

L'élément "i1" commence immédiatement, avec le début du seq, et se termine 5 secondes plus tard. Note : Spécifier un décalage de début de 0 secondes est optionnel puisque le décalage de début par défaut vaut toujours 0 seconde. Le second élément "i2" commence, par défaut, 0 seconde après que l'élément précédent "i1" s'est terminé, ce qui est 5 secondes dans le seq. L'élément "i2" se termine 10 secondes plus tard, à 15 secondes dans le seq. Le dernier élément "i3" a un décalage de début spécifié à 1 seconde, donc il commence 1 seconde après que l'élément précédent "i2" s'est terminé et a une durée de 5 secondes, donc il se termine à 21 secondes dans le seq.

10.8.3 Exemple 3 : Un conteneur de temps excl avec des variantes de temporisation enfants

  1. Élément exclusif, enfants activés par un lien :
    <par>
        <excl>
    	<par id="p1"> 
    	...  
    	</par>
    	<par id="p2">
    	...  
    	</par>
        </excl>
        <a href="p1"><img src="Button1.jpg"/></a>
        <a href="p2"><img src="Button2.jpg"/></a>
    </par>
    

    Cet exemple modélise un comportement de juke-box. Activer l'hyperlien de la première image active le média du conteneur parallèle "p1". Si le lien sur la seconde image est activé, "p2" est démarré (et "p1" est désactivé, s'il était actif) à partir du temps 0.

  2. Élément exclusif combiné avec une activation par événement :
    <smil ...>
    ...
    <par>
        <excl>
    	<par begin="btn1.activateEvent"> 
    	...  
    	</par>
    	<par begin="btn2.activateEvent">
    	...  
    	</par>
        </excl>
        <img id="btn1" src=... />
        <img id="btn2" src=... />
    </par>
    ...
    <smil>
    

    Le même exemple de juke-box, mais utilisant une activation par événement.

  3. Élément exclusif utilisant une temporisation planifiée :
    <excl>
        <ref id="a" begin="0s" ... />
        <ref id="b" begin="5s" ... />
    </excl>
    

    Dans l'exemple ci-dessus, le début de "b" désactive "a" (en supposant que "a" est toujours actif après 5 secondes). Notez que cela aurait aussi pu être modélisé en utilisant une séquence avec une durée explicite sur les enfants. Bien que la syntaxe planifiée soit permise, il n'est pas prévu que ce soit un scénario d'utilisation courant.

10.8.4 Exemple 4 : La durée par défaut d'un média discret

Pour les éléments médias simples (i.e., les éléments médias qui ne sont pas des conteneurs de temps) qui référencent un média discret, la durée implicite est définie comme valant 0. Cela peut conduire à des résultats surprenants, comme dans cet exemple :

<seq>
   <img src="img1.jpg" />
   <video src="vid2.mpg" />
   <video src="vid3.mpg" />
</seq>

La base de synchronisation implicite d'une séquence est définie comme étant la fin active effective de l'élément précédent dans la séquence. Dans cet exemple, la durée implicite de l'image est utilisée pour définir les durées simple et active. Résultat, le début par défaut du second élément le fait commencer en même temps que l'image. Ainsi, l'image ne sera pas montrée du tout ! Les auteurs spécifieront généralement une durée explicite pour tous les éléments médias discrets.

10.8.5 Exemple 5 : Un attribut end spécifie la fin de la durée active, pas la fin de la durée simple

Il y a une importante différence entre les sémantiques des attributs end et dur. L'attribut dur, en conjonction avec le temps de début spécifie la durée simple d'un élément.

C'est la durée qui est répétée quand un élément a un comportement de répétition spécifié. D'un autre côté l'attribut end surclasse la durée active de l'élément. Si l'élément n'a pas de comportement de répétition spécifié, la durée active est la même que la durée simple. Cependant, si un comportement de répétition est spécifié pour l'élément, alors l'attribut end surclassera la répétition, mais n'aura aucun effet sur la durée simple. Par exemple :

<html ...>
...
<seq repeatCount="10" end="stopBtn.click">
   <img src="img1.jpg" dur="2s" />
   <img src="img2.jpg" dur="2s" />
   <img src="img3.jpg" dur="2s" />
</seq>
...
</html>

La séquence sera jouée pendant 6 secondes à chaque itération de la répétition. Elle sera jouée 10 fois, à moins que l'utilisateur ne clique sur l'élément "stopBtn" avant que 60 secondes ne se soient écoulées.

10.8.6 Exemple 6 : Une temporisation initiée via le DOM

Quand une implémentation gère les méthodes DOM décrites dans ce document, il est possible de démarrer et terminer la durée active d'un élément en utilisant un script ou quelqu'autre extension du navigateur. Quand un auteur désire un élément décrit comme étant interactif, la syntaxe suivante peut être utilisée :

<audio src="song1.au" begin="indefinite" />

L'élément ne commencera pas avant que la méthode beginElement() ne soit appelée.

10.9 Annexe C : Les différences par rapport à SMIL 1.0

SMIL 1.0 définit le modèle pour la temporisation, incluant le balisage pour décrire la temporisation des éléments, et les éléments définissant les conteneurs de temps parallèles et séquentiels. Cette version introduit quelques variations de syntaxe et des fonctionnalités supplémentaires, incluant :

La syntaxe complète est décrite ici, y compris la syntaxe qui n'a pas changée par rapport à SMIL 1.0.

10.10 Annexe D : La consolidation de la temporisation basée sur les événements et de la temporisation planifiée

Une motivation importante de SMIL 2.0 est le désir d'intégrer une planification déterministe déclarative avec une planification non-déterministe interactive. Le but est de fournir un modèle cohérent commun et une syntaxe simple.

Notez qu'un contenur « interactif » ne se rapporte pas simplement à de l'hypermédia avec une gestion des liens entre les documents, mais spécifiquement à un contenu dans une présentation (i.e., un document), qui est activé par un certaint mécanisme interactif (souvent des événements induits par l'utilisateur, mais également des hyperliens locaux).

SMIL 2.0 décrit des extensions à SMIL 1.0 pour gérer la temporisation interactive des éléments . Ces extensions permettent à l'auteur de spécifier qu'un élément doit commencer ou se terminer en réponse à un événement (tel qu'un événement induit par l'utilisateur, comme "activateEvent" ou "click") ou à l'activation d'un hyperlien, ou à l'appel d'une méthode DOM.

La syntaxe pour décrire ceci utilise les spécifications de valeur d'événement et la valeur d'argument spéciale "indefinite" pour les valeurs d'attribut de begin et end. Les valeurs d'événement décrivent des événements de l'interface utilisateur et d'autres événements. Si un élément ne devait commencer (ou se terminer) que par l'appel d'une méthode DOM, les attributs begin et end permettent à la valeur spéciale "indefinite" d'indiquer cela. Le paramétrage begin="indefinite" peut aussi s'employer quand un hyperlien sera utilisé pour démarrer l'élément. L'élément démarrera lors de l'activation de l'hyperlien (habituellement quand l'utilisateur clique sur l'ancre). Il n'est pas possible de contrôler la fin active d'un élément utilisant des hyperliens.

10.10.1 Historique

SMIL 2.0 représente une évolution par rapport aux environnements d'exécution multimédias antérieurs. Ceux-ci étaient soit de purs planificateurs statiques, soit de purs systèmes basés sur les événements. Les modèles planificateurs présentent un plan de montage chronologique linéaire qui intègre à la fois des médias discrets et continus. Les modèles planificateurs sont plutôt bons pour raconter une histoire, mais ont une gestion limitée de l'interaction avec l'utilisateur. Les systèmes reposant sur les événements, d'un autre côté, modélisent une présentation multimédia comme un graphe d'événements corrélés. Les systèmes reposant sur les événements offrent une gestion souple de l'interaction avec les utilisateurs, mais ont généralement des capacités de planification faibles ; ils sont le plus appropriés pour des expériences multimédias fortement interactives.

Le modèle de SMIL 1.0 est principalement un modèle de planification, mais avec certaines flexibilités pour gérer les médias continus sans durée déterminée. L'interaction avec l'utilisateur y est gérée sous la forme d'hyperliens temporisés, mais il n'y avait aucune gestion de l'activation individuelle des éléments via une interaction.

10.10.2 La modélisation d'un contenu interactif basé sur des événements dans SMIL

Pour intégrer un contenu interactif à la temporisation de SMIL, le modèle planificateur de SMIL 1.0 est étendu pour gérer plusieurs concepts nouveaux : une temporisation non-déterministe et une activation par événement.

Avec la temporisation non-déterministe, un élément a un temps pour begin, ou pour end, indéfini. L'élément existe toujours dans les contraintes du document, mais le temps de begin, ou de end, est déterminé par une certaine activation extérieure. L'activation peut reposer sur un événement (tel qu'un événement induit par l'utilisateur), un hyperlien (avec un hyperlien ciblant l'élément) ou le DOM (par un appel aux méthodes beginElement() ou beginElementAt()). Du point de vue de la planification, le temps est décrit comme non résolu.

La gestion de l'activation par événement fournit un moyen pour l'association d'un événement avec les temps de début ou de fin d'un élément. Quand l'événement est déclenché (par exemple, quand l'utilisateur clique sur quelquechose), le temps associé est résolu en un temps déterminé. Le début ou la fin effectives sont calculés à partir du temps où l'événement est déclenché plus ou moins un décalage spécifié.

Le temps calculé définit la synchronisation pour l'élément par rapport au conteneur de temps parent. Il est possible que les temps de début ou de fin calculés surviennent dans le passé, par exemple, quand une valeur de décalage négative est spécifiée, ou s'il y a un délai important entre le moment où l'événement est déclenché et le moment où il est géré par l'implémentation SMIL. Voir aussi la section « La gestion des décalages négatifs pour begin ».

Notez qu'une fin reposant sur un événement ne sera pas activée tant que l'élément n'aura pas commencé. Tout événement de fin spécifié est ignoré avant que l'élément ne commence.

Les contraintes imposées sur un élément par son conteneur de temps représentent un aspect important du modèle d'activation par événement. En particulier, quand un conteneur de temps est lui-même inactif (par exemple, avant qu'il ne commence ou après qu'il s'est terminé), aucun événement n'est géré par les enfants. Si le conteneur de temps est gelé, aucun événement n'est géré par les enfants. Aucune activation par événement n'a lieu à moins que le conteneur de temps ne soit actif. Par exemple :

<smil ...>
...
<par begin="10s" dur="5s">
   <audio src="song1.au" begin="btn1.activateEvent" />
</par>
...
</smil>

Si l'utilisateur active (par exemple, clique sur) l'élément "btn1" avant 10 secondes, ou après 15 secondes, l'élément audio ne sera pas joué. De plus, si l'élément audio commence mais devait s'étendre au-delà de la fin active spécifiée du conteneur de temps par, il est écourté par la fin active du conteneur de temps par.

Voir aussi « La sensibilité des événements ».


précédent   suivant   sommaire