2. Les modules de SMIL 2.0

Rédacteurs:

Warner ten Kate (warner.ten.kate@philips.com), (Philips Electronics)

Aaron Cohen (aaron.m.cohen@intel.com), (Intel)

Philipp Hoschka (ph@w3.org), (W3C)

2.1 Introduction

Cette section est informative.

Depuis la publication de SMIL 1.0 [SMIL10], l'intérêt pour l'intégration des concepts SMIL dans HTML, le Langage de Balise HyperTexte [HTML4], et les autres langages XML a augmenté. De plus, le Groupe de Travail HTML au W3C a spécifié XHTML, le Langage de Balise HyperTexte Extensible [XHTML10], en vue d'en créer un sous-ensemble, de l'étendre, et de l'intégrer dans d'autres langages. La stratégie prise en compte pour intégrer des fonctionnalités respectives avec d'autres langages basés sur XML est fondée sur les concepts de modularisation et de profilage [SMIL-MOD], [XMOD].

La modularisation est une approche selon laquelle une fonctionnalité de balisage est spécifiée comme un ensemble de modules qui contiennent des éléments, des attributs et des valeurs d'attributs sémantiquement liés à XML. Le profilage est la création d'un langage basé sur XML par la combinaison de ces modules, dans le but de fournir la fonctionnalité requise par une application particulière.

Le profilage introduit la capacité de façonner un langage basé sur XML pour des besoins spécifiques, i.e. optimiser la présentation et l'interaction selon les capacités du client. Le profilage ajoute aussi la capacité d'intégrer des fonctionnalités à partir d'autres langages balisés, libérant ainsi l'auteur du langage de la spécification de ces fonctionnalités. De surcroît, cela renforce la cohérence du balisage grâce à l'utilisation d'un même modèle pour intégrer une fonction. Des constructions identiques facilitent la conception, avec,du côté de l'agent utilisateur, un potentiel de ré-utilisation du code. Par exemple, une application de planification gérant les fonctionnalités de temporisation et de synchronisation SMIL pourrait être utilisée avec des documents SMIL, des documents XHTML + SMIL et des documents SVG.

La modularisation permet aux concepteurs de langage de spécifier un balisage dédié destiné à une intégration dans d'autres profils de langage existants. Des exemples de spécifications destinées à une telle intégration sont MathML et XForms [MathML], [XFORMS].

La modularisation et le profilage utilisent les propriétés d'extensibilité de XML, ainsi que des technologies apparentées comme les espaces de nommage XML et les schémas XML [XML10], [XML-NS], [XSCHEMA].

Cette partie de la spécification de SMIL 2.0 décrit la charpente sur laquelle la modularisation et le profilage XML reposent, spécifie les modules de SMIL 2.0, leurs identifiants, ainsi que les exigences pour la conformité au sein de cette charpente.

2.1.1 La modularisation et le profilage

Cette section est informative.

L'approche de la modularisation utilisée dans cette spécification dérive de celle utilisée dans la modularisation de XHTML [XMOD]. La charpente sur laquelle la modularisation et le profilage SMIL reposent est décrite ici simplement.

Un module est une collection d'éléments, d'attributs et de valeurs d'attribut sémantiquement liés à XML, qui représente une unité de fonctionnalité. Les modules sont définis dans des ensembles cohérents. Cette cohérence est exprimée dans le fait que les éléments de ces modules sont associés au même espace de nommage.

Un profil de langage est une combinaison de ces modules. Les modules sont atomiques, i.e. ils ne peuvent être divisés en sous-ensembles quand ils sont inclus dans un profil de langage. En outre, une spécification de module peut inclure un ensemble conditions préalables d'intégration, auxquelles les profils de langage contenant le module doivent satisfaire.

Généralement, il y a un profil de langage principal qui inclut pratiquement tous les modules associés à un même espace de nommage. Par exemple, le profil de langage SMIL 2.0 utilise la plupart des modules SMIL 2.0. D'habitude, le même nom est utilisé pour référencer approximativement les deux - "SMIL 2.0" dans l'exemple. Aussi, le nom « profil » est utilisé pour signifier « profil de langage ».

D'autres profils de langage peuvent être spécifiés comme sous-ensemble du plus important, ou comme incorporant un mélange de modules associés à différents espaces de nommage. SMIL 2.0 Basic est un exemple du premier, XHTML+SMIL du dernier.

Un module spécial dans le profil de langage est celui appelé module Structure, dans lequel est contenu l'élément racine du profil de langage, i.e. <smil> ou <html>. N'importe lequel des profils de langage qui inclut des modules associés avec un seul espace de nommage inclura le module Structure associé à cet espace de nommage.

Les autres modules qui requièrent une attention particulière sont ceux qui caractérisent le noyau des fonctionnalités de l'espace de nommage. Ceci s'exprime par les notions de langage hôte et d'ensemble d'intégration. Les deux se rapportent à un ensemble d'exigences de conformité pour les profils de langage, parmi celles-ci l'obligation d'incorporer au moins le jeu des modules de base. Cet ensemble de conditions peut être différent entre un langage hôte et un ensemble d'intégration. Un langage hôte doit incorporer le module Structure ; un ensemble d'intégration peut ne pas l'inclure. Il peut également exister d'autres différences.

Le but principal de la conformité du profil de langage est d'améliorer l'interopérabilité. De préférence, les modules obligatoires pour la conformité avec le langage hôte sont définis de sorte que n'importe quel document interchangé dans un profil de langage conforme va produire une présentation raisonnable si le moteur de rendu, tout en gérant le jeu des modules obligatoires associés, devait ignorer tous les autres éléments et attributs (inconnus). Ici, l'expression « présentation raisonnable » est à comprendre comme quelque chose d'intelligible, ce qui n'est pas nécessairement un reflet proche des intentions originelles de l'auteur. Pour obtenir ce dernier résultat, une négociation devrait être conduite pour s'entendre sur les profils de langage spécifiques qui devront être utilisés pour les communications entre les documents.

2.2 Les modules SMIL 2.0

Cette section est normative.

La fonctionnalité de SMIL se partage entre 10 domaines fonctionnels. Dans chacun de ces domaines de fonctionnalité, un autre partitionnement est appliqué en modules. Chacun de ces modules, et seulement ces modules, sont associés à l'espace de nommage SMIL.

Les domaines fonctionnels et leurs modules correspondants sont :

1. Temporisation
   1. AccessKeyTiming
   2. BasicInlineTiming
   3. BasicTimeContainers
   4. EventTiming
   5. ExclTimeContainers
   6. FillDefault
   7. MediaMarkerTiming
   8. MinMaxTiming
   9. MultiArcTiming
   10. RepeatTiming
   11. RepeatValueTiming
   12. RestartDefault
   13. RestartTiming
   14. SyncbaseTiming
   15. SyncBehavior
   16. SyncBehaviorDefault
   17. SyncMaster
   18. TimeContainerAttributes
   19. WallclockTiming
2. Manipulation du temps
   1. TimeManipulations
3. Animation
   1. BasicAnimation
   2. SplineAnimation
4. Contrôle du contenu
   1. BasicContentControl
   2. CustomTestAttributes
   3. PrefetchControl
   4. SkipContentControl
5. Disposition
   1. AudioLayout
   2. BasicLayout
   3. HierarchicalLayout
   4. MultiWindowLayout
6. Liens
   1. BasicLinking
   2. LinkingAttributes
   3. ObjectLinking
7. Objets médias
   1. BasicMedia
   2. BrushMedia
   3. MediaAccessibility
   4. MediaClipping
   5. MediaClipMarkers
   6. MediaDescription
   7. MediaParam
8. Méta-information
   1. Metainformation
9. Structure
   1. Structure
10. Transitions
    1. BasicTransistions errata-E20
    2. InlineTransitions
    3. TransitionModifiers

Cette section est informative.

Chacun de ces modules introduit un ensemble d'éléments, de propriétés et d'attributs reliés sémantiquement. Chaque domaine fonctionnel a une section correspondante dans le document de spécification. D'autres détails sur chacun de ces modules sont spécifiés dans ces sections.

Les modules peuvent être indépendants ou complémentaires. Par exemple, le module SyncMaster requiert et se construit sur le module SyncBehavior, mais les modules PrefetchControl et SkipContentControl sont indépendants l'un de l'autre. En plus, certains modules requièrent des modules d'autres domaines fonctionnels.

Les modules spécifient leurs exigences d'intégration. Quand un module requiert un autre module pour certaines fonctionnalités de base comme condition préalable, le profil de langage doit inclure le second module pour pouvoir inclure le premier. Le premier module est défini comme dépendant du second module. Les dépendances peuvent être imbriquées, en cela qu'un module peut être dépendant d'un autre qui est lui-même dépendant.

Le tableau 1 présente les modules SMIL 2.0 ainsi que les modules dont ils dépendent.

2.2.1 Le DOM de SMIL

Cette section est informative.

SMIL est un langage basé sur XML et il est conforme au Noyau du DOM (XML) [DOM1], [DOM2]. Dans le futur, une recommandation DOM spécifique à SMIL pourra spécifier une gestion de la temporisation et la synchronisation, de l'intégration de médias et d'autres fonctionnalités multimédias synchronisées.

Un profil de langage peut comprendre une gestion du DOM. La granularité de DOM qui est gérée correspond aux modules actuellement gérés dans ce profil de langage. Comme pour tous les autres modules, la gestion qui est requise pour le DOM est une option du profil de langage.

2.3 Les identifiants pour les modules et les profils de langage de SMIL 2.0

Cette section est informative.

Cette section spécifie les identifiants pour l'espace de nommage de SMIL 2.0 et les modules SMIL 2.0. Chaque profil de langage conforme au langage hôte SMIL est tenu de déclarer explicitement l'URI de l'espace de nommage qui doit être utilisé pour l'identifier. Cet URI d'espace de nommage doit se conformer aux " exigences pour les identifiants des profils de langage conformes au langage hôte SMIL 2.0", définies ci-dessous.

2.3.1 Le type MIME de SMIL

Cette section est normative.

Les documents conçus dans des profils de langage qui incluent le module Structure de SMIL peuvent être associés avec le type MIME "application/smil". Les documents utilisant le type MIME "application/smil" sont tenus d'être conformes au langage hôte.

2.3.2 L'identifiant d'espace de nommage XML pour les modules SMIL 2.0

Cette section est normative.

L'identifiant d'espace de nommage XML pour le jeu complet des modules SMIL 2.0, et des éléments et attributs qui y sont contenus, est :

http://www.w3.org/2001/SMIL20/

2.3.3 Les identifiants pour les modules et les fonctionnalités de SMIL 2.0

Cette section est normative.

Chaque module dans cette spécification se voit associer un identifiant unique. Ceux-ci sont destinés à identifier chacun des modules de façon unique et cohérente. Ils devraient être utilisés comme valeurs dans un test pour vérifier si une implémentation inclut, ou non, un module spécifique, ou dans d'autres circonstances où il est nécessaire de faire référence à un module SMIL spécifique.

Le tableau 2 résume les identifiants pour les modules SMIL 2.0.

En plus des identifiants de modules ci-dessus, il peut y avoir des fonctionnalités différentes et des variantes d'un profil de langage à l'autre qui ne s'expriment pas en termes de gestion ou non gestion d'un module particulier. Ces fonctionnalités peuvent être exprimées en utilisant les identifiants suivants :

http://www.w3.org/2001/SMIL20/NestedTimeContainers

Ce profil permet une imbrication des conteneurs de temps par et seq.

http://www.w3.org/2001/SMIL20/DeprecatedFeatures

Ce profil gère les fonctionnalités dépréciées de SMIL 1.0.

Les implémentations qui gèrent le module BasicContentControl de SMIL doivent les admettre comme identifiants à utiliser avec le mécanisme d'espace de nommage XML et doivent permettre l'utilisation de l'identifiant d'espace de nommage associé avec l'attribut de test systemRequired. Les profils doivent identifier les attributs pour lesquels une implémentation doit retourner la valeur "true" (ceci est une condition préalable d'intégration). Les implémentations doivent retourner la valeur "false" pour les modules ou les fonctionnalités qui ne sont pas entièrement gérées.

Les modules peuvent aussi être identifiés collectivement. On définit les quatre collections de modules suivantes :

http://www.w3.org/2001/SMIL20/

Tous les modules spécifiés par la spécification SMIL 2.0.

http://www.w3.org/2001/SMIL20/Language

Les modules utilisés par le profil du langage SMIL 2.0.

http://www.w3.org/2001/SMIL20/HostLanguage

Les modules requis pour la conformité avec le langage hôte SMIL.

http://www.w3.org/2001/SMIL20/IntegrationSet

Les modules requis pour la conformité avec l'ensemble d'intégration SMIL.

2.4 La conformité avec SMIL

Cette section est informative.

Dans cette section nous spécifierons les règles de conformité pour le langage hôte SMIL et pour l'ensemble d'intégration SMIL. Les exigences pour la conformité avec le langage hôte et la conformité avec l'ensemble d'intégration sont tout d'abord données. Les exigences sont similaires à celles de la conformité du type de document pour le langage hôte XHTML et de la conformité du type de document pour l'ensemble d'intégration XHTML [XMOD]. Dans la section finale, on donne les exigences pour les identifiants des profils de langage conformes au langage hôte.

Pour l'instant, il existe trois profils de langage utilisant les modules SMIL 2.0. Ce sont le profil de langage SMIL 2.0, le profil de langage SMIL 2.0 Basic et le profil de langage XHTML+SMIL 2.0 [XHTML+SMIL]. Les deux premiers sont conformes au langage hôte SMIL, le troisième est conforme à l'ensemble d'intégration SMIL.

Cette section est normative.

Les deux tableaux suivants listent les noms utilisés pour faire référence commune à certains ensembles des éléments et attributs de SMIL 2.0. Ils sont utilisés dans les définitions des gestions minimales dans les deux sections ci-dessous sur la conformité avec le langage hôte SMIL et sur la conformité avec l'ensemble d'intégration SMIL. Le terme « gestion minimale » est utilisé pour faire référence à l'ensemble minimum d'éléments qu'un élément peut contenir, et à l'ensemble minimum d'attributs qui peut être utilisé sur un élément.

2.4.1 La conformité avec le langage hôte SMIL

Cette section est normative.

Un profil de langage est dit être conforme au langage hôte SMIL 2.0 s'il inclut les modules suivants :

1. Structure
2. BasicContentControl
3. BasicInlineTiming
4. BasicLayout
5. BasicLinking
6. BasicMedia
7. BasicTimeContainers
8. MinMaxTiming
9. RepeatTiming
10. SkipContentControl
11. SyncbaseTiming

De plus, les exigences suivantes doivent être satisfaites :

1. Le profil de langage définit les modules qu'il collecte ;
2. Le profil de langage inclut tous les éléments, attributs et valeurs d'attributs spécifiés par les modules collectés ;
3. Le profil de langage satisfait les exigences de « gestion minimale » pour les éléments et les attributs, tels qu'ils sont répertoriés dans le Tableau 5 ci-dessous ;
4. Le profil de langage se conforme aux conditions préalables d'intégration présentés par les modules qu'il collecte ;
5. Le profil de langage spécifie la sémantique liée à l'intégration des modules ;
6. Le profil de langage définit ses DTD ou ses schémas XML ;
7. Le profil de langage définit un identifiant unique obéissant aux conditions présentées dans les exigences pour les identifiants des profils de langage conformes au langage hôte SMIL ;
8. Le module SyncbaseTiming doit être inclus dans les profils conformes au langage hôte, bien que ce ne soit pas strictement requis. Nous recommandons fortement l'inclusion de ce module dans les profils conformes au langage hôte pour maintenir un niveau élevé de cohérence et d'interopérabilité avec les autres langages qui intègrent des modules SMIL, y compris le langage SMIL 2.0, XHTML+SMIL et SVG. Seuls les profils conçus pour opérer sur des appareils fortement contraints peuvent omettre le module SyncbaseTiming.

La gestion des éléments et attributs dépréciés est exigée pour la conformité avec le langage hôte SMIL 2.0, pour tous les modules que le langage en question gère. Par exemple, si un langage hôte SMIL 2.0 gère le module MultiArcTiming, il doit gérer la syntaxe dépréciée définie dans le module MultiArcTiming.

Puisque le module Structure SMIL 2.0 peut seulement être utilisé dans un profil conforme au langage hôte SMIL, ceci implique que le module Structure SMIL 2.0 doit au moins être accompagné des neufs autres modules ( cités ci-dessus) requis pour la conformité du langage. Ces modules eux-mêmes peuvent toujours être utilisés dans d'autres profils de langage, non conformes au langage hôteSMIL.

2.4.2 La conformité avec l'ensemble d'intégration SMIL

Cette section est normative.

Un profil de langage est dit conforme à l'ensemble d'intégration SMIL 2.0 s'il inclut les modules suivants :

1. BasicContentControl
2. BasicInlineTiming
3. BasicMedia
4. BasicTimeContainers
5. MinMaxTiming
6. RepeatTiming
7. SyncbaseTiming

De plus, les exigences suivantes doivent être satisfaites :

1. Le profil de langage définit quels sont les modules qu'il collecte ;
2. Le profil de langage inclut tous les éléments, attributs et valeurs d'attributs spécifiés par les modules collectés ;
3. Le profil de langage satisfait aux exigences de « gestion minimale » pour les éléments et les attributs, tels qu'ils sont répertoriés dans le Tableau 6 ci-dessous ;
4. Le profil de langage se conforme aux conditions préalables d'intégration avancées par les modules qu'il rassemble ;
5. Le module SyncbaseTiming doit être compris dans les profils conformes au langage hôte, bien que ce ne soit pas strictement requis. Nous recommandons fortement l'inclusion de ce module dans les profils conformes au langage hôte pour maintenir un niveau élevé de cohérence et d'interopérabilité avec les autres langages qui intègrent des modules SMIL, y compris le langage SMIL 2.0, XHTML+SMIL [XHTML+SMIL] et SVG [SVG]. Seuls les profils conçus pour opérer sur des appareils fortement contraints peuvent omettre le module SyncbaseTiming.

La gestion des éléments et attributs dépréciés n'est pas requise pour la conformité avec l'ensemble d'intégration SMIL 2.0. Cependant, quand ils sont inclus, les exigences ci-dessus s'appliquent également à leurs attributs et à leurs éléments. Aussi, quand ils sont gérés, il est nécessaire que tous les éléments et attributs dépréciés de tous les modules inclus soient gérés dans leur totalité.

2.4.3 Les exigences pour les identifiants des profils de langage conformes au langage hôte SMIL

Cette section est informative.

Un profil de langage est spécifié au travers de sa DTD ou de son schéma XML. Leurs identifiants peuvent être utilisés pour identifier le profil de langage. SMIL 1.0 spécifiait la déclaration de l'espace de nommage par défaut dans son élément racine, smil, comme identifiant décisif pour distinguer celui-ci des autres profils de langage [SMIL10]. Pour cela, SMIL 1.0 spécifiait

http://www.w3.org/TR/REC-smil

comme identifiant de l'espace de nommage pour SMIL 1.0.

Cette section est normative.

Dans le but d'identifier la version ainsi que le profil de langage utilisés, les documents conformes au langage hôte SMIL doivent satisfaire aux exigences suivantes :

1. Le document doit déclarer un espace de nommage par défaut [XML-NS] ;
2. L'espace de nommage par défaut doit être déclaré dans l'élément racine smil ;
3. Dans le cas où le profil de langage conforme au langage hôte SMIL a été publié comme une recommandation du W3C, l'identifiant de l'espace de nommage par défaut doit satisfaire aux conditions suivantes :
   1. L'URI est construit conformément aux conditions avancées par le document [W3C-NSURI] du W3C ;
   2. L'identifiant de l'espace de nommage par défaut doit identifier le profil de langage.
      Dans le cas où le profil de langage est un sous-ensemble d'un profil plus grand, l'identifiant de l'espace de nommage par défaut peut aussi identifier le profil de langage plus grand. La collection de modules dont la gestion est obligatoire dans le profil de langage du sous-ensemble peut être indiquée grâce à l'attribut systemRequired de l'élément smil.
      Voir la spécification du profil de langage SMIL Basic pour avoir un exemple.

2.4.4 La gestion des erreurs dans les documents conformes au langage hôte SMIL

Cette section est normative.

Les erreurs de syntaxe dans un document conforme au langage hôte SMIL sont gérées selon les règles XML établies pour un document XML valide ou bien formé [XML10].

Des erreurs sémantiques peuvent apparaître à différents niveaux. L'une survient quand les valeurs d'attributs déclarées ont des valeurs inconnues. Une autre survient si la présentation mise en oeuvre est (éventuellement) en conflit, comme dans le cas où des objets médias se disputent l'espace d'affichage ou quand ils sont synchronisés de façon ambiguë. Ces derniers cas, à moins que l'erreur ne soit intentionnelle de la part de l'auteur, ne sont pas considérés comme des erreurs et l'agent utilisateur va produire une présentation selon les règles de définition définies dans cette spécification.

2.4.5 La gestion des erreurs de syntaxe dans les valeurs d'attribut

Cette section est normative.

Les erreurs dans les valeurs d'attributs peuvent rester indétectables par l'analyseur, parce que le type de la valeur est déclaré comme valeur CDATA, ou parce que la portée de la valeur est sans limites fixes, comme dans le cas des événements par exemple. Cependant, les erreurs dans les valeurs d'attribut peuvent être détectées à l'intérieur d'un profil de langage donné, où le profil de langage définit l'ensemble des valeurs reconnues. Les spécifications des profils de langage sont tenues de spécifier la gestion d'erreur applicable quand une telle erreur de valeur se produit.

2.5 La création d'un DTD pour un profil de langage

Cette section est informative.

Cette section décrit comment les profils de langage peuvent être définis avec les DTD modulaires de SMIL 2.0. Le lecteur est supposé être familier avec les mécanismes définis dans « La modularisation XHTML » [XMOD], en particulier l'Annexe D [XMOD-APPD] et l'Annexe E [XMOD-APPE]. En général, les DTD modulaires de SMIL utilisent le même mécanisme qu'utilisent les DTD modulaires de XHTML. Les exceptions à cela sont :

1. SMIL gère les noms d'attributs qualifiés pour les attributs SMIL qui peuvent apparaître dans des éléments non-SMIL. Cela permet à ces attributs d'utiliser des préfixes pour indiquer qu'ils appartiennent à l'espace de nommage SMIL 2.0 ;
2. SMIL gère les INCLUDE/IGNORE au niveau du module plutôt qu'au niveau ELEMENT/ATTLIST de XHTML. Similairement à la Modularisation XHTML, cela interdit aux profils d'importer seulement une partie d'un module - ils doivent gérer soit tous les éléments et attributs, soit aucun.

Ci-dessous, nous donnons une courte description des fichiers qui sont utilisés pour définir les DTD modulaires de SMIL 2.0. Voir le tableau et la fin de la section pour avoir une liste complète des fichiers impliqués.

Suivant les mêmes mécanismes que les DTD modulaires de XHTML, la spécification de SMIL 2.0 place les déclarations des éléments XML (i.e., <!ELEMENT...>) et les déclarations des listes d'attributs (i.e., <!ATTLIST...>) de tous les éléments de SMIL 2.0 dans des fichiers séparés, les fichiers de module SMIL. Un fichier de module SMIL est fourni pour tous les domaines fonctionnels de la spécification de SMIL 2.0 (on a donc un fichier de module SMIL pour l'animation, la la disposition, la temporisation, etc.).

Les fichiers de module SMIL sont utilisés dans les définitions normatives des spécifications des profils de langage de SMIL 2.0. Le traitement des mêmes fichiers de module pour définir d'autres profils SMIL est recommandé, mais pas obligatoire. Les conditions préalables que les profils de langage SMIL doivent suivre sont exposés dans la spécification de SMIL 2.0, mais pas dans le code des DTD.

Pour faire en sorte que les fichiers de modules de SMIL soient indépendants les uns des autres, et indépendants des profils de langage, les déclarations d'attributs et d'éléments font une utilisation massive des entités XML. Cela donne des profils avec les crochets nécessaires pour définir les modèles de contenu réels et les attributs des éléments SMIL.

Le profil de langage SMIL 2.0 donne des exemples qui définissent comment les fichiers de modules SMIL peuvent être utilisés. La plupart des fichiers de DTD sont réutilisés au travers des différents profils. Ce qui est réutilisé, ce sont les fichiers de module SMIL, les fichiers qui définissent le type des données et les attributs communs, le fichier "qname" qui prend soin d'ajouter des préfixes d'espaces de nommage, si nécessaire, et le fichier cadre, qui prend soin d'ajouter les fichiers dans l'ordre approprié.

Les fichiers qui sont différents pour chacun des profils sont les fichiers de gestion, et les fichiers de modèle de document. Cela s'applique aussi, en général, aux nouveaux profils : pour définir un nouveau profil de langage, on doit écrire le (ou les) module(s) d'extension, le fichier pilote qui définit quels sont les modules utilisés, et un fichier de modèle de document qui définit le modèle de document étendu. Le fichier pilote et celui du modèle de document sont décrits ci-dessous plus en détail.

Le fichier pilote.

C'est le fichier qui doit être référencé par une déclaration de DOCTYPE d'un document. Sa principale fonction est de définir quel fichier de modèle de document et quels fichiers de module SMIL le profil utilise. Il peut aussi définir un espace de nommage optionnel à utiliser dans tous les préfixes d'espaces de nommage. Par exemple, pour préfixer tous les noms d'éléments avec "foobar", on peut rajouter en début de profil ceci :

<!ENTITY % SMIL.prefixed "INCLUDE" >
<!ENTITY % SMIL.prefix "foobar" >

Les éléments définis dans leurs modules comme, par exemple, <video> seront analysés comme <foobar:video>. Cela s'applique aussi pour les attributs SMIL qui apparaissent dans d'autres éléments, donc, par exemple, "begin" devient "foobar:begin". Par défaut, le préfixe de qname est vide, c'est-à-dire, il est effectivement désactivé par défaut.

Après ces définitions, le fichier pilote inclut le fichier cadre (qui va inclure plus tard le fichier de type de données, celui des attributs communs, celui de qname et celui de modèle de document), après quoi les fichiers de modules SMIL sont inclus et utilisés par ce profil.

Le fichier de modèle de document.

Le fichier de modèle de document contient les entités XML qui sont utilisées par les fichiers de module SMIL pour définir les modèles de contenu et les listes d'attributs des éléments dans ce profil.

Les modèles de contenu diffèrent généralement d'un profil à l'autre, ou alors ils contiennent des éléments provenant d'autres modules. Pour éviter ces dépendances dans les fichiers de modules SMIL, les modèles de contenu doivent être définis dans un fichier de modèle de document. Le modèle de contenu par défaut (factice), comme défini dans les fichiers de module SMIL, est "EMPTY" pour tous les autres éléments de SMIL 2.0.

Pour les mêmes raisons, les fichiers de module SMIL définissent seulement une liste d'attributs par défaut pour leurs éléments. Cette liste par défaut contient seulement les attributs principaux de SMIL 2.0 ainsi que les attributs qui sont définis dans le même fichier de module SMIL. Tous les autres attributs doivent être ajoutés à cette liste par défaut en définissant les entités XML appropriées. Par exemple, le fichier de module des objets médias n'ajoute que le noyau et les attributs de média concernés sur les objets médias ; les autres attributs, comme ceux de temporisation, sont ajoutés à cette liste par le fichier du modèle de document.