précédent   suivant   sommaire  

4. Les modules de contrôle de contenu de SMIL 2.0

Rédacteurs
Dick Bulterman, (Dick.Bulterman@oratrix.com), Oratrix
Jeffrey Ayars (jeffa@real.com), RealNetworks

Table des matières

4.1 Introduction

Cette section définit les modules de contrôle de contenu de SMIL 2.0. Ces modules contiennent les éléments et les attributs qui offrent des choix de contenu à l'exécution et une livraison de contenu optimisée. La fonctionnalité de contrôle de contenu de SMIL se partage en quatre modules :

Puisque les attributs et les éléments de contrôle de contenu sont tous définis dans les modules, les concepteurs d'autres langages balisés peuvent réutiliser cette fonctionnalité, sur une base de module à module, quand ils ont besoin d'inclure un contrôle de contenu du média dans leur langage.

La fonctionnalité dans le module CustomTestAttributes s'appuie sur la fonctionnalité du module BasicContentControl ; les profils implémentant le module CustomTestAttributes doivent aussi implémenter le module BasicContentControl. Les modules PrefetchControl et SkipContentControl n'ont pas de conditions préalables.

Dans certaines descriptions des modules de contrôle de contenu, le concept de « préférence de l'utilisateur » peut être présent. Les préférences de l'utilisateur sont en général gérées par le logiciel en utilisant la boîte de dialogue de préférence, mais cette spécification ne met aucune restriction sur comment de telles préférences sont communiquées par l'utilisateur au lecteur SMIL.

L'évaluation des attributs de contrôle de contenu dépend de l'implémentation. Les attributs peuvent être évalués plusieurs fois. Une ré-évaluation dynamique est autorisée mais pas requise.

4.2 Le module BasicContentControl de SMIL 2.0

4.2.1 Aperçu du module BasicContentControl de SMIL 2.0

SMIL 1.0 fournit un mécanisme d'« attribut de test » pour traiter un élément seulement quand certaines conditions sont vraies, par exemple quand la préférence de langage spécifiée par l'utilisateur correspond à celle de l'objet média. Un ou plusieurs attributs de test peuvent apparaître sur les références des objets média ou sur les éléments de structure de temporisation ; si l'attribut est évalué à true, l'élément contenu est joué, sinon, il est ignoré. SMIL 1.0 fournit aussi l'élément switch pour exprimer qu'un ensemble de parties d'un document est alternatif, et que le premier qui remplit certaines conditions doit être choisi. C'est utile pour exprimer que différentes versions de langages d'un fichier audio sont disponibles et que le client peut sélectionner l'une d'entre elles.

Le module BasicContent de SMIL 2.0 inclut la fonctionnalité de l'attribut de test de SMIL 1.0 et l'étend en reconnaissant de nouveaux attributs de de test du système. Cette section décrira l'utilisation des attributs de test du système prédéfinis, l'élément switch et la mise en place en-ligne de l'attribut de test. Un mécanisme pour étendre les attributs de test est présenté dans le module CustomTestAttributes.

Les attributs de test du système prédéfinis

Cette spécification définit une liste d'attributs de test qui peuvent être ajoutés aux éléments du langage, comme autorisé par le concepteur du langage. Dans SMIL 1.0, ces éléments sont des éléments de synchronisation et de média. Conceptuellement, ces attributs représentent des tests booléens. Quand l'un des attributs de test spécifiés pour un élément est évalué à false, l'élément comportant cet attribut est ignoré.

SMIL 2.0 reconnaît le jeu complet des attributs de système de SMIL 1.0. Les attributs de test du système compatibles de SMIL 1.0 sont :

Remarquez que, avec l'exception de system-overdub-or-caption, les noms de ces attributs ont été changés pour refléter les conventions de casse alternée de SMIL 2.0. Les noms avec des traits-d'union de SMIL 1.0 sont dépréciés dans cette version.

Ce qui est nouveau dans SMIL 2.0, ce sont les attributs de test du système qui définissent des caractéristiques additionnelles à l'environnement système. Ceux ci sont :

La définition complète de chacun des ces attributs est donnée dans la section « Définition des attributs ».

L'élément switch

L'élément switch permet à un auteur de spécifier un ensemble d'éléments alternatifs dont seul le premier élément acceptable est choisi.

Un exemple d'utilisation de switch est : 

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

Dans cet exemple, un objet audio est sélectionné pour accompagner l'objet vidéo. Si le débit du système est de 56000 ou plus, l'objet dutchHQ.aiff est sélectionné. Si le débit du système est d'au moins 28800 mais inférieur à 56000, l'objet dutchMQ.aiff est sélectionné. Si aucun autre objet n'est sélectionné, l'alternative dutchLQ.aiff est sélectionnée, car il n'a aucun attribut de test (il est donc toujours acceptable) et car aucun attributs de test n'est valide.

Les auteurs doivent ranger les alternatives de la plus désirable à la moins désirable. De plus, les auteurs peuvent avoir envie de mettre en place une alternative relativement sûre en dernier élément du switch ce qui permettra à au moins un objet du switch d'être choisi (à moins que ce ne soit désiré).

Remarquez que certains protocoles réseaux, i.e., HTTP et RTSP, gèrent la négociation de contenu, qui peut être une alternative utilisée dans l'élément switch dans certains cas.

Il est de la responsabilité du lecteur SMIL 2.0 de déterminer le réglage des valeurs d'attributs de test du système. De tels réglages peuvent être déterminés de façon statique selon les réglages de la configuration, ou alors ils peuvent être déterminés (et ré-évalués) dynamiquement, en fonction de l'implémentation du lecteur. Certains lecteurs peuvent ne pas sélectionner les membres d'un switch au hasard.

L'utilisation en-ligne des attributs de test du système

Pour permettre plus de fléxibilité dans la sélection d'éléments, les attributs de test peuvent aussi être utilisés en dehors des éléments switch.

Dans l'exemple suivant d'utilisation en-ligne d'un attribut de test, les sous-titres ne sont affichés que si l'utilisateur les désire. 

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

Les alternatives indiquées par une construction en-ligne peuvent être représentées comme un jeu de déclarations switch, bien que le switch résultant puisse devenir explosif en taille. L'utilisation d'un mécanisme de test en-ligne simplifie de façon significative la spécification du contenu adaptatif, spécialement dans les cas où beaucoup d'alternatives indépendantes existent. Remarquez, toutefois, qu'il n'existe pas de mécanisme sûr pour les alternatives (comme de définir un élément sans attribut de test dans switch) en utilisant les attributs de test en-ligne.

Exemples d'utilisation des attributs de test et de l'élément switch

  1. Choisir entre différents contenus selon des débits différents

    Dans un scénario commun, une implémentation peut vouloir faire une sélection via un attribut systemBitrate sur les éléments. Le lecteur SMIL 2.0 évalue chacun des éléments dans le switch chacun à son tour, en cherchant une valeur de débit acceptable. 

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

    Dans cet exemple, si le débit du système est inférieur à 10000 (dans le cas des téléphones mobiles, par exemple), alors aucune des constructions par ne sera incluse.

  2. Choisir entre différentes ressources audio selon des débits différents

    Les éléments au sein du switch peuvent être n'importe quelle combinaison d'éléments. Par exemple, l'une pourrait spécifier une piste audio alternative : 

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

    Si le débit du système est inférieur à 16000, la qualité audio standard sera présentée par défaut.

  3. Choisir entre des ressources audio dans différentes langues

    Dans l'exemple suivant, une ressource audio est disponible à la fois en néerlandais et en anglais. En se basant sur la langue préférée de l'utilisateur, le lecteur peut choisir l'une de ces ressources audio. 

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

    Dans cet exemple, si le paramétrage de langue du système était autre chose que du néerlandais ou de l'anglais, alors, aucune présentation audio ne serait faite. Pour faire qu'un choix soit utilisé par défaut, il doit apparaître en dernier dans la liste et ne pas contenir d'attribut de test. Dans le fragment suivant, l'anglais est choisi par défaut : 

     ...
 <switch>
    <audio src="joe-audio-nederlands" systemLanguage="nl"/>
    <audio src="joe-audio-english" />
 </switch>
 ...
  4. Choisir entre des contenus écrits pour différents modes d'affichage

    Dans l'exemple suivant, la présentation contient des parties alternatives réalisées pour des résolutions et des profondeurs de pixels différents. En fonction des caractéristiques de l'écran, le lecteur va utiliser la première alternative pour laquelle tous les attributs de test seront vrais. 

     ...
 <par>
    <text .../>
    <switch>
       <par systemScreenSize="1024X1280" systemScreenDepth="16">
       ...
       </par>
       <par systemScreenSize="480X640" systemScreenDepth="32">
       ...
       </par>
       <par systemScreenSize="480X640" systemScreenDepth="16">
       ...
       </par>
    </switch>
 </par>
 ...
  5. Gérer de multiples options via une utilisation en-ligne

    Cet exemple montre une video accompagnée par zéro ou plusieurs objets média. Si la langue du système est réglée soit sur anglais, soit sur néerlandais, alors l'objet audio approprié sera joué. De plus, si la langue du système est réglée sur néerlandais ou anglais et que l'attribut systemCaptions a également la valeur on, alors les fichiers textes appropriés apparaîtront. 

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

    Si la langue du système est réglée sur autre chose que néerlandais ou anglais, alors aucun objet ne sera interprété (à part la vidéo). Remarquez qu'il n'y a pas de mécanisme de sélection par défaut quand on utilise les attributs de test pour une évaluation en-ligne.

  6. Choisir le langage du doublage et les pistes pour les sous-titres

    Dans l'exemple suivant, un film français est disponible avec un doublage et des sous-titres en anglais, en allemand, et en néerlandais. Le segment SMIL suivant exprime ce fait et sélectionne l'alternative que l'utilisateur préfère. 

     ...
 <par>
    <switch>
       <audio src="movie-aud-en.rm" systemLanguage="en"
	     systemOverdubOrSubtitle="overdub"/>
       <audio src="movie-aud-de.rm" systemLanguage="de"
	     systemOverdubOrSubtitle="overdub"/>
       <audio src="movie-aud-nl.rm" systemLanguage="nl"
	     systemOverdubOrSubtitle="overdub"/>
       <!-- Français pour les autres -->
       <audio src="movie-aud-fr.rm"/>
    </switch>
    <video src="movie-vid.rm"/>
    <switch>
       <textstream src="movie-sub-en.rt" systemLanguage="en"
	     systemOverdubOrSubtitle="subtitle"/>
       <textstream src="movie-sub-de.rt" systemLanguage="de"
	     systemOverdubOrSubtitle="subtitle"/>
       <textstream src="movie-sub-nl.rt" systemLanguage="nl"
	     systemOverdubOrSubtitle="subtitle"/>
       <!-- sous-titres français pour ceux qui les veulent vraiment -->
       <textstream src="movie-caps-fr.rt" systemCaptions="on"/>
    </switch>
 </par>
 ...

4.2.2 Les éléments et attributs

Le module BasicContentControl de SMIL 2.0 définit l'élément switch et un jeu d'attributs de test du système prédéfinis.

L'élément switch

L'élément switch permet à un auteur de spécifier un ensemble d'éléments alternatifs. Un élément est sélectionné comme suit : le lecteur évalue les éléments dans l'ordre dans lequel ils apparaissent dans l'élément switch. Le premier élément acceptable est sélectionné et tous les autres éléments du switch sont exclus. Les implémentations NE DOIVENT PAS prendre arbitrairement un objet du switch quand les tests d'attribut pour tous les éléments fils échouent.

Attributs de l'élément

Cet élément n'a pas d'attributs au-delà de ceux requis par tous les éléments de ce profil.

Contenu de l'élément

Le contenu de cet élément est dépendant de l'implémentation du langage.

Dans le profil de langage SMIL 2.0, si l'élément switch est utilisé comme enfant direct ou indirect d'un élément body, il peut contenir n'importe quel objet média ou conteneur de structure de temporisation, ou il peut contenir des éléments switch imbriqués. Tous ces éléments peuvent apparaître plusieurs fois au sein du switch. Si le switch est utilisé comme enfant direct ou indirect d'un élément head, il peut contenir un ou plusieurs éléments layout.

Attributs de test prédéfinis

SMIL 2.0 définit les attributs de test du système suivants. Si n'importe lequel des attributs de test spécifiés pour un élément est évalué à false, l'élément portant cet attribut est ignoré. Notez que la plupart des noms d'attributs de test avec des traits d'union de SMIL 1.0 ont été dépréciés en faveur de noms utilisant la convention en casse alternée courante de SMIL. Pour ceux-ci, le nom déprécié de SMIL 1.0 est montré entre parenthèses après le nom préféré.

systemAudioDesc
valeurs : on | off
Cet attribut de test spécifie si oui ou non les descriptions audio fermées doivent être interprétées. Cela a été fait intentionnellement pour fournir aux auteurs la possibilité de gérer des descriptions audio de la même façon que l'attribut systemCaptions fournit des sous-titres. La valeur de systemAudioDesc est utilisée pour contrôler l'interprétation des objets en conjonction avec les préférences de l'utilisateur pour recevoir des descriptions audio d'un objet média si et quand celles-ci sont disponibles. Une valeur de on indique une préférence pour que de telles descriptions soient interprétées quand elles sont disponibles. Une valeur de off indique une préférence pour que de telles descriptions ne soient pas interprétées.
Les auteurs devraient mettre systemAudioDesc = on seulement sur les éléments qu'ils souhaitent interpréter quand l'utilisateur a indiqué qu'il veut des descriptions audio. Les auteurs devraient mettre systemAudioDesc = off seulement sur les éléments qu'ils souhaitent interpréter quand l'utilisateur a indiqué qu'il NE VEUT PAS de description audio.
C'est évalué à true si les préférences de l'utilisateur concordent avec cette valeur d'attribut. C'est évalué à false si ça ne concorde pas.
systemBitrate (system-bitrate)
valeur : la bande passante approximative, en bits par seconde, disponible pour le système.
La mesure de cette bande passante est spécifique à l'application, ce qui signifie que les applications peuvent utiliser des moyens sophistiqués pour la mesure de la connectivité de bout-en-bout, ou alors un simple réglage statique contrôlé par l'utilisateur. Dans ce dernier cas, cela pourrait par exemple être utilisé pour faire un choix basé sur la connexion au réseau de l'utilisateur. Des valeurs typiques pour des utilisateurs avec des modems seraient 14400, 28800, 56000 bit/s, etc. C'est évalué à true si le débit disponible du système est égal ou supérieur à la valeur donnée. C'est évalué à false si le débit disponible du système est inférieur à la valeur donnée.
L'attribut peut comprendre des valeurs entières supérieures à 0. Si la valeur excède une valeur de débit maximum définie par l'implémentation, l'attribut est toujours évalué à false.
systemCaptions (system-captions)
valeurs : on | off
Cet attribut permet aux auteurs de spécifier un texte redondant équivalent à la portion audio de la présentation. Comme exemples d'utilisation prévus : les publics malentendants, ceux qui apprennent à lire, ou quiconque voudrait avoir cette information.
C'est évalué à true si les préférences de l'utilisateur concordent avec cette valeur. C'est évalué à false si ça ne concorde pas.
systemComponent
valeur : une chaîne de caractères CDATA XML contenant un ou plusieurs URI séparés par des blancs.
Chaque URI identifie un composant du système de lecture, i.e., les caractéristiques/composants de l'agent utilisateur, le nombre de canaux audio, les codecs, le décodeur HW MPEG, etc. L'URI est dépendant de l'implémentation. Chaque implémentation est encouragée à publier une liste de composants d'URI qui peuvent être utilisées pour identifier et résoudre la présence de composants dépendants de l'implémentation.
C'est évalué à true si la valeur résultante est true. C'est évalué à false sinon errata-E11.
systemCPU
valeur : un NMTOKENXML [XML10].
Cet attribut de test spécifie le processeur (CPU) sur lequel un agent utilisateur pourrait tourner. Une implémentation doit permettre à l'utilisateur de régler la valeur système à unknown pour la confidentialité.
La liste suivante contient les valeurs suggérées pour cet attribut de test (des noms additionnels peuvent être reconnus par une implémentation) : alpha, arm, arm32, hppa1.1, m68k, mips, ppc, rs6000, vax, x86, unknown.

Ces valeurs proviennent des constantes _PR_SI_ARCHITECTURE définies par le projet mozilla.

C'est évalué à true si les préférences de l'utilisateur concordent avec cette valeur d'attribut. C'est évalué à false si ça ne concorde pas. La valeur est sensible a la casse utilisée.
systemLanguage (system-language)
valeurs : une liste de noms de langue séparés par des virgules, comme définis dans le [RFC1766], ou une chaîne de caractère vide
Cet attribut est évalué à true (1) si l'une des langues indiquées par les préférences de l'utilisateur est strictement égale à l'une des langues données en valeurs de ce paramètre, ou (2) si l'une des langues indiquées par les préférences de l'utilisateur correspond exactement au préfixe d'une des langues données en valeurs de ce paramètre, de telle sorte que le premier caractère balise suivant le préfixe soit "-". C'est évalué à false sinon. Par exemple, si l'anglais générique est spécifié dans les préférences de l'utilisateur, ça va correspondre à la fois à "en" pour le cas (1) et "en-gb" ( anglais de Grande-Bretagne) pour le cas (2), mais si l'anglais de Grande-Bretagne est spécifié dans les préférences de l'utilisateur, ça va correspondre seulement à "en-gb" selon le cas (1).
Si une chaîne de caractère vide ou nulle est spécifiée, l'attribut de test sera évalué à false.

La syntaxe de l'attribut systemLanguage et de l'attribut déprécié system-language est définie à l'aide de la notation EBNF (comme définie dans [XML10]) comme une liste de préfixes d'espace de nommage XML [XML-NS], séparés par le caractère « , » : 

 systemLanguageArgumentValue ::= (tagLangage (S? ',' S? tagLangage)*)?

Les endroits où sont autorisés des espaces sont indiqués par un « S », défini comme suit (pris de la définition pour « S » dans [XML10]) : 

S ::= (#x20 | #x9 | #xD | #xA)+

Pour l'implémentation : au moment de proposer une préférence linguistique à l'utilisateur, les implémenteurs doivent prendre en compte le fait que la plupart des utilisateurs ne sont pas familiers avec les détails de correspondance de langue, décrits ci-dessus, et ils devraient fournir un guidage approprié. Par exemple, les utilisateurs peuvent penser à tort qu'en sélectionnant "en-gb", ils vont avoir n'importe quel type d'anglais si l'anglais britannique n'est pas disponible. L'interface utilisateur qui sert à régler les préférences de l'utilisateur doit inciter l'utilisateur à choisir "en" pour avoir le meilleur résultat.

systemOperatingSystem
valeur : un NMTOKEN XML [XML10].
Cet attribut de test spécifie le système d'exploitation sur lequel l'agent utilisateur peut tourner. Une implémentation doit donner à l'utilisateur la possibilité de régler les préférences de l'utilisateur à unknown pour respecter la confidentialité.
La liste suivante contient les valeurs suggérées pour cet attribut de test (des noms additionnels peuvent être reconnus par une implémentation) : aix, beos, bsdi, dgux, freebsd, hpux, irix, linux, macos, ncr, nec, netbsd, nextstep, nto, openbsd, openvms, os2, osf, palmos, qnx, sinix, rhapsody, sco, solaris, sonly, sunos, unixware, win16, win32, win9x, winnt, wince, unknown.

Ces valeurs proviennent des constantes _PR_SI_SYSNAME définies par le projet mozilla.

C'est évalué à true si les préférences de l'utilisateur correspondent à la valeur de l'attribut. C'est évalué à false sinon. La valeur est sensible à la casse utilisée.
systemOverdubOrSubtitle
valeurs : overdub | subtitle
Cet attribut spécifie si un doublage ou des sous-titres sont interprétés. overdub sélectionne en remplacement une piste vocale à la place d'une autre, et subtitle veut dire que l'utilisateur préfère l'affichage d'un texte dans un langage autre que celui utilisé par la piste audio.
C'est évalué à true si la préférence de l'utilisateur correspond à la valeur de cet attribut. C'est évalué à false sinon.
system-overdub-or-caption
valeurs : caption | overdub
Cet attribut de test a été déprécié en faveur de l'utilisation des attributs systemOverdubOrSubtitle et systemCaptions.
Cet attribut est un réglage qui détermine si l'utilisateur préfère le doublage ou des sous-titres quand l'option est disponible.
C'est évalué à true si la préférence de l'utilisateur correspond à la valeur de l'attribut. C'est évalué à false sinon.
systemRequired (system-required)
valeur : liste d'extensions de langage de préfixes d'espace de nommage
Ces attributs fournissent un mécanisme d'extension pour de nouveaux éléments ou attributs. C'est évalué à true si toutes les extensions de la liste sont gérées par l'implémentation, sinon, c'est évalué à false. La syntaxe de l'attribut systemRequired et de l'attribut déprécié system-required est définie en utilisant la notation EBNF (comme défini dans [XML10]) comme liste de préfixes d'espace de nommage XML [XML-NS], séparés par le caractère « + » : 
 systemRequiredArgumentValue := NMTOKEN (S? '+' S? NMTOKEN)*

Les endroits où des espaces sont autorisés sont indiqués par un « S », défini comme suit (pris de la définition de un « S » de [XML10]) : 

S ::= (#x20 | #x9 | #xD | #xA)+
systemScreenDepth (system-screen-depth)
valeurs : un nombre supérieur à 0
Cet attribut spécifie la profondeur de la palette de couleur de l'écran en bits requis pour afficher l'élément. Les valeurs typiques sont 1 | 4 | 8 | 24 | 32.
C'est évalué à true si le moteur de lecture est capable d'afficher des images ou des vidéos avec la profondeur donnée. C'est évalué à false si le moteur de lecture n'est pas capable d'afficher des images ou des vidéos avec une plus faible profondeur.
systemScreenSize (system-screen-size)
valeur : la taille d'un écran
Les valeurs d'attribut ont la syntaxe suivante :
taille-écran ::= hauteur-ecran"X"largeur-ecran
Chacune de ces valeurs est exprimée en pixels, et doit être un entier supérieur à 0.
C'est évalué à true si le moteur de lecture est capable d'afficher une présentation à la taille donnée. C'est évalué à false si le moteur de lecture ne peut afficher que des plus petites présentations.

Il est de la responsabilité du lecteur SMIL 2.0 de déterminer les réglages pour chaque variable de test prédéfinie. Ces valeurs peuvent être déterminées par des réglages de configuration statiques, ou ils peuvent être évalués dynamiquement durant l'exécution. Un tel réglage et le comportement de (ré)évaluation est dépendant de l'implémentation.

Pour cette version de SMIL, les éléments avec des attributs de test spécifiés qui qui ne sont pas vérifiés, ou les éléments à l'intérieur d'un élément switch qui ne sont pas sélectionnés, sont sensés être ignorés et se comporteront comme s'ils n'étaient pas spécifiés dans le document. Chacune des références à ces éléments se fera comme si ces éléments n'étaient pas dans le document. En particulier, toutes les références d'ID à cet élément se comporteront comme s'il n'y avait pas d'élément avec un tel identifiant. Les langages qui intègrent ce module doivent spécifier tout comportement supplémentaire en rapport avec ces éléments ignorés. Dans le profil de langage SMIL 2.0, les attributs de temporisation qui référencent des ID invalides sont traités comme étant indéfinis.

Les auteurs doivent savoir que ce modèle de gestion des éléments ignorés peut être revu dans une future version de SMIL, tout comme les sémantiques relatives peuvent aussi changer. Ces changements ne devraient pas affecter les implémentations qui ne gèrent l'évaluation des attributs de test et/ou de l'élément switch qu'au moment de l'analyse (ou équivalent). Cependant, les sémantiques de ré-évaluation dynamique (i.e., la ré-évaluation durant la présentation du document) des attributs de test et/ou de l'élément switch ne sont pas définis dans cette version de SMIL ; cela sera fait dans une version future.

Les auteurs doivent réaliser que si de nombreux éléments alternatifs sont inclus dans un switch, et qu'aucun d'eux n'est vérifié, cela peut mener à des situations où un objet média est montré sans un ou plusieurs objets compagnons. Il est donc recommandé d'inclure un choix « attrape-tout » à la fin du switch switch qui serait acceptable dans toutes les situations.

4.2.3 Les exigences d'intégration pour le module BasicContentControl

La fonctionnalité dans ce module ne met pas à profit les fonctionnalités définies dans d'autres modules SMIL 2.0.

4.2.4 La définition de type de document (DTD) pour le module BasicContentControl

Voir le DTD complet pour les modules de contrôle de contenu de SMIL.

4.3 Le module CustomTestAttributes de SMIL 2.0

4.3.1 Aperçu du module CustomTestAttributes de SMIL 2.0

L'utilisation d'attributs de test du système prédéfinis dans le module BasicContentControl de SMIL fournit un mécanisme de sélection basé sur des attributs qui sont fixés dans la définition du module. Le module CustomTestAttribute étend cette facilité avec la définition d'attributs de test personnalisés définis par l'auteur. Les attributs de test personnalisés permettent aux auteurs de présentation de définir leurs propres attributs de test pour une utilisation dans un document spécifique. Les attributs de test personnalisés peuvent être partagés entre les documents d'une application en utilisant l'attribut uid.

Comme avec les attributs de test du système, les attributs de test personnalisés peuvent être utilisés dans les éléments des structures de temporisation et des objets média ; s'ils sont évalués à true, l'élément conteneur est activé et s'ils sont évalués à false, l'élément conteneur est ignoré. Dans cette version de SMIL, un élément ignoré sera traité comme s'il ne faisait pas partie du document source. Ainsi, élément référençant l'ID du nœud ignoré référencera alors un ID invalide. Les langages qui intègrent ce module doivent spécifier tout comportement supplémentaire relatif à ces éléments ignorés.

Étant donné que les attributs de test personnalisés sont spécifiques à une application/un document, ils nécessitent un mécanisme permettant la définition et le paramétrage des attributs. La définition des attributs est réalisée via les éléments customAttributes et customTest. L'état initial de tout attribut de test personnalisé peut être réglé par l'auteur avec l'attribut defaultState, qui prend les valeurs true ou false. Ce module fournit un attribut override avec une valeur hidden qui donne à l'auteur la possibilité d'empêcher, lors de l'exécution, la ré-initialisation de tout attribut utilisant ces mécanismes.

L'état de l'attribut peut être changé de trois façons :

  1. en modifiant la valeur de l'état par défaut de l'attribut dans un document source avant qu'il ne soit joué par le lecteur ;
  2. en utilisant l'identifiant unique donné dans l'attribut uid pour dé-référencer une valeur d'éxécution pour l'attribut customTest ;
  3. par une interface présentée à l'utilisateur (ou l'agent utilisateur) au travers du lecteur du document pendant l'éxécution.

Les règles exactes pour le l'initialisation et la modification de valeurs associées aux attributs de test personnalisés sont données ci-dessous.

Une implémentation peut gérer soit les deux, soit aucune des méthodes 2 et 3. Si la méthode 2 est gérée, la valeur de l'URI dans l'attribut uid est simplement un identifiant unique et n'implique pas que la valeur d'exécution soit ramenée via le Web. La valeur peut être stockée et extraite localement, et identifiée simplement par son uid. La manière précise dont ceci est réalisé est dépendant de l'implémentation. Si la méthode 3 est gérée, la facilité de l'attribut de test personnalisé ne requiert pas le support d'identifiant spécifique pour une manipulation de l'utilisateur directe de l'attribut de test commun.

Exemple d'utilisation

L'exemple suivant montre une façon d'appliquer des attributs de test personnalisés dans un document du profil de langage SMIL 2.0 : 

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

L'élément customAttributes dans l'en-tête contient la définition des attributs de test personnalisés disponibles. Chaque attribut de test personnalisé, défini par l'élément customTest, contient un identifiant et un titre (qui peut être utilisé par un agent utilisateur, si disponible, pour marquer cet attribut), ainsi qu'une définition d'état initial (optionnel), un UID qui contient un identifiant unique pour la valeur de paramétrage pour cet attribut et un drapeau de ré-écriture.

Les variables de test personnalisées nommées "west-coast", "east-coast" et "far-north" sont définies avec un état de rendu par défaut à false. Ils contiennent chacun une référence à un URI qui est utilisé pour définir des réglages locaux pour les variables respectives.

La variable de test personnalisée "the-rest" est définie avec un réglage de rendu par défaut à true.

A l'intérieur du body, une construction switch SMIL est utilisée pour sélectionner des objets média à inclure dans une présentation dépendant des valeurs des divers attributs de test personnalisés. Le premier objet qui contient une valeur à true sera interprété et comme, dans cet exemple, la dernière option sera toujours à true, elle sera interprétée si aucun autre objet ne peut être évalué true.

Même si cet exemple montre une utilisation des attributs de test personnalisés basée sur l'élément switch, la facilité peut aussi être appliquée comme attributs de test dans un usage en-ligne.

Les règles de paramétrage des valeurs

Le réglage de la valeur associée à un attribut de test personnalisé se fait comme suit :

  1. Le réglage initial est pris de la valeur de l'attribut defaultState, s'il est présent. Si aucun état par défaut n'est défini explicitement, une valeur de false est utilisée ;
  2. Ensuite, si le mécanisme de l'URI est géré par l'implémentation, l'URI défini par l'attribut uid est examiné pour voir si une valeur persistante a été définie pour l'attribut de test personnalisé avec l'identifient associé. Si une telle valeur est présente, elle est utilisée à la place de l'état par défaut défini dans le document (s'il y en a un). Sinon, l'état initial existant est maintenu ;
  3. Ensuite, si un mécanisme basé sur l'UI (soit via le DOM SMIL, un lecteur GUI ou par un autre moyen) est disponible et qu'une valeur a été mise par l'utilisateur, la valeur associée à l'attribut de test personnalisé prend la valeur de spécification de l'utilisateur. Si aucune préférence n'a été définie par l'utilisateur, soit la valeur basée sur l'UID, soit la valeur par défaut issue du texte du document (dans cet ordre) est utilisée.

Remarquez que le paramétrage de l'attribut de test personnalisé de l'utilisateur prendra le pas sur celui d'un URI. Si l'utilisateur n'a spécifié aucune valeur pour l'attribut alors le paramétrage de l'URI aura priorité. Comme avec les attributs de test du système prédéfinis, cette évaluation aura lieu d'une façon définie par l'implémentation. La valeur peut être (ré)évaluée dynamiquement, mais ce n'est pas nécessaire. Notez aussi que les implémentations n'ont pas toutes besoin de gérer l'attribut uid ou le paramétrage via une interface utilisateur des attributs.

4.3.2 Les éléments et attributs

Cette section définit les éléments et les attributs qui font la fonctionnalité du module CustomTestAttributes de SMIL. Les éléments customAttributes et customTest sont utilisés pour définir des variables d'attributs de test personnalisés et l'attribut customTest est utilisé en-ligne sur les références d'objet média et structures de temporisation pour contrôler l'évaluation des éléments conteneurs.

L'élément customAttributes

L'élément customAttributes contient les définitions de chacun des attributs de test personnalisés. Les éléments contenus définissent une collection d'attributs de test spécifiés par l'auteur qui peuvent être utilisés dans des déclarations switch ou en-ligne comme attributs de test dans le document.

Attributs de l'élément

Cet élément n'a pas d'attributs au-delà de ceux requis pour tous les éléments dans le profil.

Contenu de l'élément

L'élément customAttributes peut contenir un ou plusieurs éléments customTest.

L'élément customTest

L'élément customTest définit un nom spécifié par l'auteur qui va être utilisé comme argument de test dans un élément switch ou en-ligne dans des éléments objet média et structure de temporisation. Les éléments customTest sont définis au sein des sections tracées par les éléments customAttributes qui forment une partie de l'en-tête du document.

Attributs de l'élément
defaultState
valeurs : true | false
L'état initial pour la variable de test personnalisée nommée est donné par la valeur de cet attribut. S'il n'est pas spécifié, il est à false par défaut.
L'état d'éxécution pour la variable de test personnalisée nommée peut être réglée selon les règles de traitement des attributs uid et/ou override, si présent. Les valeurs ne sont pas sensibles à la casse.
override
valeurs: visible | hidden
Cet attribut permet à l'auteur de choisir si la possibilité de surclasser l'état initial d'une variable de test personnalisée devrait être présentée à l'utilisateur typique, ou si le choix devrait être réservé aux utilisateurs qui expriment spécifiquement une préférence pour cet accès. Si la valeur de l'attribut override est visible, alors l'agent utilisateur doit rendre disponible pour l'utilisateur un moyen de régler la valeur de la variable de test personnalisée dans sa configuration par défaut soit directement, via le DOM SMIL, soit via un autre mécanisme. Si la valeur de l'attribut override est hidden, alors l'agent utilisateur ne doit pas présenter à l'utilisateur un moyen de régler la valeur de l'attribut personnalisé, à moins que l'utilisateur n'ait exprimé une préférence pour cet accès. Les valeurs ne sont pas sensibles à la casse. La valeur par défaut est hidden.
uid
valeurs : un URI
L'URI identifie le test personnalisé associé pour une utilisation persistante. L'agent utilisateur devrait l'utiliser comme la clé pour ranger et extraire les valeurs associées à l'attribut de test personnalisé et s'assurer que les questions de sécurité et de confidentialité soient prises en compte. Si l'attribut override le permet, une référence résolue à un réglage via l'attribut uid définit le réglage initial de la valeur de test personnalisée ; cette valeur peut être surclassée par l'utilisateur/l'agent utilisateur si c'est autorisé par l'attribut override. C'est à l'environnement d'éxécution de faire valoir cet attribut.

Le mécanisme d'évaluation effectif associé à l'URI est dépendant de l'implémentation. Cela peut varier d'une simple lecture dans un fichier local, ou un registre, à une référence sécurisée via les capacités d'une base de données, et cela peut être influencé par les autres réglages de configuration fournis par l'implémentation.

Contenu de l'élément

Aucun.

L'attribut customTest

En plus des éléments customAttributes et customTest, ce module fournit un attribut customTest qui peut être appliqué par les concepteurs de langage aux objets médias et aux éléments de structure de temporisation requérant une sélection. Dans tous les aspects opérationnels, l'attribut de test personnalisé est similaire à la facilité de l'attribut de test du système prédéfini du module BasicContentControl.

customTest
valeur : une liste d'identifiants XML
Les identifiants, définis dans les éléments customTest, définissent des variables qui sont évaluées comme des attributs de test. Si les variables sont toutes évaluées à true, l'élément associé est évalué, sinon celui-ci et son contenu sont sautés. Les attributs customTest dont les valeurs ne correspondent pas avec l'identifiant d'un élément customTest sont évalués comme étant false.

La syntaxe de l'attribut customTest est définie en utilisant la notation EBNF (comme définie dans [XML10]) comme une liste de références d'identifiants d'éléments de customTest, séparées par le caractère « + » : 

 valeurArgumentTestPersonnalisée := IDREF (S? '+' S? IDREF)*

Les endroits où des espaces sont autorisés sont indiqués par un « S », défini comme suit (pris de la définition de « S » de [XML10]) :

S ::= (#x20 | #x9 | #xD | #xA)+

4.3.3 Les exigences d'intégration pour le module CustomTestAttribute

La fonctionnalité dans ce module s'appuie sur la fonctionnalité définie dans le module BasicContentControl, qui est une condition nécessaire pour l'inclusion du module CustomTestAttribute.

Le profil implémentant les éléments et les attributs de test personnalisés doit fournir un moyen d'associer un identifiant unique XML avec un élément customTest, pour qu'il soit utilisé par l'attribut customTest. Et le profil doit fournir un moyen d'associer un texte descriptif à un élément customTest, qui peut être utilisé dans un GUI ou un autre mécanisme de sélection pouvant être présenté à l'utilisateur. Pour le profil de langage SMIL 2.0, les attributs id et title de l'élément servent cette intention.

4.3.4 La définition de type de document pour le module CustomTestAttribute

Voir le DTD complet des modules de contrôle de contenu SMIL.

4.4 Le module PrefetchControl de SMIL 2.0

4.4.1 Aperçu du module PrefetchControl de SMIL 2.0

Ce module définit un élément et des attributs qui peuvent être utilisés pour contrôler le rapport d'un contenu à partir d'un serveur d'une façon qui va améliorer la performance de rendu du document.

Cet élément donnera une suggestion ou indication à l'agent utilisateur qu'une ressource média sera utilisée dans le futur et que l'auteur voudrait que tout ou partie de la ressource soit d'abord ramenée dans le futur pour que la lecture du document soit plus uniforme. Les agents utilisateurs peuvent ignorer les éléments prefetch, mais agir ainsi peut provoquer une interruption dans la lecture du document quand la ressource est nécessaire. Cela donne aux outils de développement ou aux auteurs prévoyants la possibilité de planifier la récupération des ressources quand ils pensent qu'il y a de la bande passante ou du temps pour le faire. Un élément prefetch est dans le corps du document XML, et sa planification est basée sur son ordre lexical à moins qu'une temporisation explicite ne soit présente.

Le fait d'aller rechercher par avance des données à partir d'un URL qui change le contenu dynamiquement est potentiellement dangereux : si la ressource entière n'est pas ramenée en avance, une requête ultérieure pour les données restantes peut rapporter les données d'une nouvelle ressource. Un agent utilisateur devrait respecter toute directives de mise en cache appropriée appliquée au contenu, par exemple, des en-têtes 822 pas de cache dans HTTP. Plus particulièrement, un contenu marqué comme ne pouvant être mis en mémoire devra être recherché à chaque fois qu'il est joué, alors qu'un contenu qui peut être mis en mémoire ne sera recherché qu'une seule fois, avec le contenu pré-ramené en mémoire pour les utilisations futures.

Exemples

  1. Ramener en avance une image pour qu'elle soit affichée immédiatement après que la vidéo se termine : 
     <smil xmlns="http://www.w3.org/2001/SMIL20/Language">
   <body>
     <seq>
       <par>
         <prefetch id="endimage"
	    src="http://www.example.org/logo.gif"/>
         <text id="interlude"
	    src="http://www.example.org/pleasewait.html" fill="freeze"/>
       </par>
       <video id="main-event" src="rtsp://www.example.org/video.mpg"/>
       <img src="http://www.example.org/logo.gif" dur="5s"/>  
    </seq>
   </body>
 </smil>

    Cet exemple commence avec un pré-rapport en parallèle avec le rendu d'un objet de texte. Le texte est un média discret, donc il se termine immédiatement, le pré-rapport est réglé par défaut pour pré-ramener l'image entièrement avec toute la bande passante disponible et l'élément prefetch se termine quand l'image est téléchargée. Cela termine le <par> et la vidéo commence à jouer. Quand la vidéo est finie, l'image est affichée ;

  2. Ramener en avance les images pour un bouton pour que la substitution des images intervienne rapidement pour l'utilisateur final : 
     <html>
 <body>
     <prefetch id="upimage" src="http://www.example.org/up.gif"/>
     <prefetch id="downimage" src="http://www.example.org/down.gif"/>
     ....
     <!-- le script qui va changer le graphique -->
     <img src="http://www.example.org/up.gif"/>
   </body>
 </html>

4.4.2 Les éléments et attributs

L'elément prefetch

L'élément prefetch donne aux auteurs un mécanisme pour influencer la planification des transferts des objets médias du serveur vers le lecteur.

Les documents doivent toujours être joués même si les éléments prefetch sont ignorés, bien que des pauses ou des nouvelles mises en mémoire tampon puissent survenir. Si un élément prefetch est ignoré, la temporisation de l'élément est respectée, i.e., si un élément prefetch a une durée dur="5s", les éléments qui dépendent de la temporisation de l'élément prefetch se comportent comme si le le pré-rapport avait pris 5 secondes.

La durée intrinsèque d'un élément prefetch est soit la durée du média cherché, si l'opération de pré-rapport est gérée, soit zéro si celle-ci ne l'est pas.

Si un élément prefetch est répété, à cause du redémarrage ou de la répétition d'un élément parent, l'opération de pré-rapport devrait avoir lieu encore une fois. Cela assure que les données « fraîches » appropriées soit affichées si, par exemple, le pré-rapport concerne un URL vers une bannière de publicité dont le contenu change à chaque requête.

Attributs de l'élément

L'élément prefetch reconnaît les attributs suivants :

mediaSize
valeurs : bytes-value | percent-value
Définit la quantité de ressource à aller chercher, comme une fonction de la taille du fichier de la ressource. Pour aller chercher la totalité de la ressource sans connaître sa taille, il faut spécifier 100%. Par défaut, c'est 100%.
mediaTime
valeurs : clock-value | percent-value
Définit la quantité de ressource à aller chercher, comme une fonction de la durée de la ressource. Pour aller chercher la totalité de la ressource sans connaître sa taille, il faut spécifier 100%. Par défaut, c'est 100%.
Pour un média discret ( un média qui ne serait pas basé sur le temps, comme les types de média "text/html" ou "image/png"), l'utilisation de cet attribut entraîne le rapport de la ressource entière.
bandwidth
valeurs : bitrate-value | percent-value
Définit la quantité de la bande passante réseau que l'agent utilisateur devrait utiliser pour pré-rapporter le média. Pour utiliser tout ce qui est disponible, il faut spécifier 100%. Par défaut, c'est 100%.

Un attribut avec une valeur de "0%" est ignoré et traité comme si l'attribut n'avait pas été spécifié.

Si les deux attributs mediaSize et mediaTime sont spécifiés, mediaSize est utilisé et mediaTime est ignoré.

Si les attributs clipBegin et clipEnd dans un objet média sont différents de ce qui est spécifié dans l'élément prefetch, une implémentation peut utiliser n'importe lesquelles des données qui ont été ramenées mais le résultat peut ne pas être optimal.

Syntaxe des valeurs d'attribut
bytes-value
La valeur bytes-value a la syntaxe suivante :

bytes-value ::= Digit+; n'importe quel nombre positif

percent-value
La valeur percent-val a la syntaxe suivante :

percent-value ::= Digit+ "%"; n'importe quel nombre positif entre 0 et 100

clock-value
La valeur clock-value a la syntaxe suivante : 
Clock-val	   ::= ( Hms-val | Smpte-val )
Smpte-val 	::= ( Smpte-type )? Hours ":" Minutes ":" Seconds 
			    ( ":" Frames ( "." Subframes )? )?
Smpte-type	::= "smpte" | "smpte-30-drop" | "smpte-25"
Hms-val		::= ( "npt=" )? (Full-clock-val | Partial-clock-val 
			    | Timecount-val)
Full-clock-val	::= Hours ":" Minutes ":" Seconds ("." Fraction)?
Partial-clock-val ::= Minutes ":" Seconds ("." Fraction)?
Timecount-val	::= Timecount ("." Fraction)? (Metric)?
Metric		::= "h" | "min" | "s" | "ms"
Hours		::= DIGIT+; n'importe quel nombre positif
Minutes		::= 2DIGIT; de 00 à 59
Seconds		::= 2DIGIT; de 00 à 59
Frames		::= 2DIGIT; intervalle de smpte = 00-29, intervalle de smpte-30-drop = 00-29, intervalle de smpte-25 = 00-24
Subframes 	::= 2DIGIT; intervalle de smpte = 00-01, intervalle de smpte-30-drop = 00-01, intervalle de smpte-25 = 00-01
Fraction		::= DIGIT+
Timecount 	::= DIGIT+
2DIGIT		::= DIGIT DIGIT
DIGIT		::= [0-9]

Pour les valeurs Timecount, le suffixe métrique par défaut est "s" (pour seconde).

bitrate-value
La valeur bitrate-value spécifie un nombre de bits par seconde. Il a la syntaxe suivante :

bitrate-value ::= Digit+; n'importe quel nombre positif

4.4.3 Les exigences d'intégration pour le module PrefetchControl

Un profil intégrant le module PrefetchControl doit ajouter les attributs nécessaires pour spécifier les médias à ramener. En général, ce sont les mêmes attributs de spécification de ressource que ceux des éléments médias eux-mêmes. De surcroît, le profil doit ajouter tous les attributs nécessaires pour contrôler la temporisation de l'élément prefetch.

4.4.4 La définition de type de document (DTD) pour le module PrefetchControl

Voir le DTD complet pour les modules de contrôle de contenu SMIL.

4.5 Le module SkipContentControl de SMIL 2.0

4.5.1 Aperçu du module SkipContentControl de SMIL 2.0

Ce module contient un seul attribut, l'attribut skip-content, qui peut être utilisé pour contrôler de façon sélective l'évaluation de l'élément dans lequel l'attribut apparaît. Cet attribut est introduit pour une future extension de SMIL. La fonctionnalité est inchangée par rapport à SMIL 1.0.

4.5.2 Les éléments et attributs

Définition de l'élément

Le module SkipContentControl ne contient aucune définition d'élément.

L'attribut skip-content

skip-content
valeur : true | false
Cet attribut contrôle si le contenu d'un élément doit être évalué ou sauté.
  • Si un nouvel élément est introduit dans une version future du langage, qui autoriserait des balises d'une version précédente du langage comme contenu d'élément, l'attribut skip-content contrôle si le contenu doit être traité par l'agent utilisateur ;
  • Si un élément vide dans une version du langage devient non vide dans une version de SMIL future, l'attribut skip-content contrôle si son contenu est ignoré par l'agent utilisateur, ou si cela aboutit à une erreur de syntaxe.
Si la valeur de l'attribut skip-content est true, et que l'un des cas ci-dessus s'applique, le contenu de l'élément est ignoré. Si la valeur est false, le contenu de l'élément est traité.
La valeur par défaut de skip-content est true.

4.5.3 Les exigences d'intégration pour le module SkipContentControl

Il est de la responsabilité du profil de langage de spécifier quels éléments ont des attributs skip-content pour l'activation de ce mécanisme d'évolution.

précédent   suivant   sommaire