Tablix utilise un fichier au format XML pour enregistrer les informations relatives à l'emploi du temps. Le format XML repose sur l'utilisation de balises, emboitées les unes dans les autres. Chaque balise peut avoir un ou plusieurs attributs et certaines peuvent inclure du texte. La balise du premier niveau (top level), qui doit englober toutes les autres, est appelée la racine.
Note: Le document fixant la définition des types (DTD) utilisés pour le fichier de configuration de Tablix peut être lu en ligne.
Tip: L'erreur la plus répandue rencontrée chez les nouveaux utilisateurs est de mettre les balises
<restriction>aux mauvais endroits dans le fichier XML. Dans la plupart des cas, Tablix ignorera, en silence, les balises inconnues rencontrées de le fichier de configuration, et par conséquent ignorera toutes les balises<restriction>qui ne sont pas à leurs places.Si vous n'êtes pas certain de la syntaxe de votre fichier XML, ou si Tablix semble ignorer certaines de vos balises
<restriction>, vous pouvez utiliser xmllint, qui est fourni avec libxml2, pour vérifier que votre fichier est comforme à la DTD. Tapez xmllint --valid --noout your-config-file.xml dans une console de commandes. Si aucun message d'erreur n'est signalé, la syntaxe du fichier est correcte.
Le fichier de configuration comprend plusieurs parties. Elles sont délimitées par des balises. La balise racine doit s'appeler <ttm>. Elle doit avoir l'attribut version, avec pour valeur le numéro de version du format utilisé. Ce numéro de version doit être "0.2.0" pour toutes les versions du noyau Tablix supérieures à 0.2.1 .
Note: Toutes les chaînes de caractères (noms des ressources, types de restrictions, etc...) qui sont utilisées dans le fichier XML sont sensibles à la casse. Vous pouvez, par exmple, avoir 3 différentes ressources, avec les noms "ALPHA", "Alpha" et "alpha".
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE ttm PUBLIC "-//Tablix//DTD TTM 0.2.0//EN" "http://www.tablix.org/releases/dtd/tablix2r1.dtd">
<ttm version="0.2.0">
.
.
.
</ttm>
La première partie de la configuration est optionnelle. Vous pouvez mettre les informations concernants l'auteur , l'adresse de l'institution et le titre de l'emploi du temps dans la balise <info>.
<info>
<title>Exemple Ecole de la République</title>
<address>3, rue de la Liberté</address>
<author>Responsable de l'emploi du temps</author>
</info>
Ces informations seront affichées au dessus de l'emploi du temps lorsqu'il est exporté au format XHTML.
La partie suivante définit les modules qui seront utilisés par Tablix. Cette partie, et toutes les autres affiliées sont obligatoires.
Les modules sont listés dans des balises <module>, emboîtées dans la balise <modules>.
<modules>
<module name="sametime.so" weight="200" mandatory="yes"/>
.
.
.
<modules>
Certains modules peuvent accepter des options. Elles sont alors spécifiées dans les balises <option>. Chaque option porte un nom (specifié à l'aide de l'attribut name) et une valeur.
<modules>
<module name="holes.so" weight="6" mandatory="no">
<option name="resourcetype">class</option>
</module>
.
.
.
</modules>
Note: En sélectionnant des modules, vous choississez le groupe d'erreurs pour lequel Tablix essaiera d'optimiser l'emploi du temps. Par les valeurs des poids, vous pouvez signifier à Tablix qu'elles sont les importances relatives des erreurs.
Note: Chaque module peut définir un ou plus types de restrictions. Reportez-vous au manuel de référence des modules pour connaître plus précisément quel module définit quel restriction. Tablix ignorera toutes les types de restrictions inconnus. Un avertissement est affiché pour toute restriction inconnue rencontrée si le niveau de "verbosité" est fixé à 3 ou plus (valeur à 2 par défaut)
Astuce: Vous pouvez trouver des exemples bien configurés pour tous les modules dans le sous-répertoire ttf/tests/. Chaque module inclu dans la distribution est l'objet d'un ou plusieurs tests. Ces tests sont utilisés par la strucuture de test de Tablix (Tablix Testing Framework) pour vérifier si les modules fonctionnent correctement. Pour l'instant, vous pouvez considérer ces fichiers comme des fichiers de configuration (description de problème d'emploi du temps) et ignorer le code "Scheme" supplémentaire du début.
Tous les types de ressources qui seront utilisés dans votre emploi du temps doivent être définies dans la balise <resources> .
<resources>
<constant>
.
.
.
</constant>
<variable>
.
.
.
</variable>
</resources>
Les types de ressource constants doivent être définis dans la balise <constant> et les types de ressource variables dans la balise <variable> .
Un type de ressource est défini avec une balise <resourcetype> . Le nom du type est spécifié par l'attribut type .
<constant>
<resourcetype type="teacher">
.
.
.
</resourcetype>
.
.
.
</constant>
Chaque type de ressource peut contenir une ou plusieurs ressources. Une ressource simple est définie avec une balise <resource> à l'intérieur de <resourcetype>.
Chaque ressource doit avoir son nom défini avec l'attribut name .
Note: Deux ressources d'un même type de ressource ne peuvent pas avoir un nom identique.
<resourcetype type="teacher">
<resource name="Prof. SJK 1"/>
.
.
.
</resourcetype>
Si certains modules ont des restrictions de ressources pour les types de ressources définies, vous pouvez alors appliquer une restriction à une ressource avec la balise <restriction> .
<resourcetype type="class">
<resource name="3 B">
<restriction type="conflicts-with">3 MA-FIZ</restriction>
</resource>
.
.
.
</resourcetype>
Chaque restriction a un type (spécifié avec l'attribut type) et une valeur.
Une série de ressources peut être définie avec la balise <linear> . C'est un moyen simple pour définir un grand nombre de ressources identiques.
<resourcetype type="room">
<linear name="K#" from="1" to="5">
<restriction type="capability">Kemija</restriction>
</linear>
.
.
.
</resourcetype>
Vous devez donner un nom à la série de ressources à l'aide de l'attribut name. Le caractère '#' dans le nom sera remplacé par un entier prend sa valeur dans l'échelle définie par les attributs from (de) et to (à) .
Les restrictions de ressource peut être appliquées de la même manière que la balise <resource> .
L'exemple ci-dessus, définira 5 ressources, portant les noms K1, K2, ...,K5. Toutes ces ressources auront la restriction "capability" qui leur sera appliquée.
Une matrice de ressource est définie d'une façon similaire, en utilisant la balise <matrix> .
<resourcetype type="time">
<matrix width="5" height="8"/>
</resourcetype>
Les attributs (propriétés) width et height définissent les dimensions de la matrice. Vous pouvez ne pas donner de nom pour les ressources de cette matrice. Toutes les ressources seront nommées "XY", où X est le numéro de ligne de la ressource dans la matrice et Y celui de sa colonne.
Les restrictions de ressources peuvent être appliquées à une matrice de ressources avec la balise <resource> .
Les évènements doivent être définis avec des balises <event>, au sein de la balise <events> .
<events>
<event name="SJK" repeats="4">
.
.
.
</event>
.
.
.
</events>
Chaque évènement a un nom défini par l'attribut name. Deux évènements différents peuvent porter le même nom; cependant cette pratique n'est pas recommandée car elle peut perturber le fonctionnement de certains modules.
L'attribut repeats définit le nombre de fois que l'évènement se répète. Par exemple, si un évènement à une valeur de 4 pour l'attribut repeats , cela équivaut à avoir déclaré 4 balises <event> définissant cet évènement dans le fichier de configuration.
Note:
repeatsn'a pas d'autre effet caché. Il n'existe que pour faciliter l'écriture du fichier XML à la main. Cela veut dire que les 2 exemples suivants sont absolument identiques pour Tablix. En fait, si vous regardez le fichier XML de la solution correspondant au problème, vous verrez que toutes les balises<event>sont réécrites de sorte qu'il n'y ait aucunrepeatsd'une valeur supérieure à 1.Cet exemple...
<event name="SJK" repeats="3"> . . . </event>...est identique à celui-là:
<event name="SJK" repeats="1"> . . . </event> <event name="SJK" repeats="1"> . . . </event> <event name="SJK" repeats="1"> . . . </event>
Les ressources utilisées par un évènement sont définies avec des balises <resource> à l'intérieur de la balise <event> .
<event name="SJK" repeats="4">
<resource type="teacher" name="Prof. SJK 1"/>
<resource type="class" name="1 A"/>
</event>
Les balises <resource> doivent avoir les attributs type et name renseignés. Cela est obligatoire pour assigner une ressource de chaque type de ressource constant à chaque évènement. Optionnellement, vous pouvez également assigner une ressource d'un, ou plusieurs, types de ressources variables à un ou plusieurs évènements. De telles assignations seront considérés comme des conseils par le noyau Tablix. Ils peuvent être utilisés pour la solution définitive s'ils aident à réduire la valeur d'ajustage de l'emploi du temps.
Note: Remarquez que ces "conseils" ne sont pas équivalents aux "fixed tuples" de la branche 0.1 . Si vous souhaitez assigner de façon permanente des ressources variables à un évènement, vous devez utiliser un module qui définit une restriction qui l'implémente.
Par exemple, pour planifier un évènement à heure fixe, vous pouvez utiliser le module fixedtime.so.
Si certains modules ont défini des restrictions concernant les évènements, vous pouvez alors appliquer une restriction d'évènent un insérant une balise <restriction> à l'intérieur de la balise <event> .
<event name="KEM" repeats="2">
<resource type="teacher" name="Prof. KEM 2"/>
<resource type="class" name="1 B"/>
<restriction type="capability">Kemija</restriction>
</event>
Comme pour les restrictions de ressources, chaque restriction d'évènement à un type (specifié à l'aide de l'attribut type ) et une valeur.