XML : Principe et utilisation

Table of Contents

1. Introduction
2. Structure d'un document XML
3. Le XML bien formé
4. Pratique : verifier automatiquement un document XML
5. Un petit peu plus loin avec la Définition de Type de Document (DTD)
6. Et ensuite ...?

1. Introduction

Depuis 1998, XML ou eXtensible Markup Language est un standard en développement qui ne cesse d'augmenter son champ de compétence. On le retrouve dans beaucoup d'application et promet beaucoup de choses. A tel point que pour certains XML en soit venu à signifier eXtraordinary Marketing Language tant sa présence est devenue envahissante. Une des principale raisons de ce raz de marée XML est la parution d'un grand nombre de recommendations liées à ce standard en vue de rendre possible divers traitement de l'information. XML et ses DTD, XSL, XPath, XLink, XPointer et d'autres encore, constituent aujourd'hui une nébuleuse dans laquelle il n'est pas simple de se repérer, et dont même le point d'entrée n'est plus évident. A cela s'ajoute la disponibilité d'outils utilisant directement XML et ses dérivés et difficilemment utilisables sans maitriser les bases de ces standards.

Le but de ces articles est d'offrir un moyen de se constituer une vue d'ensemble de XML qui permettra d'utiliser les recommendations exhaustives du W3C à l'origine de ces standards peu adaptées à l'apprentissage ex nihilo. Comme XML est un ensemble de recommendation, il est possible d'en parler pendant des heures en restant théorique, alors que la raison de toutes ces recommendations est quand même d'aboutir à des applications concrètes destinées à simplifier la vie des utilisateurs en reposant sur des bases solides. L'accent sera donc mis au fur et à mesure de la progression sur des exemples pratiques permettant de se faire la main avec les outils existants, car ces outils commencent à être nombreux.

Au cours de la découverte des differents aspects de XML, la première constatation que l'on fait généralement est qu'il n'y a rien de magique et qu'il existe parfois déja d'autres outils depuis longtemps qui font le travail beaucoup mieux. C'est vrai, XML n'est pas magique, mais offre quantités de solutions pour resoudre les problèmes quand d'autres atteignent leurs limites, le tout reposant sur des standards ouverts.

Au cours de ces articles, nous allons aborder le standard XML en lui même et son compagnon inséparable que sont les DTD. Puis nous introduirons petit à petit les extensions sans qui XML ne serait finalement pas grand choses.

2. Structure d'un document XML

XML est un ensemble de recommendation qui permettent de representer des informations au moyen de balises. 

  <?xml version="1.0"?>
  <contenu>
    Le reste de mon information ici...
  </contenu>

L'exemple de fichier minimal ci-dessus montre qu'un fichier devrait commencer, mais ce n'est pas obligatoire, par la declaration xml indiquant le numéro de version utilisé. Il s'agit actuellement de la version 1.0, la seule et unique utilisable. Puis vient notre balise contenu qui constitue l'élément racine de notre fichier XML. Le nom de cette balise ( le texte écrit entre les signe < et >) n'a aucune importance et peut être choisi librement parmi n'importe quel nom pouvant contenir des lettres majuscules ou minuscule, des chiffres ou les caractères -'()+,./:=?;!*#@$_% (en fait il faut retenir qu'il n'y a pas les caractères <, > ni & ni d'espace et que : n'est pas recommendé car utilisé par une autre recommendations XML ). A la suite de cette balise vient la suite de l'information, puis finalement la balise de fermeture portant le même nom que la balise d'ouverture avec un simple / devant. En XML, toute balise ouverte doit être refermée.

Un mot important a été utilisé dans le paragraphe précédent : il s'agit de racine du document. Il est possible en effet de représenter tout document XML sous forme d'arbre. Ainsi : 

  <?xml version="1.0"?>
  <contenu>
    <debut>
      Le debut ici ...
    </debut>
    <milieu>
      Le milieu ici ...
    </milieu>
    <fin>
      La fin ici ...
    </fin>
      Eventuellement, encore quelque chose ici ...
  </contenu>

peut être representé par : 

 contenu
   |_debut
   |   |_Le debut ici ...
   |_milieu
   |   |_Le milieu ici ...
   |_fin
   |   |_La fin ici ...
   |_Eventuellement, encore quelque chose ici ...

Cette dernière représentation rend évidente la notion de racine que constitue notre élément contenu. Il suffit alors de savoir que XML n'autorise qu'un seul élément racine par document.

On constate que XML présente des similitudes avec le HTML lui aussi composé de balises. La connaissace de HTML permet de se retrouver sur le terrain familier d'un langage de balise. Mais il peut aussi être source de confusions. En effet, dans le langage HTML chaque balise a son interprétation : <A></A> represente un lien et <B></B> delimite du texte en gras. En XML, rien de tout ça : les balises n'ont pas d'interprétation et <B>mon texte</B> ne représente que mon texte entre deux balises B, en aucun cas du texte en gras ni quelque style particulier que ce soit. Ce n'est que l'application qui traitera le fichier XML qui donnera eventuellement un sens à une balise ( ce qui nous permet d'ailleurs de dire que c'est le navigateur qui interprète la balise B comme délimitant du texte en gras dans un fichier HTML et que le concepteur d'HTML aurait bien evidemment pu choisir une autre solution)

On peut se demander quel est l'interet de XML si les balises ne veulent rien dire. En fait, XML a spécifiquement été établi avec l'intention d'être un format compréhensible par l'homme et la machine. Donc en jetant un coup d'oeil sur notre dernier fichier exemple, on voit du premier coup que ce fichier contient une information sous le nom de contenu, et que ce contenu se subdivise en plusieurs parties, debut, milieu et fin, avec eventuellement de l'information supplémentaire. Cette description est tout ce qu'on recherche. Il est à present aussi facile de demander à quelqu'un d'extraire la fin du contenu que de la faire extraire automatiquement par une application. Et s'il est possible pour une application d'extraire facilement cette information, c'est parce que le XML est defini de façon standard et qu'il existe des outils prêt à réaliser cette tache.

Maintenant que le principe de base est éclairci, nous allons examiner les règles nécessaires pour constituer un document XML

3. Le XML bien formé

La notion de XML bien formé est l'exigence minimale pour un document XML. Si un document n'est pas bien formé, sa lecture par un parseur, qui est le programme de lecture de documents XML, échouera. Il est donc impératif de respecter scrupuleusement les règles qui seront developpés dans ce chapitre.

La première des règle a déja été vue précedemment : toute balise ouverte doit être impérativement fermée. Il est possible de declarer l'ouverture et la fermeture d'une balise en une seule opération dans le cas ou elle ne contient aucun autre élément. Dans ce cas, on écrira la balise sous la forme <vide /> ( notez le / situé après le nom de la balise ). Ce type de balise est similaire à la balise <BR> en HTML qui represente un saut de ligne. En XML, il faudrait donc écrire <BR />. Cette balise est donc vide puisqu'il n'y a aucun espace entre l'ouverture et la fermeture pour ajouter une quelconque information. Par contre, une telle balise peut contenir un ou plusieurs attributs, comme n'importe quelle autre balise.

Les attibuts sont le moyen d'ajouter de l'information à l'interieur même d'une balise sous la forme d'un couple nom / valeur. Le document suivant reprend notre exemple précedent en ajoutant des attributs aux balises debut, milieu et fin. 

  <?xml version="1.0"?>
  <contenu>
    <debut>
      Le debut ici ...
    </debut>
    <milieu importance="essentielle" verification="non">
      Le milieu ici ...
    </milieu>
    <fin importance="nulle">
      La fin ici ...
    </fin>
      Eventuellement, encore quelque chose ici ...
  </contenu>

Notre exemple donne à l'attribut importance de la balise milieu la valeur "essentielle" tandis que pour la balise fin , la valeur de l'attribut est "nulle". De même la valeur de l'attribut verification de la balise milieu vaut "non". De la même façon que les balises n'ont pas de valeur prédefinie, les attributs ne signifient rien par eux-meme, sinon que la balise dont ils font partie possède cet attribut dont la valeur est définie. Par exemple, la valeur "non" de l'attribut verification pourrait signifier que la verification n'a pas été faite, ou qu'elle n'est pas à faire ou autre chose encore. Seule l'application qui traitera ce document pourra éventuellement lui donner un sens.

Du point de vue de la syntaxe, les règles à observer sont :

4. Pratique : verifier automatiquement un document XML

Jusqu'a présent, notre découverte de XML s'est cantonnée à la théorie. Nous allons maintenant tirer profit d'un des avantages de XML en utilisant un des nombreux outils disponible permettant de manipuler les documents. L'outil que nous allons utiliser est un parseur XML, qui permet de parcourir notre fichier et de procéder à quelques traitements. Ce qui nous interesse à notre stade est de verifier que notre document XML est bien formé ce qui signifie que le parseur sera capable de le parcourir entièrement sans rencontrer une seule erreur.

Le parseur que nous allons utiliser se nomme Xerces et est édité par xml.apache.org. Vous pouvez le télécharger à http://xml.apache.org. Là vous avez le choix entre la version Java et C++. Choisissez celle qui vous convient. Xerces est disponible sous forme de binaires pour plusieurs plateforme dans sa version C++, avec laquelle seront decrits les tests dans la suite de cet article. Son installation ne pose aucun problème car il suffit de décompacter l'archive et c'est opérationel.

XERCES_DIR designera le repertoire dans lequel vous aurez decompacté l'archive. Copiez le dernier exemple de fichier XML de cet article dans un fichier test.xml que vous placerez dans le repertoire XERCES_DIR/bin.

Notre premier essai consistera à utiliser le petit utilitaire SAXPrint situé également dans le repertoire XERCES_DIR/bin. Tapez la commande suivante à partir de XERCES_DIR/bin : 

./SAXPrint test.xml

Evidemment, le résultat n'est pas très impressionnant, puisque ce programme se contente de parser (c'est à dire de lire et de verifier le fichier) puis d'imprimer la sortie sur l'écran. Toutefois, la verification a bien eu lieu et le fait que le programme affiche correctement notre fichier signifie qu'il est bien formé.

Un autre essai peut être réalisé avec SAXCount qui donne quelques infomations sur notre document XML. Tapez : 

./SAXCount test.xml

et vous obtiendrez un décompte du nombre de balises, du nombre d'attributs et du nombre de caractères. Notez que le nombre de balises (elements) est de 4. En effet, le parseur a rencontré les balises <contenu>, <debut>, <milieu> et <fin>, ce qui fait effectivement 4 éléments.

A présent je vous propose de modifier un peu notre fichier test.xml. A la place du texte "Le milieu ici" situé entre les balises <milieu> tapez "Le milieu était ici". Le but est d'introduire un caractère accentué français. En reéxecutant SAXPrint test.xml, vous devriez voir que la sortie affichée par le programme ne correspond plus à notre attente en ce qui concerne le caractère accentué. Le problème vient du fait que le parseur ne sait pas que le caractère "é" qu'il a lu correspond à la lettre "e" accentuée française. Pour qu'il le prenne en compte, il faut lui indiquer que nous utilisons l'alphabet Occidental de l'Ouest. Pour cela, il suffit de remplacer la première ligne du fichier test.xml par : 

<?xml version="1.0" encoding="iso8859-1"?>

A présent, la sortie de ./SAXPrint test.xml doit être correcte et les caractères accentués sont imprimés correctement

5. Un petit peu plus loin avec la Définition de Type de Document (DTD)

Nous avons vu un précedement qu'un fichier XML admettais un unique élément racine. Dans notre exemple il s'agissait de l'élément <contenu>. En fait, en plus d'être la racine, cet élément represente le type de document (ce qui explique pourquoi il ne peut y avoir qu'un élément racine, parce que le document ne peut être de plusieurs type à la fois). Pour définir de façon formel le type de notre document, nous allons modifier l'entête de notre fichier de la façon suivante : 

  <?xml version="1.0" encoding="iso8859-1"?>
  <!DOCTYPE contenu>
  <contenu>
  ...
  </contenu>

La définition explicite du type de document est la première étape de la DTD ou Définition du Type de Document (Document Type Definition). La DTD consiste à ajouter des informations à notre fichier XML afin de décrire sa structure. En français, on dirait que le document "contenu" est constitué de 3 éléments : "debut", "milieu" et "fin" et que l'élément milieu à deux attributs "importance" et "verification" et que l'élément fin quant à lui a un attribut "importance". La DTD reviens à faire une description de ce type là suivant une syntaxe très précise apportant toutes les informations nécessaires (par exemple, est ce que l'élément "debut" peut lui aussi avoir des attributs ?)

La manière la plus simple d'intégrer une DTD est de la placer dans notre document. Pour cela il suffit de completer notre definition doctype qui se presente alors de la façon suivant : 

<!DOCTYPE contenu [ (placer la déclaration de DTD ici) ]>

Ce qui nous donnera le fichier XML suivant : 

  <?xml version="1.0" encoding="iso8859-1"?>
  <!DOCTYPE contenu> [
    <!ELEMENT contenu (debut, milieu, fin)>
    <!ELEMENT debut (#PCDATA)>
    <!ELEMENT milieu (#PCDATA)>
    <!ATTLIST milieu
      importance CDATA #IMPLIED
      verification CDATA #IMPLIED>
    <!ELEMENT fin (#PCDATA)>
    <!ATTLIST fin
      importance CDATA #IMPLIED
      verification CDATA #IMPLIED>
 ]>
  <contenu>
    <debut>
      Le debut ici ...
    </debut>
    <milieu importance="essentielle" verification="non">
      Le milieu ici ...
    </milieu>
    <fin importance="nulle">
      La fin ici ...
    </fin>
      Eventuellement, encore quelque chose ici ....
  </contenu>

Les définitions de DTD ont un aspect rebutant de prime abord, mais en fait il sont très simple à comprendre. Nous allons dans la liste qui suit reprendre ligne après ligne la signification de ce charabia :

A partir de là la structure de notre document est définie. Il est possible d'utiliser nos petits programmes de la section précedente pour vérifier notre document XML. 

./SAXPrint test.xml

Si le parseur ne déclanche pas d'erreur, notre document XML sera dit valide ( Xerces est en effet un parseur dit validateur parce qu'il controle la structure du document XML par rapport à la DTD). Si vous utilisez un parseur non-validateur, vous ne pourrez que vérifier que votre document est bien formé, mais pas qu'il est valide. Dans nos exemple de la section précedente, le parseur ne renvoyait pas d'erreur parce qu'aucune DTD n'était présente. Notre document n'était pas valide pour autant puisque la notion de validité est indissociablement liée à la notion de DTD. A présent, SAXPrint renverra une erreur si :

Il est possible de modifier le fichier test.xml pour vérifier que le parseur signale effectivement une erreur lorsqu'un de ces cas est rencontré.

6. Et ensuite ...?

A présent les bases de XML sont éclaircies mais l'interet n'est toujours pas evident. Pour l'instant un document XML n'est qu'un document texte possédant certaines caractéristiques de formatages et qui peut eventuellement controler sa propre structure. Les veritables avantages sont constitués par les outils disponibles et les autres recommendations XML.