Copyright © 2005-2022 Yves MARCOUX; dernière modification de cette page : 2022-01-04.

INU3011 Documents structurés – Premier Tour d’horizon de XML

Validité d’un document XML

Index de ce texte — Index général du Tour d’horizon — Accueil du Tour d’horizon

Yves MARCOUX - EBSI - Université de Montréal

Introduction

Les règles syntaxiques présentées dans les textes Qu’est-ce qu’un document XML ? et Les entités en XML déterminent ce qu’on appelle le bien-formé d’un document XML. Le simple fait de dire « document XML » sous-entend le respect de toutes ces règles. Un document qui n’est pas bien-formé n’est pas à proprement parler un document XML.

Il existe en XML une façon de définir des contraintes syntaxiques (donc, de forme) additionnelles, qui pourront s’appliquer à certains documents en plus des règles du bien-formé : c’est la mécanique de la validité. En définissant ces règles additionnelles, une gestionnaire de l’information peut s’assurer que les documents qui entrent dans son système ont tous une forme qui répond à ses attentes.

Pour comprendre en quoi l’imposition de contraintes de validité peut être utile pour la gestion de l’information, nous devons d’abord parler de l’imprévisibilité des documents bien formés.

Imprévisibilité des documents bien formés

Vous aurez probablement noté que la rédaction d’un document XML bien formé offre à son auteur à peu près autant de latitude qu’une feuille de papier blanche : une liberté quasi-totale. En effet, à part le fait que le document doit comporter un élément-document, tout est au choix de la personne qui crée le document : nombre d’éléments utilisés, noms d’élément, imbrication des éléments, attributs, etc.

Conséquences de l’imprévisibilité des documents

Pour comprendre l’effet d’une si grande latitude sur la gestion de l’information, examinons un scénario hypothétique.

Imaginez une professeure qui, pour mieux connaître ses étudiants, leur demande en début d’année d’inscrire sur un bout de papier leurs nom, prénom, date de naissance et programme d’études. Afin de pouvoir utiliser ces informations de façon systématique, elle prévoit les transcrire dans une feuille de calcul de tableur.

La professeure se rend vite compte qu’elle a un travail considérable devant elle. En effet, elle doit :

• Repérer sur chaque bout de papier les informations demandées, qui peuvent avoir été inscrites dans n’importe quel ordre.
• Uniformiser la façon dont les noms sont écrits : certains étudiants peuvent avoir utilisé la forme Prénom Nom, d’autres Nom, Prénom, d’autres encore Initiale Nom, etc. Bref, elle devra régulièrement distinguer un nom d’un prénom et sera peut-être aux prises avec des cas comme « Denis » et « Jacques », qui sont tous les deux à la fois nom et prénom.
• Uniformiser la façon dont les dates de naissance sont écrites. Sans compter qu’elle pourra faire face à des inscriptions ambiguës, comme 12-10-1999, qui peut désigner soit le 12 octobre, soit le 10 décembre.
• Composer avec les nombreuses abréviations et variantes utilisées dans les noms de programme d’études et les uniformiser.

Le problème est que les documents reçus des étudiants sont grandement imprévisibles. Les étudiants, même s’ils sont totalement disposés à fournir l’information demandée, ont simplement trop de latitude dans la façon de rédiger leurs informations.

Augmenter la prévisibilité des documents

L’année suivante, notre professeure prévient le coup et distribue aux étudiants ce simple formulaire :

Du coup, son effort de transcription est diminué d’au moins 50%. Bien qu’elle considère l’introduction du formulaire comme un succès, elle observe que l’uniformisation des noms de programme d’études lui demande encore beaucoup de travail. Ayant constaté que les trois programmes d’études les plus fréquents couvraient à peu près 80% des cas, elle modifie son formulaire l’année suivante :

Avec ce nouveau formulaire, elle estime que son travail de transcription a diminué de plus de 80% par rapport à la première année. Elle envisage donc de continuer à utiliser ce formulaire dans le futur (peut-être en l’ajustant si elle constate un changement dans les programmes les plus populaires).

Comment faut-il comprendre la démarche de la professeure ? L’introduction des formulaires a fait augmenter la prévisibilité des documents reçus des étudiants en restreignant leur latitude dans la façon d’exprimer l’information à transmettre. La tâche de traiter les documents reçus s’en est trouvée de beaucoup allégée.

La restriction « imposée » aux étudiants a bien peu de chances d’être perçue comme brimant leur liberté d’expression en tant que « créateurs ». Au contraire, pour les 80% qui n’auront qu’à cocher une case plutôt que d’écrire au complet le nom de leur programme d’études, cette restriction comporte même un bénéfice ! Même pour les autres, on peut arguer que l’utilisation du formulaire leur simplifie la vie, ne serait-ce qu’en éliminant la charge cognitive de se rappeler quelles informations doivent être fournies. De façon générale, un formulaire élimine le « syndrome de la page blanche » pour ceux qui le remplissent.

L’utilisation du formulaire ne garantit évidemment pas l’exactitude de l’information inscrite par les étudiants, cependant, elle fait en sorte qu’un étudiant consciencieux et disposé à fournir les informations demandées a toutes les chances d’arriver à produire un document facile à traiter et dont le contenu est conforme à la réalité.

Ce qu’il faut retenir, c’est que des documents ayant une grande prévisibilité sont plus faciles à traiter que des documents présentant de grandes variations de forme et qu’une prévisibilité suffisante peut souvent être atteinte sans grandes contraintes pour les auteurs. Cela est vrai pour des documents rédigés et traités à la main, mais également – et peut-être encore plus – pour des documents numériques que l’on envisage de traiter par ordinateur.

La validité : pour augmenter la prévisibilité des documents

Une gestionnaire de l’information qui envisagerait que mettre sur pied un système informatisé acceptant à l’entrée des documents XML bien formés serait un peu comme notre professeure demandant à ses étudiants de lui remettre un « bout de papier » contenant certaines informations. Les documents qu’elles recevrait n’aurait aucune prévisibilité et il serait extrêmement difficile de demander à un programmeur de développer une application pour les traiter adéquatement.

L’idée générale : les « règles d’écriture »

Une option pour la gestionnaire serait d’énoncer des « règles d’écriture » visant à imposer une certaine prévisibilité aux documents, du genre « Assurez-vous d’inscrire votre nom dans un élément nom contenant deux sous-éléments prénom et nom-de-famille, dans cet ordre » ou encore « SVP, inscrivez la date sous la forme AAAA-MM-JJ dans un élément date, qui sera enfant de l’élément-document mémo ». Cependant :

• Pour être vraiment utiles, ces règles devraient avoir un niveau de précision tel que leur formulation en deviendrait alambiquée, au point de les rendre pratiquement incompréhensibles.
• Il serait fastidieux pour les auteurs de prendre connaissance de ces règles, de bien les comprendre et de ne pas en oublier.
• Il n’y aurait aucune façon automatisée pour les auteurs de vérifier qu’ils ont respecté les règles avant de soumettre leurs documents au système.
• Loin de constituer une aide à la création de documents acceptables, ces règles agiraient plutôt comme une entrave à la création de documents pour les auteurs.

Les règles d’écriture rédigées en langue naturelle ne représentent donc pas une option réaliste. C’est ici que la mécanique de validité des documents XML vient à la rescousse : elle permet en quelque sorte à la gestionnaire d’information d’exprimer des règles d’écriture, vérifiables automatiquement, qui peuvent restreindre autant que désiré la forme que peut prendre un document XML. Ces règles n’ont pas besoin d’être interprétées par un humain (bien que ce soit possible) et leur vérification automatique peut être déclenchée par l’auteur lui-même avant qu’il ne soumette ses documents au système. La mécanique de validité XML agit un peu comme les formulaires dans notre scénario tout à l’heure. Bien pensées, les règles de validité XML peuvent véritablement agir comme une aide à la création de documents que notre système peut accepter, en plus d’assurer la gestionnaire de l’information que les documents qui entrent dans son système ont la forme voulue, et sont donc faciles à traiter.

La mécanique de la validité en XML

Voici comment fonctionne la mécanique de la validité en XML. Une gestionnaire de l’information rédige d’abord des contraintes additionnelles de forme (en sus du bien-formé) qu’elle veut voir satisfaites par les documents XML qui entrent dans « son système » (l’application informatique de traitement de documents qu’elle s’apprête à mettre sur pied). Ces contraintes additionnelles sont rédigées dans un langage particulier, le langage des DTD, qui ressemble légèrement au XML bien formé, mais qui en est fondamentalement très différent. Un ensemble de contraintes exprimées dans ce langage s’appelle une DTD (pour Document Type Definition); la gestionnaire rédige donc sa DTD, puis elle place celle-ci à un emplacement accessible sur le Web (dans les cas simples, qui nous intéressent en ce moment, une DTD consiste en un seul fichier).

Une fois le système mis en service, elle informe les auteurs qu’ils devront produire des documents conformes à cette DTD, c’est-à-dire des documents qui, en plus d’être bien formés, respectent les contraintes additionnelles exprimées dans la DTD. Elle leur fournit bien entendu l’adresse Web de la DTD (donc, son URL), de même que le nom (identificateur générique) qu’ils devront donner à l’élément de plus haut niveau (l’élément-document) de leurs documents. On pourrait s’attendre à ce que le nom que l’on doit donner à l’élément de plus haut niveau des documents fasse partie des règles exprimées dans la DTD, mais curieusement, pour une raison technique et historique, il n’en fait pas partie.

Pour signaler qu’ils veulent créer des documents satisfaisant aux contraintes additionnelles de la DTD, les auteurs ajoutent au début de leurs documents (donc, dans le prologue) une déclaration de type de document (aussi appelée déclaration DOCTYPE), qui a cette forme :

<!DOCTYPE ephn SYSTEM "URL-de-la-DTD">

où ephn doit être remplacé par le nom prescrit par la gestionnaire pour l’élément de plus haut niveau des documents, et URL-de-la-DTD par l’URL, également fournie par la gestionnaire. Par exemple :

<!DOCTYPE info-perso SYSTEM "http://univ.dumonde.org/prof-techno/info-perso.dtd">

Pour un auteur qui utilise un éditeur XML (comme oXygen), l’ajout de la déclaration de type de document dans le prologue du document a un effet « magique ». En effet, l’éditeur récupère alors la DTD, prend connaissance des règles additionnelles qui doivent être respectées, et est en mesure de guider l’auteur dans la rédaction d’un document conforme à la DTD, c’est-à-dire qui respecte ces règles, en plus d’être bien formé.

En tout temps pendant la rédaction du document, l’auteur peut demander à l’éditeur de valider le document, c’est-à-dire de vérifier s’il respecte les règles additionnelles de la DTD, en plus d’être bien formé. Si le document n’est pas valide, souvent l’éditeur pourra émettre un diagnostic très précis qui aidera réellement l’auteur à régler la disparité entre son document en l’état et la forme imposée par la gestionnaire via la DTD.

Lorsqu’il a complété la rédaction d’un document, l’auteur fait une validation finale dans l’éditeur, pour s’assurer que le document a une forme acceptable. Sur réception du document, le système effectue de son côté aussi une validation (automatisée) du document et n’accepte le document que s’il est valide.

En résumé, on dit qu’un document XML est valide si les trois conditions ci-après sont satisfaites :

1. Le document est bien formé.
2. Il comporte une déclaration DOCTYPE dans son prologue, laquelle pointe à une DTD existante.
3. Il satisfait aux règles additionnelles exprimées dans la DTD.

Une DTD est aussi appelée modèle XML. Une DTD définit un type de document. Nous désignons la personne qui crée une DTD par le mot modélisatrice; la modélisation est le travail de concevoir un modèle XML pour un certain type de document. La modélisatrice peut être la même personne que la gestionnaire de l’information responsable de la mise sur pied du système elle-même, ou ce peut être une personne mandatée par celle-ci.

Le langage des DTD est traité dans un texte séparé.

Notons qu’il existe d’autres mécanismes que les DTD pour définir des contraintes syntaxiques additionnelles au bien-formé. L’un des plus populaires est celui des schémas XML du W3C. Le principe est le même, mais la nature exacte des contraintes que l’on peut définir et la façon de les exprimer varient. Ces autres mécanismes ne sont pas couverts dans le cours.

Applications XML

Une application XML n’est rien d’autre qu’un système de traitement de documents XML, c’est-à-dire un système informatisé capable d’accepter, de produire et/ou de transformer des documents XML. Une telle application peut revêtir des formes très variées, du simple logiciel installé sur un ordinateur personnel jusqu’au système transactionnel en ligne.

Applications validantes et non validantes

Aucune application XML ne peut accepter un document qui n’est pas bien-formé sans, minimalement, émettre un message d’erreur. Cependant, en plus du bien-formé, certaines applications peuvent exiger que les documents soient valides. On parle alors d’applications validantes.

Une application validante refusera les documents qui ne sont pas bien-formés, ou qui sont bien-formés mais non valides. Une application non validante acceptera tous les documents bien-formés; en particulier, elle ne refusera pas les documents qui, en plus d’être bien-formés, sont valides. Cependant, elle n’en vérifiera pas la validité. La quasi-totalité des navigateurs Web, en tant qu’applications acceptant des documents XML, sont des applications non validantes.

Certaines applications sont à la fois validantes et non validantes, c’est-à-dire validantes ou non selon les fonctions à accomplir ou selon les demandes de l’utilisateur. L’éditeur oXygen est de ce type : il peut ne vérifier que le bien-formé d’un document, ou encore en vérifier aussi la validité (si, bien sûr, le document comporte une déclaration DOCTYPE).

Applications génériques et spécialisées

Certaines applications sont capables de travailler avec n’importe quel document XML bien formé. Ce sont des applications dites génériques. Comme ces applications ne peuvent compter sur aucune prévisibilité dans les documents, les traitements qu’elles permettent de faire sont en général assez rudimentaires, par exemple, les afficher avec une interprétation minimale (ce que font les navigateurs Web, en l’absence d’une feuille de style) ou encore en faire l’édition en tant que fichier texte (ce que fait un éditeur comme oXygen, en mode texte).

Dans un contexte où une gestionnaire de l’information définit une DTD pour restreindre la forme des documents acceptables, les applications développées n’ont pas besoin de pouvoir travailler avec n’importe quel document bien formé; il leur suffit d’accepter les documents valides selon cette DTD. On parle alors d’applications spécialisées; elles sont spécialisées au type de documents correspondant à la DTD.

Normalement, une application spécialisée sera validante, en ce sens qu’elle vérifiera explicitement que les documents qu’on lui soumet sont bien conformes au modèle auquel elle s’attend. Cependant, certaines applications spécialisées prennent pour acquis que la validation des documents est faite en amont dans la chaîne de traitement des documents et ne prennent pas la peine de valider les documents soumis. Évidemment, le comportement de telles applications est imprévisible si jamais on leur soumet des documents qui ne se conforment pas au modèle attendu, puisqu’elles sont conçues pour ne traiter que les documents qui s’y conforment.

Une feuille de style effectuant une présentation particulière d’un type de document (une facture, une notice bibliographique, etc.) est un exemple tout simple d’application spécialisée. Une telle application est souvent non validante, notamment lorsqu’elle s’appuie sur les capacités de stylage des navigateurs Web, lesquels ne valident pas les documents. Dans ce contexte, il est important de s’assurer que les documents sont validés à un certain moment dans la chaîne de traitement, avant qu’on ne leur applique la feuille de style.

Les feuilles de style – surtout XSLT, mais également CSS – sont le principal type d’application que nous verrons directement dans le cours.