Ce chapitre commence par définir le terme de scénario qui, dans le monde de l'informatique, se spécifie à travers un langage. Ensuite un état de l'art de ces langages est présenté en distinguant les langages impératifs des langages déclaratifs.
Scène 1 ext.city street - day 1 Downtown L.A. NOON on a hot summer day. On an EXTREME LONG LENS the (...). In SLOW MOTION they move (...) and like a dream it begins very slowly to DISSOLVE TO : Scène 2 ext. city ruins - night 2 Same spot as the last shot (...) ANGLE ON Scène 3 a heap (...) DISSOVE TO Scène 4 (...) WE TRACK SLOWLY (...) HOLD ON THIS IMAGE as a female VOICE speaks (...)
La description des scènes utilise un pseudo-code pour le mouvement des caméras (EXTREME LONG LENS, SLOW MOTION), et pour la transition (DISSOLVE TO, ANGLE ON). Pour une présentation multimédia les besoins expressifs sont similaires et nous employons aussi le terme de scénario. Plus précisement, nous identifions les besoins d'expression suivants :
La spécification de ce langage dépend du domaine d'application. Dans les systèmes de bases de données multimédia, ce langage se veut plus typé que celui des systèmes d'édition. En effet, un des objectifs des bases de données en général est de pouvoir accéder à un document ou à une classe de documents, tandis que l'objectif des systèmes d'édition est de créer une instance de document. Cela se traduit par un typage plus fort, sous forme de hiérarchie par exemple . Ainsi en base de données le positionnement des objets s'effectue grâce à des relations spatiales topologiques (disjoint, equal, etc.) alors que les systèmes d'édition nécessitent l'apport de relations spatiales directionnelles (à_gauche, au_dessus, etc.) et de distance. Notre travail se situe dans les systèmes d'édition multimédia.
En plus du domaine applicatif, le langage se définit par son
paradigme : impératif ou déclaratif. Un langage impératif
est un langage permettant de dire comment réaliser une opération,
alors qu'un langage déclaratif permet de dire quoi réaliser.
La frontière entre ces deux paradigmes dépend du vocabulaire
du domaine qui est parfois difficile à établir. Par exemple,
dans l'édition multimédia, nous avons vu qu'il était
nécessaire d'avoir un mécanisme de positionnement des objets.
Un langage permettant de dire que A est aligné à gauche
avec B est un langage déclaratif pour ce domaine par rapport
à un langage où pour obtenir cette propriété
il faut calculer explicitement la position de l'un par rapport à
l'autre :
A Aligné_A_Gauche B Déclaratif |
À chaque instant A.x = B.x Impératif |
DOM fournit un ensemble de classes constituant le noyau, ainsi que des
classes particulières au type de document HTML et XML. La liste
des principales classes du noyau avec un bref descriptif est donnée
dans la Fig 2 .
Un des avantages de DOM est qu'il permet à des documents intrinsèquement statiques de devenir dynamiques. Par exemple, le texte d'un lien peut changer de taille et de couleur lorsque la souris passe dessus, le contenu d'un article peut être étendu lorsque le lecteur le sélectionne, et le numéro de téléphone saisi peut être vérifié, etc.
On s'aperçoit aisément que cette solution pour rendre les documents dynamiques est difficile à maîtriser par des utilisateurs, notamment non informaticiens. Il est nécessaire d'apprendre les concepts du langage descriptif comme HTML, ainsi qu'un langage impératif implémentant l'APInote1 DOM. Un exemple d'utilisation de DOM est décrit dans la section suivante à travers un langage de script tels que VBScript ou JavaScript.
Les feuilles de style permettent de spécifier le rendu visuel d'un document, par exemple la taille des caractères, la fonte, la taille des marges, etc. Par conséquent, combinés à l'API DOM, les documents HTML deviennent véritablement dynamiques avec notamment l'introduction de la notion d'attributs spatio-temporels, c'est-à-dire des styles dépendants du temps. De plus, augmenté d'un modèle à événement , DOM apporte une véritable interactivité.
La Fig 3 montre un exemple de document DHTML «
drag&drop »(glisser-lacher) illustrant la modification dynamique
de l'attribut de style Position et la prise en compte des événements
provenant de la souris. Dans l'en-tête, délimité par
les marques <HEAD> et </HEAD>, est définie une feuille de
style (iegear) selon le modèle CSS (c.f. 3.1).
Ensuite, dans le corps du document HTML, le style est appliqué via
la marque <DIV> avec comme attribut le nom de la feuille de style. Dans
la partie script, délimitée par les marques <SCRIPT> et
</SCRIPT>, la position est modifiée grâce à la méthode
moveBy de l'objet iegear, lui-même accédé
via l'objet document. L'objet concerné par ces actions
est l'image de fond définie dans la feuille de style, ce qui fait
que le corps du document est vide.
<HTML>
<HEAD>
<STYLE TYPE="text/css">
<!-- Définition d'une feuille de style -->
<!-- #iegear { <!-- Identificateur -->
(...)
layer-background-image: url(http://www.ruleweb.com/
html/preview/ns_gear.jpg);
<!-- Spécifie une image comme fond de la feuille de
style -->
} -->
</STYLE> <!-- Fin feuille de style -->
</HEAD>
<BODY bgcolor="Black">
<!-- Document HTML -->
<DIV ID="iegear"> <!-- Applique le style iegear -->
<!-- Document vide car l'image est définie dans la
feuille de style -->
</DIV>
<!-- Fin du document HTML -->
<!-- Script -->
<SCRIPT LANGUAGE="JavaScript1.2">
<!--
currentX=currentY=0; <!-- Position courante de
l'image -->
<!-- grabGear : active l'événement MOUSEMOVE -->
function grabGear(gear) {
<!-- gear est un objet événement -->
currentX = gear.pageX; currentY = gear.pageY;
captureEvents(Event.MOUSEMOVE);
onmousemove = moveGear; <!-- fonction reflexe de
l'événement MOUSEMOVE -->
}
<!-- moveGear : déplace l'image -->
function moveGear(gear) {
distanceX = (gear.pageX - currentX);
distanceY = (gear.pageY - currentY);
currentX = gear.pageX; currentY = gear.pageY;
document.iegear.moveBy(distanceX,distanceY);
}
<!-- désactive l'événement MOUSEMOVE -->
function dropGear() {
releaseEvents(Event.MOUSEMOVE);
}
<!-- Initialisation -->
document.iegear.document.onmousedown = grabGear;
document.iegear.document.onmouseup = dropGear;
//-->
</SCRIPT>
</BODY>
</HTML>
En conclusion, DHTML est un langage hybride, mélangeant l'aspect déclaratif pour spécifier le placement spatial et l'aspect impératif pour réaliser des animations et d'éventuelles synchronisations. Un des avantages de cette approche est qu'elle permet d'augmenter en douceur et sans cassure l'expressivité d'un langage sur lequel sont basés plusieurs millions de documents. Par contre, peu de pages utilisent cette fonctionnalité d'une part parce qu'elle est relativement complexe, et d'autre part car DHTML est très récent et souffre d'un manque de standardisationnote2.
Un document Toolbook reprend la métaphore de livre. Il
se compose de une ou plusieurs pages représentant les écrans
de l'application. La visualisation des pages s'effectue dans des fenêtres
appelées visionneuses. Les pages contiennent des champs,
des boutons, et des graphismes. Multimédia Toolbook permet d'ajouter
des vidéos et des sons. Les pages et les composants qu'elles contiennent
représentent les objets de ToolBook. Un objet peut être
partagé par plusieurs pages en le plaçant sur un arrière-plan
commun à plusieurs pages (c.f. Fig 5 ).
Pour combler les lacunes du système d'édition, comme notamment
l'impossibilité d'animer les objets, Toolbook offre la possibilité
d'écrire des scripts. Ils permettent de modifier dynamiquement les
attributs des objets, d'interagir avec l'utilisateur, et de naviguer à
travers les pages du livre. Par exemple, le script de la Fig
6 montre comment l'objet self (objet contenant le script) peut
se déplacer vers la gauche grâce à la fonction move.
Lorsque l'objet atteint le bord inférieur, son déplacement
change de direction.
bord = (item 2 of size of this book) - 700 posOrig = item 2 of my bounds --Emplacement --courant de l'objet changePos = 100 --incrément de déplacement do move self by 0, changePos limNouv=my bounds if item 2 of limNouv > Bord then changePos = -100 end if until item 2 of limNouv <= posOrig
Avec ces scripts, Toolbook a un fort pouvoir d'expression. Grâce à son langage OpenScript, seule l'imagination de l'auteur limite la création d'une application multimédia ; à condition, bien évidemment, de maîtriser ce langage. De plus, la synchronisation temporelle est éparpillée à travers le code, rendant le comportement de la présentation difficile à cerner.
Le système d'édition temporelle s'inspire de Director
, c'est-à-dire qu'il repose sur une vue time-line. Pour chaque objet,
il est possible de définir des « keyframes » (images
clés), et d'associer entre deux « keyframes » d'un même
objet un effet de style : déplacement d'un objet, changement de
couleur, ou changement de forme (morphing). Sur la figure Fig
7 sont représentés deux objets animés par un déplacement.
Chaque ligne de la vue time-line correspond à un objet. L'effet
de style est représenté par un arc, entre deux « keyframes
», étiquetté par le nom de l'effet (position,
rotate, shape, etc.)
Le fait de masquer complètement le langage facilite grandement la création d'animations et par conséquent rend ce logiciel accessible à des non-informaticiens. Par contre, le champ d'expression est limité aux seules commandes fournies par une interface utilisateur. Il n'est pas possible, par exemple, de maintenir une relation spatiale pendant un intervalle de temps donné.
Une autre approche consiste en la spécification d'un langage déclaratif qu'il est possible d'encapsuler plus aisement par une interface utilisateur. Ces langages sont présentés dans la section suivante.
CSS (Cascading Style Sheet : CSS ) est un langage de feuilles de style permettant aux auteurs et aux lecteurs d'associer des styles à des documents structurés tels que HTML ou XML. Un style permet de contrôler la présentation d'un document sur l'écran, sur l'imprimante ou comment les objets sonores qu'il contient sont prononcés. Par exemple, la police de caractères, la visibilité et la couleur sont des styles de présentation.
Une feuille de style en CSS est composée d'une ou plusieurs règles, constituées d'un sélecteur et d'une déclaration. Le sélecteur détermine quelles règles sont appliquées aux éléments de l'arbre. La déclaration spécifie l'effet de style à appliquer au sélecteur. Par exemple, la règle
EM { color : blue; fontsize : 16 }
associe à l'élément EM la couleur bleue et une taille de caractères de seize.
La valeur des styles est héritée par les descendants d'un noeud dans l'arbre du document. Par exemple, dans la spécification suivante :
<H1>L'en-tête <EM>est</EM> important!</H1>si la couleur de l'élément EM n'a pas été spécifiée, alors le texte « est » hérite de la couleur de l'élément père H1. Cette spécification est illustrée par la Fig 8 .
L'en-tête est important!
Ce langage fait office de référence pour contrôler la présentation d'un document indépendamment de la structure. Son fort pouvoir d'expression est accompagné d'une très bonne lisibilité et d'une facilité d'apprentissage pour l'auteur. Par contre, pour le moment, seuls les documents statiques peuvent être complétés par une spécification CSS.
XSL (eXtensible Style Langage : XSL ) est un langage de feuilles de style dont l'objectif est de fournir des mécanismes permettant de créer des feuilles de style respectant la syntaxe XML, et basé sur DSSSL (Document Style Semantics and Specification Language ).
XSL en est à ses premiers balbutiements et semble potentiellement intéressant pour spécifier des feuilles de style dans des documents structurés.
Dans les relations à base d'intervalles, les relations possibles entre deux objets multimédia se réduisent à toutes les combinaisons de positionnement possibles de deux intervalles sur une droite orientée. Le modèle le plus général, proposé par J.F Allen , dresse la liste exhaustive de toutes ces relations (c.f annexe A).
Dans la suite de cette étude, nous verront comment ces deux approches ont été utilisées.
<smil>
<head> // En-tête du document
<layout type="text/smil-basic">
<region id="titre" width="90%" high="5%" />
<region id="ecrivain" left="10" top="10" width="200" high="200" />
</layout>
</head>
<body> // Début de la spécification temporelle
<par>
<audio src="chezmoi/bonjour.wav" />
<seq>
<text src="text_titre.txt" region="titre" dur="10s">
<par>
<video id="v" src="ecrivain.mpg" region="ecrivain" />
<audio src="ecrivain.au" begin="id(v)(5)"/> /* Synchro fine qui
précise que le début de l'audio doit débuter 5 unités de
temps après le début de la vidéo v */
</par>
</seq>
</par>
</body>
Du fait que SMIL soit un langage déclaratif, il est très facile d'écrire des scénarios multimédia nécessitant de la synchronisation. Néanmoins, la possibilité de choisir entre deux types de synchronisation (arbre d'opérateurs ou événements) est déroutante.
De plus, à l'heure actuelle, SMIL ne permet pas de définir des mises en page dynamique. Pour combler cette lacune, propose de considérer la mise en page comme un média. Par conséquent, la mise en page peut changer au cours du temps en la synchronisant avec les autres objets du document. Cette méthode est adaptée à une mise en page à gros grain mais pas à grain fin comme le nécessite les animations.
La composition spatiale repose sur trois classes de relations (c.f. Fig 10 et ) :
Par conséquent, une composition spatio-temporelle est un ensemble de couples ST_R(sp_rel, temp_rel), avec sp_rel une relation spatiale et temp_rel une relation temporelle. Un couple ST_R définit un positionnement spatial et, indépendemment, une composition temporelle entre deux objets.
Les événements simples sont générés par des actions atomiques. Par exemple, la souris, le clavier, le changement d'état d'un objet, l'horloge, le début de l'application et le début d'une composition spatio-temporelle sont des événements simples.
Les événements complexes sont une composition des événements simples à travers un ensemble d'opérateurs et de fonctions. En voici quelques exemples :
« ; » : conjonction d'événements
SEQ(e1;...;en-1;en) : définit un événement qui est levé lorsque en est levé et si e1..en-1ont été levés dans l'ordre de définition.
Pour finir, ce modèle ne permet pas de spécifier des animations sur les objets (déplacement, changement de couleur, etc.) et, de plus, les relations spatiales sont fixes. Les dimensions temporelles et spatiales sont considérées comme indépendantes : la composition spatiale s'effectue sans se préoccuper de la composition temporelle et réciproquement.
Les événements sont représentés par des noeuds et leurs relations temporelles par des arcs. Les événements temporelles sont déclenchés par le début ou la fin de la présentation d'un objet, tandis que les événements spatiaux sont, par exemple, déclenchés par le début et la fin d'un déplacement. Les événements spatiaux sont caractérisés par les fonctions suivantes :
Dans la Fig 11 , les objets vidéoA
et le sonA commencent leur présentation en même temps.
La fin de sonA déclenche le début de l'événement
spatial spécifié par RelativePath(). Lorsque l'objet
vidéoA a terminé sont mouvement et après un
temps d2, il déclenche la présentation de l'objet
sonB.
Ce modèle de spécification est suffisamment puissant pour permettre de créer des animations grâce aux fonctions attachées aux noeuds spatiaux. De plus, il est possible de synchroniser les événements spatiaux. Enfin, l'ensemble de la spécification temporelle et spatiale est uniformisé sous la seule notion d'événements.
Néanmoins, ce modèle permet d'introduire des incohérences. De plus, l'environnement d'édition proposé souffre d'un problème de facteur d'échelle : plus le scénario devient complexe et moins la spécification devient lisible, et plus, la représentation ne reflète pas la dimension temporelle. En effet, les événements spatiaux peuvent avoir des durées différentes mais sont toujours représentés par un cercle de taille fixe. Enfin, les événements spatiaux ne sont que de simples raccourcis des événements temporels. En effet, chaque fonction prend en paramètre la variable time. Chaque noeud spatial peut donc être remplacé par deux noeuds temporels entre lesquels un fonction spatiale est appliquée. Par conséquent, les événements spatiaux n'apportent rien de nouveau au niveau de la synchronisation.
Les objets multimédia de base sont des entités élémentaires du modèle, et sont considérés comme des intervalles de temps. La composition de ces objets par le biais des opérateurs constitue un objet composite qui est aussi un intervalle.
Les opérateurs sont classés en opérateurs temporels, et non temporels. Les opérateurs temporels exprime les relations d'Allen en explicitant les liens causaux entre les intervalles. Contrairement aux modèles vus dans les sections précédentes, toutes les possibilités de liens causaux sont exploitées. Voici un ensemble non exhaustif de ces opérateurs :
Par contre, la construction d'un arbre d'opérateurs n'est pas facile, et se prête difficilement à l'incrémentalité du scénario. De plus, le choix d'implémenter la construction de l'arbre comme une API rend Menkalinan difficile d'accès pour des non-informaticiens et le scénario temporel est illisible.
Nous souhaitons construire un document multimédia Inria-Opéra qui présente les activités de recherche du projet Opéra. Le document comporte une introduction composée d'un élément texte Titre-Présentation, d'un élément sonore Musique et de deux scènes Intro-Inria et Activité-Opéra. La scène Intro-Inria contient une vidéo (Vidéo1) qui présente le projet au sein de l'unité de recherche Inria Rhône-Alpes et un commentaire sonore (Audio1). La scène Activité-Opéra est composée de deux sous-scènes : Protos-de-Recherche qui contient trois éléments textuels (Thot, Alliance et Madeus) et Présentation-Opéra qui contient un élément audio (Audio2) ainsi qu'une vidéo (Vidéo2). Les trois textes précédents contiennent des liens externes vers d'autres documents. Trois éléments d'interaction, contenus dans l'introduction, permettent de naviguer dans le document : Bouton1 permet de revenir au début du document, Bouton2 permet d'interrompre la scène Intro-Inria et Bouton3 permet d'accéder directement à la partie Présentation-Opéra.
Dans l'exemple Inria-Opéra les trois éléments Thot, Alliance et Madeus sont des liens vers des documents externes désignés par leur URL.
La spécification du placement spatial dans Madeus s'effectue
par l'intermédiaire de l'attribut de positionnement <POS>
(Fig 14 ) qui définit la position spatiale
absolue d'un élément de base. Les valeurs de cet attribut
correspondent aux coordonnées en pixels du coin supérieur
gauche de l'élément de base. Si cet attribut n'est pas spécifié,
alors l'objet est positionné par défaut avec les coordonnées
(0, 0).
<OBJECT> <NAME> Vidéo1 <PCDATA> inria_opera.mpeg1 <POS> 78 24 <DUR> 1.00 3.00 <EOBJECT>
Le placement spatial peut s'effectuer aussi par des relations spatiales
(c.f annexe A) pour spécifier le placement relatif entre les objets.
Elles sont délimitées par les balises <SPREL> et
<ESPREL> et sont de la forme ObjetDeRéférence
Relation ObjetSecondaire.
<SPREL> Bouton1 Alignement_à_Gauche Vidéo1 Bouton1 Alignement_Inférieur Video1 Image2 Centrage_Vertical Text2 Image1 Décalage_Supérieur(10) Text1 <ESPREL>
Le scénario temporel souhaité dans l'exemple Inria-Opéra
est schématisé Fig 16 . Ainsi, l'introduction
d'Opéra est orchestrée comme suit. Le document consiste en
la présentation du Titre en même temps que de la Musique.
Cinq secondes après le début de la Musique, la scène
Intro-Inria commence. Celle-ci présente en même temps
la vidéo Vidéo1 et l'audio Audio1, et peut
être interrompue à tout moment par le bouton Bouton2.
La terminaison de Intro-Inria rend ce bouton inactif.
L'approche choisie pour la description du scénario temporel dans Madeus est une approche déclarative basée sur les contraintes d'intervalles d'Allen. L'idée sous-jacente à cette approche est que l'auteur spécifie ce qu'il souhaite obtenir comme placement temporel (A avant B, etc.) sans avoir à spécifier toutes les informations temporelles attachées aux éléments, comme leurs instants de début et de fin ou leur durée. Le scénario temporel d'un document est donc défini par un ensemble de relations entre les éléments d'un même élément composite.
En plus de ces relations, Madeus utilise deux opérateurs supplémentaires, parmin et parmaster, pour spécifier des relations de causalité entre les intervalles (c.f. et annexe A). Dans ces relations, deux intervalles commencent en même temps, A parmin B spécifie que le plus court interrompt le plus long, A parmaster B spécifie que la fin de A, désigné comme le maître de la relation, provoque la fin de B si et seulement si B n'est pas encore terminé.
Le chapitre suivant tente de clarifier le vocabulaire et propose un modèle pour ensuite spécifier l'expression spatio-temporelle des documents multimédia.
Application Programming Interface
(2)
A l'heure actuelle, la spécification de DHTML diffère
légèrement en fonction des butineurs du marché qui
ralentit son expansion
(3)
http://www.asymetrix.com