Présentation du schéma XML DAPA

Selon une approche documentaire relativement classique, on pourrait présenter en premier lieu la nature rédactionnelle du schéma DAPA. En effet, l'un des objectifs principaux du schéma est de permettre la création de documents rédigés pour être lus de manière séquentielle, comme une monographie, un article, etc. Cette approche rédactionnelle est à opposer à l'approche base de données qui consiste à mettre des informations dans des cases précises et à les restituer selon une certain logique applicative. On peut par contre faire une analogie entre cette approche et les documents produits à l'aide d'un traitement de texte, même si cette analogie est très superficielle.

Il est toutefois important d'aller au-delà de cette première approche classique pour réaliser que le schéma DAPA permet de créer des documents structurés, c'est-à-dire des documents qui contiennent de l'information à propos de leur structure, que cette structure soit logique (séparation en parties, sections, paragraphes, etc.) ou sémantique (rôle de certaines parties du texte). La mise en place d'un système d'information basé sur des documents structurés est essentielle si l'on veut associer à la fois les mérites des documents de nature rédactionnelle – clarté, facilité de lecture, souplesse pour exprimer un discours – et les avantages de l'information structurée telle qu'on la retrouve dans des bases de données – possibilité de manipuler l'information de différentes manières, recherches précises. Ainsi, à partir d'un corpus de documents XML respectant le schéma DAPA, il est possible de créer des outils qui vont effectuer des recherches uniquement dans les titres (pour une meilleure précision), qui vont extraire automatiquement des tables des matières pour les inclure dans un système de diffusion sélective d'information, qui vont produire des listes d'illustrations, etc.

Mais le schéma DAPA permet d'aller beaucoup plus loin que la création de documents structurés de nature rédactionnelle. Il permet de créer de véritables dossiers électroniques, où l'on retrouvera toutes les informations numériques – textes, images, animations, vidéo, son – à propos d'une entité, que celle-ci soit une œuvre du patrimoine, une personne, un lieu, etc. Cette notion de dossier électronique fait largement appel à la possibilité de relier entre eux de nombreux documents, de définir le rôle de ces relations mais également des documents à l'intérieur des dossiers et d'intégrer de manière cohérente et structurée des éléments multimédia tels que des images.

Pour arriver à représenter de tels dossiers électroniques – et leurs constituantes – le schéma DAPA propose une approche cohérente : l'utilisation d'un même jeu de métadonnées, basé sur les normes Dublin Core et Geographical Markup Language, pour décrire l'ensemble des constituantes d'un dossier électronique. Ces métadonnées peuvent ainsi décrire non seulement les documents, mais leurs parties et ce jusqu'à un niveau très fin (on peut ainsi préciser l'auteur ou les droits associés à une section), elles peuvent décrire des objets externes comme des images, mais aussi des relations pour préciser leur rôle ou leur fonction.

Par cette généralisation de l'utilisation d'un même format de métadonnées, il est possible de non seulement constituer des corpus de documents structurés en format XML, mais de leur donner une cohérence d'ensemble qui permet de produire de véritables dossiers électroniques.

Dans un schéma XML, ou toute autre forme de grammaire telle une DTD, on peut définir un certain nombre de contraintes que les documents devront respecter pour être valides selon cette grammaire. Ces contraintes sont toutefois fort limitées, et se résument à :

• Le nom des éléments, autrement dit les éléments qui peuvent être utilisés dans le document, voire dans certains cas l'espace de noms auquel ils doivent appartenir.

• Les attributs que l'on peut associer à un élément, et le caractère obligatoire ou non de ces attributs.

• Les valeurs que peuvent prendre des attributs ou des éléments, en fonction de règles simples, de patrons de valeurs définies par des expressions régulières, de listes de valeurs ouvertes ou fermées, etc.

• Les éléments que l'on peut inclure à l'intérieur d'un élément, de même que la possibilité d'y ajouter du texte ou non.

• Le caractère obligatoire ou répétable des éléments.

Ces contraintes sont en général suffisantes pour permettre de mettre au point un système d'information complet et robuste au sein d'une institution, d'un groupe, d'un projet, etc. Toutefois, lorsque le schéma a été défini dans un autre contexte ou dans un contexte plus large, plus générique, il est fort probable que les contraintes qu'on y trouve seront trop génériques ou pas totalement appropriées. C'est pourquoi, dans un tel contexte, il est nécessaire de réfléchir à d'autres façons de mettre en place les contraintes nécessaires.

Ce commentaire s'applique parfaitement au schéma DAPA. En effet, même s'il fut réalisé dans le cadre d'un projet précis initié par la direction de l'architecture et du patrimoine, il reste relativement générique, justement dans le but de permettre aux utilisateurs – gestionnaires de projets, auteurs, contributeurs – de créer de l'information appropriée en contenu et en structure. On peut donc qualifier le schéma DAPA de générique, et c'est pourquoi il est utile de réfléchir à d'autres moyens d'apporter des contraintes dans un système d'information XML.

Une première approche serait de définir son propre schéma institutionnel ou projet, en s'assurant que les documents qui respectent ce schéma puissent être convertis automatiquement dans un format qui respecte le schéma initial, et ce dans le but de rester compatible avec ce schéma. Cette approche a l'avantage de pouvoir être très précise et très conforme aux souhaits de l'institution ou du projet, mais en contrepartie elle demande des efforts importants pour la mettre en place et elle ne facilite pas les mises à jour si jamais le schéma initial évolue.

C'est pourquoi nous proposons d'autres approches qui consistent à apporter de nouvelles couches de contraintes au-delà du schéma XML, couches qui pourraient s'appliquer à différents endroits dans un système d'information gérant des documents XML.

• L'outil de production

  Au-delà de la grammaire elle-même, l'outil de production peut offrir des contraintes additionnelles. C'est le cas, par exemple, lorsque l'outil nous permettra de choisir des termes d'indexation dans une liste pour les insérer dans un élément XML, sans que cette liste ne soit définie dans le schéma. Ou encore, si l'on programme l'outil de production pour rendre un élément obligatoire en avertissant l'utilisateur, au moment de la sauvegarde du document, si cet élément n'est pas présent.

• La vérification des documents

  On peut également imaginer une étape de vérification des documents, externe à l'outil de production, qui permettrait d'effectuer un certain nombre de vérifications plus sophistiquées ou moins précises. Par exemple, on pourrait implémenter une vérification de l'ensemble du document pour voir si la structure générale (chapitres et sections par exemple) respecte les consignes de rédaction propres à un groupe ou un environnement. On pourrait également vérifier si les termes d'indexation saisis dans le document correspondent bien à des entrées d'un vocabulaire contrôlé qui serait accessible dans un autre outil.

  Cette couche de contraintes peut être préférable à celle offerte par l'outil de production dans le cas où les contraintes ne sont pas obligatoires. En effet, le retour de cette étape de validation pourrait être à la fois des suggestions et des éléments d'information, pas seulement des obligations de modifications. Par ailleurs, lorsque des contraintes ne peuvent être vérifiées directement dans l'outil de production (par exemple si l'accès à des ressources n'est pas possible ou si l'environnement de production ne peut pas être programmé pour le faire), cette approche peut être très utile et très performante.

• La vérification des corpus

  Les contraintes par vérification des corpus sont en quelque sorte différentes des autres couches introduites ici car elles s'effectuent pas uniquement sur un document XML, mais sur l'ensemble d'un corpus auquel appartient le document. Par exemple, un document XML pourrait être vérifié avec les autres documents faisant partie d'un dossier électronique, ou parmi l'ensemble des documents d'un corpus de dossiers électroniques.

  Cette approche est utile pour vérifier l'intégrité du corpus, notamment les liens qui peuvent exister entre les différents documents. Ou encore pour vérifier l'unicité des identifiants.

En choisissant une approche qui consiste à définir un schéma XML générique et des guides d'utilisation de plus en plus spécifiques, nous avons fait le pari que de telles couches de contraintes allaient être mises en place afin de s'assurer que dans un contexte précis d'utilisation du schéma, une cohérence plus grande que celle contrainte par ce dernier allait pouvoir être mise en place. Toutefois, il convient de souligner que les bénéfices d'un schéma générique dépassent largement cet inconvénient.