Comme l'indiquait l'intitulé même de l'exercice, "premiers pas
en XML", l'objectif premier ici était d'apprendre à marcher.
Sous cet angle, je pense avoir en partie rempli ma "mission", je peux faire
vingt mètres sans me casser la figure. Par contre, j'ai pu aussi me
rendre compte de l'étendue des possibilités ouvertes par XML,
et donc du potentiel de travail encore à fournir.
Plus sérieusement, en abordant cet exercice, mon idée était
de réaliser un petit dispositif très modeste mais qui puisse
servir de base de travail au développement d'un instrument plus
véritablement efficace, et qui pourrait s'insérerer dans le
projet sur lequel je travaille
(projet
pilote NTIC du rectorat). C'est d'ailleurs un peu la même "philosophie"
que j'ai déjà adopté pour staf 18. Dans cette
optique, il me semble que le résultat de l'exercice correspond bien
à l'esprit de départ, c'est-à-dire qu'il ne s'agit vraiment
pas d'un produit fini mais d'une sorte d'ébauche qui pose les grandes
lignes du travail à venir. A ce titre, le plus instructif dans cette
première étape réside certainement dans les insuffisances
du dispositif en l'état actuel et les erreurs (voir ci-dessous) commises
du fait d'anticipations erronées. En effet, ce qui apparaît
au premier abord comme des conséquences négatives, m'a
révélé certains aspects du XML-designing qui constituent
du coup un enseigement extrémement positif. Je pense
particulièrement à certaines différences entre la
création avec HTML et celle avec XML; il me semble en effet qu'avec
ce dernier, la partie "conception" du travail doit être beaucoup plus
rigoureuse, et qu'il est difficile de se lancer dans la réalisation
sans avoir une idée très claire de ce que l'on veut, la
contrepartie étant de pouvoir réaliser des objets nettement
plus performant.
Concernant encore les erreurs de conception, j'aurais pu en réparer
certaines, mais commençaient sérieusement à manquer
le temps, et l'envie aussi :).
Comme pour staf 18, le contexte dans lequel doit venir s'insérer
l'exercice réalisé détermine fortement les contenus.
Néanmoins, j'essaye toujours, parmi les possibilités qui me
sont offertes, de choisir un thème qui corresponde à la
"technique", pour le moins à l'idée que je m'en fais. Ainsi,
voyant l'usage qui a été fait de XML dans le cadre de staf
18, j'ai tout de suite pensé à réaliser un "rapport
d'évaluation", qui rentrait évidemment dans le cadre de mon
projet pédagogique, puisque le cours sur lequel il porte comprend
des tests réguliers. J'ai donc imaginé, à partir des
tests qui ont été soummis cette année aux étudiants,
quel type de feed-back il serait possible, ou même souhaitable, de
leur donner (actuellement ils n'obtiennent que leur note et nous organisons
une permanence pour la consultation des copies).
Dans un premier temps, j'ai repéré quatre éléments
qui selon moi devraient apparaître et qui ont donné la structure
à mon dispositif XML; ces quatre éléments sont les
"informations générales", "appréciations globales",
qui donne un point de vue d'ensemble sur l'examen, les "corrections"
et enfin les "conseils".
A l'usage, c'est-à-dire en créant des exemples à partir de vrai copies d'examen, j'ai trouvé que le dispositif est assez convivial et qu'en le retravaillant sur certains points, il pourrait assez rapidement être opérationnel. Le point faible principal, selon moi, réside dans la structuration de la partie "correction", celle-ci en effet s'est révélée beaucoup trop rigide et assez mal adaptée au type d'examens auquelle elle est censée s'appliquer. Une piste pourrait être de traiter les copies par unité d'erreurs, c'est-à-dire de ne plus simplement reproduire la structure de l'examen et de mettre des justes ou des faux à côté de chaque exercice ou même sous-exercice, mais de prendre chaque erreur une à une (à la limite dans un ordre thématique) et dans indiquer la location dans l'exament.
.
J'ai eu beaucoup, et j'en ai encore pas mal, de peine à voir à l'avance quelle influence une modification dans tel document aura sur tel autre. Ce problème s'est révélée de manière flagrante avec le mise en page; imaginant en effet qu'il suffisait de déclarer dans le DTD que des éléments étaient facultatifs pour que non-utilisés ils n'apparaissent pas (je voulais surtout que n'apparaissent pas tous les exercices n'existant pas dans l'examen); j'ai donc essayé de sauver un peu les meubles mais la mise en page demeure passablement insatisfaisante.
Par ailleurs, j'ai été tiraillé au niveau des outils: je n'ai pas trouvé d'éditeurs validants, les seuls que j'ai trouvé sur le net étaient inaccessibles (liens cassés, serveur introuvable, etc) et de l'autre côté, alors que j'étais enfin résolu à prendre les quelques heures pour apprendre Emacs, j'ai été complétement incapable de l'installer (problème de décompression avec les *.tar). Tout ça pour dire que j'ai pas mal bricoler et qu'il ne faudrait pas s'étonner de tomber sur des trucs pas très orthodoxes :)
Ci-dessous sont les liens vers les différentes pages réalisées, à noter qu'ici le XML est le document à vide, des exemples dans la prochaine section donneront une meilleure idée de l'utilisation du dispositif.
| DTD | XSL | XML |
Voici deux utilisations du rapport d'évaluation qui illustrent bien, je crois, les qualités et les insuffisances de cet exercice.
Julien Dubouchet
<--Created by J.D., 1-JUL-99-->