Le but de ce cours est de vous présentez assez sérieusement le langage XML (eXtensible Markup Language). Comme nous allons le voir, XML est un langage très général qui n'a pas pour but de replacer le langage HTML, mais plutôt d'être complémentaire à ce dernier. En effet, XML n'est pas un langage de présentation de document en tant que tel.

On pourrait plutôt qualifier XML de meta-langage : en effet on peut difficilement exploiter XML tel quel : il faut en spécifier un sous-ensemble sur lequel on pourra travailler. Pour exploiter un sous ensemble de tag XML, on peut utiliser une DTD (Document Type Definition) et des feuilles de styles. On pourrait presque dire que HTML est un sous ensemble XML (quelques règles de syntaxe, non significatives, du langage HTML sont à revoir pour être compatibles avec celles du langage XML).

Nous allons donc, dans ce cours, apprendre la syntaxe XML (cela constitue la partie la plus simple de ce cours). Ensuite, nous irons voir ce qu'est un document de validation (les DTD et les schemas). Nous parlerons aussi de feuilles de styles (Cascading Style Sheet, eXstensible Stylesheet Language). Nous verrons aussi ce qu'il est possible de faire avec les langages de programmation et XML.

Il faut aussi savoir que l'un de but recherché par XML est de pouvoir échanger, via le Web, des données stockées dans des bases de données. Nous nous attarderons donc sur ce point pour voir ce qu'il est actuellement possible de faire dans ce domaine.

Historique

Dès le débuts des années 90, le CERN (Centre Européen de Recherche Nucléaire) rend public le projet World Wide Web. Ce projet consistait à définir un langage de présentation de documents hypertextes (HTML - HyperText Markup Language), ainsi qu'un protocole de transfert pour ces documents (HTTP - HyperText Transfert Protocol). Une fois ces deux technologies définies, on put passer à la réalisation d'outils permettant réellement cet échange d'informations (un navigateur Web et un serveur HTTP). On peut aujourd'hui dire que ce projet fut un véritable succès : qu'il n'a pas encore entendu parler du Web, d'HTML, d'HTTP ou encore de navigateurs Web ?

HTTP (Hypertext Transfert Protocol) est un protocole de transfert de document hypertextes. Initialement, HTTP fut conçut pour l'échange de documents HTML. Mais comme nous allons le voir plus loin, ce protocole à encore de bonne années devant lui.

HTML (Hypertexte Markup Language) est un langage de description de documents hypertextes. Ce langage est basé sur une syntaxe de balisage très simple. Pour de plus amples informations sur HTML, vous pouvez consulter le cours sur le langage HTML. Il est clair que depuis sa première version, ce langage à bien évolué : on en est actuellement à la version 4.01. Cependant, il est clair qu'il existe de nombreux problèmes (non forcément complexes) auxquels ce langage ne sait pas palier. Il est clair que les langages de script (Javascript ou VBScript) peuvent aider à contourner certains problèmes, mais il ne s'agit pas, en soit, d'une solution satisfaisante.

Un des nombreux problèmes rencontré par HTML, tient dans le fait que depuis sa première version, le langage ne sais pas séparer la partie structuration du document (definition des titre, des paragraphes, des listes, ...) de sa présentation. La présentation (comment doit t'on afficher les données du document) est noyée dans le document. Cela impose de grosses difficultés pour refondre un site Web constitués de nombreux documents. Pour cet aspect là, il est vrai que depuis la version 4.0 du langage HTML, de nombreuses choses ont été dépréciées au profit des feuilles de styles CSS. Cependant, d'autres problèmes persistent encore en HTML.

Il a donc fallut commencer à réfléchir à une solution non pas de replacement, mais complémentaire. C'est le W3C qui a cherché à proposer un standard accepté et utilisé de tous. Cette solution doit pouvoir permettre de transférer des données sur le Web, sans devoir refaire un protocole de communication, et sans forcément avoir de grosses modifications à apporter aux outils utilisés (comme nous le confirmerons, un serveur normal peut envoyées des données XML via HTTP).

Si vous voulez tout savoir, en vérité, HTML est un langage dérivé de SGML (Standard Generalized Markup Language), qui est un langage utilisé, par exemple, dans des sociétés d'édition. SGML est un langage basé sur la notion de marque (de tag) pour organiser les données contenu dans les document, tout comme HTML. Ce langage est bien plus puissant que ne l'est HTML, mais il est aussi, bien trop complexe pour une utilisation dans le cadre du Web. Le W3C s'est donc orienté vers une solution intermédiaire, d'où la naissance de XML.

Le World Wide Web Consortium (W3C)

Le W3C (World Wide Web Consortium) est une association à buts non lucratifs, visant à uniformiser les langages et les technologies utilisés sur le Web. Attention, le W3C n'est pas un organisme de normalisation. Il ne définit pas des normes, mais des recommandations. On peut malgré tout dire que ces recommandations sont considérées comme des standards de fait (tous le monde, et notamment les constructeurs de navigateurs s'y conforment, plus ou moins rapidement).

Le W3C propose notamment des recommandations sur HTML, CSS, le DOM (Document Object Model), ..., et bien entendu XML. Donc pour avoir plus d'informations à propos de ces différents langages, vous pouvez donc consulter les recommandations du W3C, qui sont accessible via le Web. Pour accéder au site du W3C, il vous suffit de saisir l'URL suivante dans votre navigateur préféré.

http://www.w3c.org

Plus haut, je vous parlai de sous-ensembles XML que l'on peut exploiter. Deux exemples concrets sont, entre autres, définis par le W3C. Il s'agit MathML (Mathématique Modeling Language) et de SMIL (Synchronized Multimédia Integration Language). Jettez, éventuellement un coup d'œil sur ces deux recommandations.

Votre premier document XML

Nous allons, dans ce chapitre, étudier notre premier document XML. L'objectif étant de voir comment ce dernier est constitué : en effet, un document XML est constitué de plusieurs fichiers et notamment, un fichier de données, un fichier de validation et une feuille de styles.

L'exemple que nous allons étudier est réellement utilisé sur le site d'un centre de formation : Evolution Multimédia. Notons au passage que je travaille dans ce centre de formation depuis 1998. Un tel centre présente des informations bien précisent : des plans de formation. Il est aussi à notez qu'Evolution ne dispense pas que quelques formations, mais au contraire, plus d'une centaine (Je vous renvoi, à ce sujet, sur le site du centre de formation).

Il a donc été nécessaire pour nous de trouver une technologie qui nous permette de facilement présenter ces plans de cours, tout en garantissant que nous puissions changer la mise en page de ces plans de cours sans forcément devoir retoucher l'intégralité des plans de cours. XML s'est donc imposé à nous, et nous avons, à partir de ce dernier, définit notre propre langage de présentation de plan de cours : appelons le FML (Formation Markup Language).

Pour pouvoir poursuivre la lecture de ce chapitre, je vous convie à télécharger le fichier zip suivant : il contient tous les fichiers dont nous allons parler dans la suite de ce chapitre. Notez que ce mini projet à été mit en oeuvre via l'outil XmlSpy que vous pouvez aussi télécharger à partir de l'adresse suivante : http://www.xmlspy.com. Cet outil est à mon sens l'un des meilleurs du moment en terme d'édition de documents XML. Sachez aussi que pour l'heure, seul Internet Explorer 5.5 (ou supérieur) permet de correctement visualiser des documents XML.

Présentation du langage FML

Un plan de formation est quelque chose d'un peu complexe. En effet, une formation durera un certain nombre de jours - il faut un certain nombre de pré-requis pour suivre une formation - il faut connaître les objectifs à atteindre durant la formation. De plus le plan de la formation définit les différents chapitres qui vont être étudiés.

Utiliser un langage de balisage est une bonne chose dans notre cas. Cela permettra de structurer les données qui constituent le plan de cours. Mais une question apparaît : quels tags utiliser ? En fait XML ne spécifie aucun tag. C'est à vous de définir votre propre langage. Dit autrement, XML fournit une syntaxe mais c'est à vous de définir une grammaire. Nous reviendrons sur cet aspect ultérieurement dans ce chapitre, mais nous pouvons dès à présent choisir les noms des tags que nous allons utiliser.

L'exemple suivant vous montre un extrait d'un fichier de données utilisant notre langage FML. Il s'agit d'un plan de cours (partiel), mais il peut bien entendu y avoir autant d'autres fichiers que nécessaire. Quelques explications suivent cet exemple.

<?xml version="1.0" encoding="ISO-8859-1"?>

<?xml:stylesheet type="text/xsl" href="Formation.xsl" ?>

<!DOCTYPE FORMATION SYSTEM "Formation.dtd">

<FORMATION>

    <TITRE>Visual Basic 6.0 (Niv 1 - Fr)</TITRE>

    <DUREE>5</DUREE>

    <PREREQUIS>

        Une expérience de la programmation est vivement conseillée.

    </PREREQUIS>

    <OBJECTIF>

        Etre capable de programmer des applications en utilisant

        le langage et l'environnement Visual Basic Enterprise.

    </OBJECTIF>

    <CONTENU>

        <CHAPITRE>

            <TITRE>

               Introduction au développement d'applications

               à l'aide de Visual Basic 6.0

            </TITRE>

            <SECTION>Fonctionnalités de Visual Basic</SECTION>

            <SECTION>Éditions de Visual Basic</SECTION>

            <!-- La suite du chapitre -->

        </CHAPITRE>

        <CHAPITRE>

            <TITRE>Visual Basic - Notions fondamentales </TITRE>

            <SECTION>Introduction aux objets</SECTION>

            <!-- La suite du chapitre -->

        </CHAPITRE>

        <!-- Les autres chapitres -->

    </CONTENU>

    <ANIMATEUR>Dominique LIARD</ANIMATEUR>

    <ANIMATEUR>Olivier ASTRE</ANIMATEUR>

</FORMATION>

Comme vous pouvez le voir, tous les noms de tags sont en français. C'est donc clair, ce n'est pas du prédefini (sans quoi ça aurait certainement été écrit en anglais). C'est moi qui ai décidé d'appeler ainsi mes tags. Une formation (tag FORMATION) est donc constituée d'un titre (tag TITRE), puis d'une durée (tag DUREE), et ainsi de suite.

Si vous regardez attentivement les premières lignes du fichier de données, vous constaterez qu'il se lie à deux autres fichiers : "formation.dtd" et "formation.xsl". Ils servent, respectivement, à définir la grammaire (comment correctement utiliser les tags) de notre langage et à permettre une mise en page d'un fichier de données. Revenons plus en détails sur chacun de ces fichiers.

Mise en oeuvre et intérêt d'une grammaire

Pour définir un langage balisé, il ne suffit pas de simplement choisir quelques noms de tags ! En effet, si l'on considère le langage HTML (à titre d'exemple), un tag <TD> (Table Data) ne peut pas s'utiliser n'importe ou. Une cellule de données TD doit être contenue dans une ligne de tableau <TR> (Table Row) qui doit elle même être contenue dans un tag <TABLE>. Il y a bien une grammaire HTML.

Définition de la grammaire FML

Pour vos langages, il doit en être de même. Pour ce faire, deux principaux mécanismes vous sont offerts. Le premier (historiquement parlant) consiste à définir une DTD (Document Type Definition). Le second consiste à utiliser un schema (un fichier XML de définition de grammaire). Dans notre exemple, étant donnée sa simplicité, c'est une DTD qui est utilisée. Le tableau suivant vous montre le contenu de cette DTD.

<!ELEMENT FORMATION (TITRE, DUREE, PREREQUIS, OBJECTIF, CONTENU, ANIMATEUR+)>

<!ELEMENT CONTENU (CHAPITRE)*>

<!ELEMENT CHAPITRE (TITRE, SECTION*)>

<!ELEMENT TITRE (#PCDATA)>

<!ELEMENT DUREE (#PCDATA)>

<!ELEMENT PREREQUIS (#PCDATA)>

<!ELEMENT OBJECTIF (#PCDATA)>

<!ELEMENT SECTION (#PCDATA)>

<!ELEMENT ANIMATEUR (#PCDATA)>

Notre langage FML définit neuf tags. En conséquence, notre DTD contient au moins neuf lignes. Ici, une ligne par tag. Pour les six dernières règles, elles indiquent que ces tags ne peuvent que contenir des données textuelles (#PCDATA - Parsed Character Data). Les trois autres sont un peu plus complexes.

La première définition indique ce que le tag racine (<FORMATION>) va contenir un titre (et obligatoirement un), puis une durée, un pré-requis, un objectif, un contenu et des animateurs (un ou plus). Mais le contenu est lui même composé. Il peut contenir un nombre quelconque de chapitre (0 ou plus). Un chapitre étant constitué d'un titre et d'autant de sections que nécessaire.

Validation d'un fichier de données

Vous pouvez utiliser des outils de validation, pour vérifier qu'un document de données et bien conforme à la grammaire (DTD ou Schema) du langage. Sous environnement Windows, Microsoft fournit des outils de validation : personnellement, j'utilise un outil nommé "xmlint.exe".

Le tableau suivant vous affiche quelques résultats obtenus par l'outil "xmlint.exe". Le premier test de validation à été effectué avec un fichier de données en accord avec la DTD : rien ne s'affiche. Le deuxième test à été effectué en permuttant les tags <TITRE> et <DUREE> dans le fichier de données : l'outil n'arrive donc pas à valider le fichier et affiche un message d'erreur. Enfin, le troisième test à été lancé en supprimant du fichier de données le tag <CONTENU> : encore une fois, la validation ne peut aboutir. Analyser bien les messages d'erreurs affichés par l'outil.

C:\Documents and Settings\Administrator\Desktop\FmlSample>dir

 Volume in drive C has no label.

 Volume Serial Number is 38DF-5396

 Directory of C:\Documents and Settings\Administrator\Desktop\FmlSample

22/12/2002  17:18    <DIR>          .

22/12/2002  17:18    <DIR>          ..

27/03/2001  03:32               534 Formation.css

22/12/2002  21:43               333 Formation.dtd

24/05/2002  05:53               731 Formation.spp

22/12/2002  18:08             2 351 Formation.xsl

22/12/2002  17:33    <DIR>          Images

16/12/2002  01:18            17 094 V-Basic1.html

22/12/2002  20:35             7 508 V-Basic1.xml

16/12/2002  01:18            11 154 V-Basic2.html

22/05/2002  03:59             4 357 V-Basic2.xml

26/03/2001  11:54               100 XmlToHtml.bat

               9 File(s)         44 162 bytes

               3 Dir(s)   7 405 457 408 bytes free

C:\Documents and Settings\Administrator\Desktop\FmlSample>xmlint V-Basic1.xml

V-Basic1.xml

C:\Documents and Settings\Administrator\Desktop\FmlSample>xmlint V-Basic1.xml

V-Basic1.xml

        Element content is invalid according to the DTD/Schema.

Expecting: TITRE.

        URL: file:///C:/Documents%20and%20Settings/Administrator/Desktop/FmlSamp

le/V-Basic1.xml

        Line 00005:  <DUREE>5</DUREE>

        Pos  00009: --------^

C:\Documents and Settings\Administrator\Desktop\FmlSample>xmlint V-Basic1.xml

V-Basic1.xml

        Element content is invalid according to the DTD/Schema.

Expecting: OBJECTIF.

        URL: file:///C:/Documents%20and%20Settings/Administrator/Desktop/FmlSamp

le/V-Basic1.xml

        Line 00010:  <CONTENU>

        Pos  00011: ----------^

C:\Documents and Settings\Administrator\Desktop\FmlSample>

Notez pour le moment, que la validation de la grammaire n'est pas une étape obligatoire pour pouvoir présenter un document. Nous reviendrons ultérieurement, dans les chapitres suivants, sur cette notion de grammaire XML. Nous étudierons en détails comment écrire une DTD, mais aussi comment écrire un schema.

Mise en page d'un plan de cours

Il vous faut bien comprendre une chose : les tags dont nous avons parlé dans FML on été choisis par nos soins. Comment le navigateur pourrait t'il les connaître ? Tout comme il nous a fallut spécifier qu'elles étaient les règles d'imbrications des tags, il va nous falloir définir comment chaque tag va se présenter.

Aspects généraux

Si nous ne spécifions rien, le navigateur ne saura pas quoi faire. Par défaut, Internet Explorer se contente simplement d'afficher le fichier XML en question. Pour testez la chose, il vous suffit simplement de supprimer la deuxième ligne du fichier de données XML (celle qui lie la feuille de style XSL) et d'afficher ce document dans le navigateur. La capture d'écran suivante vous montre le résultat.

Il est clair que si on laisse les choses ainsi, nous risquons de ne pas remporter un franc succès. Il est préférable d'ajouter une feuille de style. Pour ce faire, il suffit d'ajouter la ligne suivante dans le prologue (en deuxième ligne dans la partie supérieure) des fichiers XML.

<?xml:stylesheet type="text/xsl" href="Formation.xsl" ?>

Cette ligne d'affectation de feuille de styles contient principalement deux parties. La première indique le langage de feuille de style utilisé. En effet, vous avez deux langages potentiellement utilisables avec XML : CSS (Cascading StyleSheet) et XSL (eXtensible Markup Language). Dans notre exemple, c'est une feuille de style XSL qui est utilisée. La deuxième information à fournir est la localisation du fichier de style (href signifiant Hypertext REFerence). La capture d'écran suivante montre le même fichier que précédemment, mais auquel on a appliqué une feuille de styles.

Introduction aux feuilles de styles XSL

Si l'on regarde bien les possibilités d'affichage d'un navigateur, on peut dire qu'elles se limitent aux possibilités inhérentes au HTML. Cela est suffisant au mécansime XSL pour pouvoir présenter un document XML

L'acronyme XSL signifie eXtensible Markup Language. Il est vrai que si l'on cherche à comprendre comment fonctionne XSL, on a du mal à comprendre le qualificatif de Stylesheet (feuille de styles). En effet, on peut plus comparer XSL au pré-processeur du langage C qu'à un mécanisme de feuilles de styles.

Pour s'en convraincre, regardons de plus près comment XSL fonctionne. En fait on parle du moteur de transformation XSL (le véritable nom de la recommandation du W3C étant XSLT). Ce moteur est un outil qui prend en entrée deux fichiers (un fichier de données XML et un fichier de règles XSL) et qui en sortie, aprés de multiples transformations, renvoie un autre fichier XML. Le diagramme suivant schématise ce fonctionnement.

Le fichier de règles XSL est constitué de différentes règles. Dans le cas le plus simpliste, chaque règle correspond à un nom de tags dans le fichier de données d'entrées. A titre d'exemple, voici un extrait de la feuille de style qui montre comment afficher les différents chapitres et leurs contenus. Les couleurs utilisées permettent, ici, de mettre en évidence ce qui correspond au fichier de données d'entrée et ce qui correspond à celui de sortie.

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

    <xsl:output encoding="ISO-8859-1"/>

    <!-- Toutes les autres règles de la feuille de styles -->

    <xsl:template match="CHAPITRE">

        <H2><xsl:value-of select="./TITRE"/></H2>

        <UL>

            <xsl:apply-templates select="./SECTION"/>

        </UL>

    </xsl:template>

    <xsl:template match="SECTION">

        <LI><xsl:value-of select="."/></LI>

    </xsl:template>

</xsl:stylesheet>

Légende

        Rouge : permet de filtrer les tags du fichier d'entrée

                pour lesquels la règle s'applique.

        Bleu (clair) : permet, pour le tag considéré, de dire ce

                qu'on lui associe dans le fichier de sortie.

Comme vous l'avez constaté, en sortie, le moteur de transformation XSL produit du HTML que le navigateur saura afficher. Mais comprenez bien que la génération de tag HTML n'est pas une obligation, vous pouvez utiliser le moteur de transformation pour passer d'un langage XML à un autre langage XML. Vous renviendrons dans les chapitres ultérieurs, plus dans le détail sur XSL.

Où opérer la transformation ?

Dans le cadre du Web, il vous faut choisir ou réaliser l'application de la feuille de style (la transformation XSL). Deux possibilités s'offrent à vous : soit c'est le navigateur qui réalise l'opération, soit c'est le serveur Web. Dans les deux cas, il y a des avantages et des inconvénients.

Application coté navigateur

L'application de la feuille de styles (dit autrement, la génération du fichier de sortie) est un processus qui peut prendre un certain temps. Réaliser cette transformation par l'intermédiaire du navigateur amènne donc à sérieusement réduire l'activité du serveur web.

Tant que cela est possible, préferrez faire travailler le navigateur dans le sens ou les traitements sont répartis. La principale problèmatique réside dans le fait que les navigateurs ne supporte pas tous les technologies XML. Essayez d'afficher un document XML dans un Netscape : vous serez surpris. Et oui, il ne sais pas réaliser l'application de la feuille de styles.

Par défaut, l'application de la XSL est malgré tout faite par le navigateur, dès lors que vous avez ajouté le tag <?xml:stylesheet ... ?> dans votre document.

Application coté serveur

La seconde altérnative consiste à appliquer la feuille de style sur le serveur Web. Ainsi, vous n'avez qu'à garantir que le serveur Web sache prendre en charge les technologies XML, les différents clients ne recevant alors plus que du HTML. Deux sous alternatives sont alors à prendre en compte : soit le fichier à un contenu statique, soit chaque requête HTTP peut ammener à recevoir des données différentes.

Si le contenu des documents ne change pas, ce qui est d'ailleurs le cas avec nos plans de cours, vous pouvez alors faire l'application une fois pour toute est stoker les fichiers HTML sur le serveur Web. Si vous regardez dans le fichier ZIP, vous y trouverez un fichier "XmlToHtml.bat". Il utilise l'outil msxsl.exe (fournit par Microsoft) pour générer le fichier HTML à partir du fichier XML de données.

Si au contraire le contenu d'un flux de données XML peut changer d'une requête HTTP à une autre (par exemple, par ce qu'il est généré à partir d'une base de données), il faut alors garantir que la transformation sera réalisée à chaque requête. Pour ce faire, vous pouvez utiliser un mécanisme de génération de page Web dynamique (PHP, ASP, ASP.NET, Servlets ou JSP, ...). L'exemple suivant vous montre un code ASP.NET réalisant la transformation.

using System;

using System.Collections;

using System.ComponentModel;

using System.Data;

using System.Data.SqlClient;

using System.Drawing;

using System.Web;

using System.Web.SessionState;

using System.Web.UI;

using System.Web.UI.WebControls;

using System.Web.UI.HtmlControls;

using System.Xml;

using System.Xml.Xsl;

namespace CaddieVirtuel {

    public class Caddie : System.Web.UI.Page {

        protected System.Data.SqlClient.SqlConnection sqlConnection1;

        protected System.Data.SqlClient.SqlCommand sqlCommand1;

        protected System.Data.SqlClient.SqlDataReader reader;

        private void Page_Load(object sender, System.EventArgs e) {

            /* Ouverture de la connexion à la base de données */

            this.sqlConnection1.Open();

            this.sqlCommand1.Parameters["@id"].Value = this.Request.QueryString["id"];

            this.reader = this.sqlCommand1.ExecuteReader();

            /* Génération de la réponse HTTP. Vous avez le choix pour

             * où appliquer la feuille de style XSL */

            this.applyServerSide();

            /* Fermeture de la connexion à la base de données */

            this.reader.Close();

            this.sqlConnection1.Close();

            /* On termine la réponse HTTP */

            this.Response.End();

        public void applyServerSide() {

            this.Response.ContentType = "text/html";

            String xml = "<?xml version='1.0' encoding='ISO-8859-1' ?>";

            while(this.reader.Read()) {

                xml += "<Article>";

               xml += "    <IdArticle>" + reader.GetInt32(0) + "</IdArticle>";

               xml += "    <Designation>" + reader.GetString(1) + "</Designation>";

               xml += "    <Marque>" + reader.GetString(2) + "</Marque>";

               xml += "    <PrixUnitaire>" + reader.GetDouble(3) + "</PrixUnitaire>";

               xml += "</Article>";

            XslTransform xslt = new XslTransform();

            xslt.Load(this.Server.MapPath(".") + "\\" + "Domi.xsl");

            XmlDocument doc = new XmlDocument();

            doc.LoadXml(xml);

            xslt.Transform(doc, null, this.Response.Output);

        public void applyClientSide() {

            this.Response.ContentType = "text/xml";

            while(this.reader.Read()) {

               Response.Write("<?xml version='1.0' encoding='ISO-8859-1' ?>");

               Response.Write("<?xml:stylesheet type='text/xsl' href='Domi.xsl' ?>");

               Response.Write("<Article>");

               Response.Write("    <IdArticle>" + reader.GetInt32(0));

                Response.Write("    </IdArticle>");

               Response.Write("    <Designation>" + reader.GetString(1));

                Response.Write("    </Designation>");

               Response.Write("    <Marque>" + reader.GetString(2) + "</Marque>");

               Response.Write("    <PrixUnitaire>" + reader.GetDouble(3));

                Response.Write("    </PrixUnitaire>");

               Response.Write("</Article>");

        Web Form Designer generated code

Dans ces deux sous cas, notez aussi qu'un autre inconvénients peut être signalé, comparé à une transformation coté navigateur. Un flux de données XML prend généralement moins de place qu'un flux HTML. En effet, les données XML sont décorellées de tous aspects visuels : il a donc moins de texte à transférer par le réseaux.

Conclusion

Nous avons donc, dans ce chapitre, étudié notre premier langage XML. En effet, le différentes recommandations du W3C, estampillées du mot XML, permettent de définir un langage de balisage adapté à vos besoins.

Pour ce faire, il vous faut définir une grammaire, spécifiant comment correctement utiliser les tags de votre langages. Des outils de validations de grammaire vous sont même fournis. Deux sous langages vous permettent de définir une grammaire : une DTD (Document Type Definition) ou un Schema (qui est lui même une grammaire XML bien définie).

Accessoirement, vous pouvez adjoindre une feuille de styles à votre langage, cela vous permettant de présenter vos données. Encore une fois, deux langages sont utilisables : CSS (Cascading StyleSheet) et XSL (eXtensible Stylesheet Language). Ce dernier (lui aussi est basé sur une grammaire XML déterminée) étant bien plus puissant que CSS.

Dans le chapitre suivant mous allons nous intéresser de plus prés non pas à la définition d'un grammaire XML, mais sur la syntaxe XML. En effet, la recommandation XML, à proprement parler, définit uniquement les aspects de syntaxe pour que vos fichiers de données soient "bien formés".

Les règles de syntaxe XML

Nous allons, dans ce chapitre, étudier la syntaxe du langage XML. En effet, un fichier XML utilise des tags pour structurer ses données. Différentes règles existent pour régirent l'utilisation de ces tags. Nous allons donc les présenter une par une.

Nous parlerons aussi de certains autres aspects inhérent à la mise en oeuvre d'un document XML. Et notamment : la notion de prologue, celle de namespaces ainsi que tout ce qui à attrait au tables de codage de caractères.

La notion de tags XML

A l'instar d'HTML, le langage XML utilise aussi des tags (on parle aussi, en français, de marques ou de balises). Un tag est facilement reconnaissable étant donné qu'il commence par le caractère < et qu'il se termine par le caractère >. Mais cette simple définition ne suffit pas à définir XML. En effet, les choses sont un peu plus complexes : c'est ce que nous allons développer dans cette section.

Les règles syntaxiques élémentaires

Premièrement, sachez qu'il y a une distinction entre les tags ouvrant et les tags fermant. Si nous reprenons l'exemple du langage FML (vu dans le chapitre précédent), le tag <CHAPITRE> est un tag ouvrant alors que le tag </CHAPITRE> est un tag fermant. Un tag fermant commence par les deux caractères </.

Tout tag ouvrant doit obligatoirement être fermé plus loin dans le fichier. Pour une personne qui à l'habitude d'HTML, cette règle est nouvelle. En effet en HTML, un tag peut ne pas être fermé : par exemple le tag <HR> (Horizontal Rule), qui permet de tracer une ligne horizontale de séparation, n'a pas de tag fermant. En XML, il en va autrement : si le fichier est syntaxiquement incorrect, le traitement du fichier aboutira à une erreur. La capture d'écran suivante montre le cas d'un fichier XML contenant un tag non fermé qui serait affiché dans Internet Explorer.

Il existe cependant une forme plus compacte pour représenter un couple de tags XML ne contenant pas de données. Il suffit du fournir un unique tag commençant par le caractère < et se terminant par les caractères /> (cette fois-ci, le slash (/) est positionné à la fin du tag). Ce tag est lors à la fois ouvrant et fermant. Les deux lignes suivantes sont syntaxiquement équivalente si l'on considère avoir utilité d'un tag <DATE> prenant trois attributs.

<DATE Jour="26" Mois="08" Année="1973"></DATE>

<DATE Jour="26" Mois="08" Année="1973" />

Secundo, XML fait une distinction entre les lettres minuscules et les lettres majuscules. Encore un fois, l'expert HTML devra s'adapter à cette nouvelle règle, dans le sens ou HTML ne fait pas la distinction entre ces deux types de lettres. Les exemples suivants sont tous, syntaxiquement, incorrects. Si vous affichez un tel document dans IE, un message d'erreur vous sera retourné.

<DATE Jour="26" Mois="08" Année="1973"></date>

<Date Jour="26" Mois="08" Année="1973"></date>

<DaTe Jour="26" Mois="08" Année="1973"></dAtE>

En dernier lieu, notez que vous ne pouvez pas choisir n'importe quoi comme nom de tags. Certes, XML ne définit aucun tag, mais vos noms ne doivent pas commencer par le mot xml (en minuscules). Ainsi, au cas ou dans l'avenir, un quelconque tag doit être défini, au niveau de la recommandation XML (aujourd'hui en version 1.0), il commencera par ce préfixe.

Hormis cette règle, vous pouvez opter pour le nom de votre choix en sachant que ce dernier ne devra contenir que des lettres, des chiffres, et les caractères - (trait d'union), _ (underscore), . (le point) et : (deux points). Sachez, en outre, que ce dernier caractère a une signification particulière (introduction d'un namespace, nous en reparlerons) et que vos noms ne peuvent commencer que par un underscore ou une lettre.

Imbrication des tags XML

Une règles importante à garder à l'esprit est la règle d'imbrication des tags. Vous ne pouvez pas utiliser les tags n'importe comment les uns par rapports aux autres. Nous savons déjà que tout tag ouvrant doit avoir un tag fermant lui correspondant. Mais cela ne suffit pas.

Vos tags ne devrons en aucun cas se chevaucher, sans quoi le document ne sera pas syntaxiquement correcte. L'exemple suivant n'est donc pas correcte.

<TAG-PARENT>

    <TAG-ENFANT>

</TAG-PARENT>

    </TAG-ENFANT>

Vos tags se doivent obligatoirement d'être imbriqués les uns dans les autres. Au contraire de l'exemple précédent, celui qui suit est syntaxiquement correcte.

<DATE>

    <JOUR>26</JOUR>

    <MOIS>08</MOIS>

    <ANNEE>1973</ANNEE>

</DATE>

Enfin, sachez que tout document XML, doit et ne peut avoir qu'un seul tag racine. Tous les autres tags du document se devront d'être contenus dans le tag racine. L'exemple qui suit est encore une fois incorrecte.

<?xml version="1.0" ?>

<TAG-RACINE>

    <!-- Contenu du tag -->

</TAG-RACINE>

<AUTRE-TAG-RACINE>

    <!-- Contenu du tag -->

</AUTRE-TAG-RACINE>

Les commentaires en XML

Vous pouvez, en XML, injecter un (ou plusieurs) commentaire(s) dans vos fichiers XML. En fait, on introduit un commentaire de la même façon qu'en HTML. A savoir, tout commentaire commence par la séquence de caractères . Ceux d'entre vous qui ont étudiés le chapitre précédent auront déjà été familiarisés avec cela.

Attention toute fois à ceux qui ont l'habitude du langage HTML. En effet, en HTML, tout tag non reconnu et purement et simplement ignoré. Certains ont donc pris la mauvaise habitude de commenter leurs fichiers en utilisant une construction de type <! commentaire >. Cela ne marche absolument pas en XML ! Une erreur sera renvoyée à qui utilisera une telle construction. Si c'est ce que vous faisiez, je ne peux que vous conseiller de changer vos habitudes (même en HTML).

L'exemple suivant vous montre un exemple de commentaires en tête d'un fichier XML.

<!--                                               -->

<!-- Plan de cours sur le langage Visual Basic 6.0 -->

<!--                                               -->

<?xml version="1.0" encoding="ISO-8859-1"?>

<?xml:stylesheet type="text/xsl" href="Formation.xsl" ?>

<!DOCTYPE FORMATION SYSTEM "Formation.dtd">

<FORMATION>

        <TITRE>Visual Basic 6.0 (Niv 1 - Fr)</TITRE>

        <DUREE>5</DUREE>

        <!-- Suite du document -->

</FORMATION>

Une possibilité intéressante est à noter : vous pouvez mettre en commentaire un ensemble de tags. Syntaxiquement cela ne pose aucun problème étant donné que le commentaire se termine par la séquence --> : la fin d'un tag embarqué dans le commentaire ne le termine donc pas.

<?xml version="1.0" ?>

<EXEMPLE>

    <!--

    <DATE>

        <JOUR>26</JOUR>

        <MOIS>08</MOIS>

        <ANNEE>1973</ANNEE>

    </DATE>

-->

</EXEMPLE>

Quelques bonnes pratiques

Le choix des tags pour définir un langage, n'est pas forcément trivial. De plus, on peut parfois exprimer des choses similaires via plusieurs structures différentes. En conséquence, il faut faire en sorte de choisir les alternatives les plus adaptées à vos besoins : Facile à énoncer, mais plus délicats à réaliser. Voici donc quelques conseils utiles à retenir.

En premier lieu, opter pour des nom de tags clairs et explicites, même s'ils sont plus long à saisir. Les choses n'en seront que plus lisibles : ⁽¹⁾ à titre d'exemple, que veut dire <UL> en HTML ? En outre, c'est plus "mémo technique" : les utilisateurs retiendront plus vite les tags de votre langage.

Ensuite, réfléchissez bien à ce que vous devez faire des données comprises dans vos tags. Le choix de votre structure peut influer sur la suite des choses (comment récupérer les données dans une feuille de styles, par exemple). A titre d'exemple, regardez les deux propositions suivantes et dites moi laquelle est la meilleur ?

<DATE>26/08/1973</DATE>

ou

<DATE>

    <JOUR>26</JOUR>

    <MOIS>08</MOIS>

    <ANNEE>1973</ANNEE>

</DATE>

En fait, il n'y a pas de meilleur solution dans l'absolu. Le choix dépendra de ce que vous voulez faire de vos dates. Mais si vous souhaitez les afficher tantôt d'une manière tantôt d'une autre, la seconde alternative est préférable. On pourra très simplement dissocier le jour du mois et de l'année. De plus le caractère de séparation n'est pas imposé dans la seconde alternative.

Même si ces discussions vous semblent secondaires, comprenez bien que c'est ce genre de choix qui fera la qualité de votre langage.

Les attributs de tags

Si vous avez été, jusque là, très attentif, vous avez du voir qu'un tag pouvez aussi posséder des attributs. Ceux d'entre vous qui connaissent déjà HTML en ont l'habitude. Par exemple, la tag <TABLE>, permettant d'introduire un tableau dans le document, accepte un bon nombre d'attributs parmis lesquels : Border, CellSpacing, CellPadding, ...

En XML, les mêmes possibilités vous sont offertes. La syntaxe est la même que celle du langage HTML. Faites attention à ne pas utiliser les attributs de tags à tors et à travers. Ce sont ces points que nous allons maintenant développer.

Syntaxe générale

Les différents attributs d'un tag sont obligatoirement fournis à la suite du nom du tag. Chaque élément (le nom du tag et le différents attributs) devant au moins être séparé des autres par un espace.

Un attribut de tag est constitué de deux parties : un nom et une valeur. La valeur doit être comprise soit entre des simples quottes soit entre des doubles guillemets. De plus, le nom est séparé de la valeur par le signe d'égalité.

<TagName attribut1="valeur1" attribut2='valeur2'>

    Donnée du tag

</TagName>

De la bonne utilisation des attributs de tags

Souvent, vous serrez amené à faire des choix : certaines informations pourront être stockées soit sous forme de valeur d'attributs, soit sous forme de données de sous-tags. Le choix n'est pas toujours triviales. Pour vous en convaincre, analysez les deux exemples suivants : dans les deux cas, la date est bien découpée en trois parties constitutives (le jour, le mois et l'année). A votre avis, quel est le meilleur choix ?

<DATE>

    <JOUR>26</JOUR>

    <MOIS>08</MOIS>

    <ANNEE>1973</ANNEE>

</DATE>

ou

<DATE jour="26" mois="08" année="1973" />

Normalement, un attribut vient qualifier la données d'un tag. Cela rajoute un complément d'information utile pour le traitement de la données. Mais un attribut ne doit pas contenir la donnée principale. Dans le cas d'une date, il est bien clair que l'information principale est constituée du jour, du mois et de l'année. Ces trois informations devraient donc normalement être des données de tags. La première alternative semble donc être préférable.

Malgré cela, et techniquement parlant, les deux alternatives permettraient de mettre en oeuvre une feuille de styles opérationnelle. J'espère que vous sentez bien les doutes auxquels vous pourriez être confronté dans l'avenir.

Pour clore cette section, je vous propose un dernier exemple. Celui-ci, ma fois, me semble tout à fait acceptable. Nous avons ici un tag permettant de définir une date, sous forme d'une unique données. Cependant, il se peut que vous ayez (par exemple dans une feuille de style) à décortiquer cette information pour la présenter différemment. Pour ce faire un attribut format vient compléter cette donnée en déterminant de quelle manière elle est constituée.

<DATE format="fr">26/08/1973</DATE>

Quelques attributs prédéfinis

Il existe en XML deux attributs prédéfinis dont nous allons parler : il s'agit de xml:lang et xml:space. Il permettent, respectivement, d'indiquer la langue utilisée dans une partie du document et de dire ce que l'on va faire des caractères de séparation.

Dans les deux cas, il faut noter l'obligation de les redéfinir dans la DTD si vous souhaitez utilisez un système de validation (malgré le fait qu'ils soient prédéfinies en XML). Autre remarque : si l'un de ces deux attributs est utilisé sur un tag, cet attribut et sa valeur seront aussi cascadés sur tous les sous-tags. Il est donc possible de ne spécifier qu'une unique fois l'attribut xml:lang (par exemple) pour tout le document : il suffit de le définir sur le tag racine.

Reprenons l'étude ces deux attributs un à un

· xml:lang : permet de spécifier la langue utilisée par les données. Voici quelques exemples d'utilisation de cet attribut : notez la possibilité de définir son propre jargon (il est préfixé de x-). Cette possibilité peut, par exemple, servir aux moteurs de recherche pour mieux classifier les documents traités, et mieux renvoyer des résultats pour une recherche donnée.

<EXEMPLE xml:lang="fr">Aquarelle</EXEMPLE>

<EXEMPLE xml:lang="en-GB">Watercolour</EXEMPLE>

<EXEMPLE xml:lang="en-US">Watercolor</EXEMPLE>

<EXEMPLE xml:lang="x-hacker">ceci est un bug</EXEMPLE>

· xml:space : cet attribut accepte deux valeurs. La valeur par défaut est "default" (ça tombe bien). La seconde valeur autorisée est "preserve". Dans ce dernier cas, les caractères de séparation seront préservés : les outils de traitement de données XML pourront ainsi les utiliser. Par caractères de séparation, on entend les espaces, les tabulations et les caractères de passage à la ligne.

Pour information : les outils de traitement de données XML (les parseurs XML), sur lesquels nous reviendrons ultérieurement dans ce cours, transforment un flux XML textuel en une arborescence en mémoire. Le fait de préserver les séparateurs augmente la taille, en mémoire, de cette arborescence, étant donné que des noeuds supplémentaires sont créés pour stocker les caractères de passage à la ligne entre deux tags. Il faut donc utiliser cet attribut avec sagesse.

Le prologue du fichier XML

Un document XML est constitué de deux parties : le prologue et l'arbre d'éléments. Nous avons, jusque là, bien parlé de la seconde partie : l'arbre d'éléments. On utilise cette terminologie car tout ensemble de tags XML peut être représenté sous forme arborescente. Nous allons maintenant nous focaliser plus sur la première partie : le prologue.

Le prologue n'est pas obligatoire, mais vivement recommandé (de part la recommandation XML 1.0). Il contient des informations utiles pour le traitement des données qui y sont contenues. Il est, de plus, subdivisé en plusieurs sous-parties.

Version du XML et système d'encodage

La première ligne sert, principalement, à deux choses. Premièrement, via l'attributs version, elle permet d'indiquer la version du langage XML utilisé. Pour l'heure, il n'y a pas réellement de difficulté à ce niveau, pour la simple et bonne raison qu'il n'existe qu'une seule et unique version de la recommandation : la version 1.0. Voici un petit exemple montrant l'utilisation de l'attribut version : attention aux minuscules et aux majuscules.

<?xml version="1.0" ?>

<!-- Suit l'arbre d'éléments -->

Sa seconde grosse utilité est de pouvoir spécifier quel est le système d'encodage ayant servit à générer le fichier. A ce sujet, quelques explications complémentaires me semble les bien venues. Normalement, vos données vont être contenues dans un fichier dans un format textuel. Pour ce faire, vous allez utiliser un outil qui produira un fichier 8 bits. Or, les outils manipulant les données XML, travaillerons eux, non pas en 8 bits mais avec la norme ISO-10646. Il va donc falloir que ces outils transforment les données contenue dans le fichier au format précédemment cité (c'est aussi le cas pour Internet Explorer).

Mais ce n'est pas tout. Les différents systèmes d'exploitation existant n'utilisent pas tous le même système d'encodage 8 bits. Vous avez certainement déjà reçu des mailsou les caractères accentués étaient parasités : celui qui vous a envoyé le message n'était, à coup sur, pas sur le même système d'exploitation que vous. Par contre, quasiment tous ces systèmes d'encodage possèdent un point commun : ils sont tous dérivés du système ASCII.

Le système ASCII (American Standard Code for Information Interchange) est en fait un table de correspondance qui aux 128 (2⁷) première valeurs entières fait correspondre des caractères bien précis. Ainsi, ASCII associe au code 65 le caractère "A", au code 97 le caractère "a", ... Cette table de correspondance existe maintenant depuis de nombreuses années et l'on est forcé de constater que 128 caractères c'est trop peu. Avec le temps, de nombreuses autres tables de correspondance sont venues étendre ASCII à 256 caractères (2⁸). Si vous utilisez un système d'exploitation Windows configuré pour la France, sachez que vous utilisez alors la table latine 1 : cette dernière est normalisée sous la référence ISO-8859-1.

Si vous ne spécifiez rien, l'outil manipulant vos données (dans notre cas Internet Explorer) considérera que votre fichier utilise la norme ASCII. Or cette dernière ne contient pas de caractères accentués. Si dans vos données se trouve un seul est unique caractère accentué, le système affichera un message d'erreur. Regarder l'exemple suivant ainsi que la capture d'écran montrant le résultat dans Internet Explorer.

<?xml version="1.0" ?>

<PERSONNE>

    <NOM>Durand</NOM>

    <PRENOM>Gérard</PRENOM>

</PERSONNE>

Si, au contraire, vous spécifier le système d'encodage ayant servit à générer le fichier, les données seront correctement interprétées, quelques soit le poste servant à la consultation. Pour spécifier le système d'encodage, utilisez l'attribut encoding. Analyser l'exemple suivant et la capture d'écran associée.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<PERSONNE>

    <NOM>Durand</NOM>

    <PRENOM>Gérard</PRENOM>

</PERSONNE>

Liaison à une feuille de styles

L'une des finalités de votre document XML est certainement de ce présenter dans un navigateur. Pour ce faire, il faut le lier à une feuille de style. Comme nous l'avons déjà signalé dans le chapitre précédent, deux langages peuvent être utilisés : CSS (Cascading StyleSheet) ou XSL (eXtensible Markup Language).

Pour effectuer la liaison, il vous suffit de rajouter la ligne, commençant par "<?xml:stylesheet" dans l'exemple suivant, en deuxième ligne du prologue. Cette ligne indique qu'on cherche à appliquer une feuille de styles. L'attribut type sert à spécifier le langage utilisé ("text/css" ou "text/xsl"). L'attribut href (Hypertext REFeference) indique la localisation du fichier.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<?xml:stylesheet type="text/css" href="Personnes.css" ?>

<PERSONNE>

    <NOM>Durand</NOM>

    <PRENOM>Gérard</PRENOM>

</PERSONNE>

Liaison à une DTD

Le dernier aspect lié au prologue, dont nous allons parler, permet de lier une DTD (Document Type Definition) à votre document. Pour ce qui est des schemas, la liaison s'établie d'une autre manière. Nous reparlerons de cela bien plus tard.

Je rappelle qu'une DTD permet de définir une grammaire XML et que des outils de validation peuvent être utilisés pour contrôler la bonne utilisation des tags au sein d'un fichier de données. Le chapitre suivant rentrera plus en détail dans l'étude des DTD. Pour l'heure, ce qui nous intéresse, c'est de savoir lier une DTD à un fichier de données.

Cette liaison se réalise aussi au niveau du prologue, mais comparé aux lignes précédemment étudiées, la syntaxe diffère quelque peu. Il est aussi à noter qu'une DTD peut directement être embarquée dans le fichier de données. Dans ce cas, la DTD ne sert que pour cet unique fichier. Nous reparlerons de ces possibilités dans le chapitre suivant. Nous ne considérerons ici que le cas d'une DTD définie dans un fichier externe.

L'exemple qui suit vous montre comment la DTD est liée au fichier de données. Une remarque importante est à faire : le nom associé à la DTD doit être exactement identique au nom du tag racine, sans quoi une erreur vous sera retournée.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<?xml:stylesheet type="text/css" href="Personnes.css" ?>

<!DOCTYPE PERSONNE SYSTEM "Personnes.dtd" [] >

<PERSONNE>

    <NOM>Durand</NOM>

    <PRENOM>Gérard</PRENOM>

</PERSONNE>

Aspects avancés de la syntaxe XML

Maintenant que vous commencez à être à votre aise avec la syntaxe XML, je vais en profiter pour vous présenter, rapidement, d'autres aspects de syntaxe, quelque peu plus subtiles. Le concept principal à cerner étant la notion d'espaces de noms (namespace en anglais). Nous verrons ensuite comment injecter un sigle quelconque dans vos documents, dont certains sont fortement lié à la syntaxe XML (et notamment les caractères < et >).

La notion de namespaces

Pour mieux comprendre la notion d'espace de noms, considérons un cas simple. Deux grammaires XML distinctes définissent des tags qui pourraient vous convenir. Dans ce cas, vous pouvez définir une grammaire qui inclue les deux langages précédemment cités.

Considérons aussi, que chacune des deux grammaires sur lesquelles vous vous appuyez définissent un même nom de tag, par exemple <DATE>, mais dont leurs utilisations et leurs significations seront différentes d'un langage à un autre. Dans ce cas, comment dire que l'on cherche à utiliser l'un des deux tags (étant donné qu'ils ont le même nom) ?

C'est, notamment, pour régler ce genre de problématique que la notion d'espaces de noms à été définie. Un nom, complet, de tag est en fait constitué de deux parties séparées par un caractère ":". La première partie spécifie dans quel espace de noms le tag est défini et la seconde nomme le tag. Normalement, un espace de nom est associé à une grammaire particulière. On peut donc ainsi envisager avoir les deux tags <FirstLanguage:DATE> et <SecondLanguage:DATE> sans risque de confusion.

Pour garantir l'unicité du tag, un espace de noms est généralement associé à une URL : en effet, chaque société possède bien sa propre URL. Ainsi, deux sociétés peuvent définir deux langages utilisant des tags similaires sans risque de conflits. Je ne sais pas si vous aviez déjà remarqué, mais nous avons déjà vu un exemple concret d'utilisation d'espace de noms. Si vous ne vous en souvenez pas, revenons rapidement sur la définition d'une feuille de styles XSL. Chaque tag du langage XSL est préfixé du qualificateur xsl. En fait, il s'agit d'un espèce d'alias que se substituera par l'URL http://www.w3.org/1999/XSL/Transform.

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

        <xsl:output encoding="ISO-8859-1"/>

        <xsl:template match="/">

               <xsl:apply-templates/>

        </xsl:template>

        <!-- Suite -->

</xsl:stylesheet>

Injection de caractères Unicode

Il est possible, dans un document XML, d'insérer n'importe quel caractère Unicode. En réalité, cela n'est pas complément vrai dans le sens ou XML supporte la norme ISO 10646 : mais cette dernière et Unicode sont très proche. Par en revenir à nos caractères, il est bien clair que votre clavier 102 touches aura du mal à vous permettre la saisie d'autant de caractères (aujourd'hui, plus de 38000 caractères sont définis dans la table Unicode). Pour visualiser les caractères définis dans la table Unicode, il vous suffit d'activer ce lien.

Pour palier la difficulté, les concepteurs d'XML ont permis le fait de passer une chaîne de caractères ASCII particulière, afin d'obtenir un caractère donné. Cette chaîne de caractères doit commencer par la séquence "&#" et doit se terminer par le caractère ";". Entre ces deux parties, il vous faut fournir la valeur Unicode du caractère souhaité. Sachez aussi que la table Unicode repose, pour ces 128 premiers éléments sur la table ASCII.

Ainsi, l'exemple suivant permet d'insérer quelques caractères de l'alphabet grecque. Le résultat ici présenté ne s'affichera, malheureusement, pas correctement sous tous les navigateurs : seul le HTML des navigateurs modernes reconnaissent aussi cette possibilité.

<CONTENT>

    Quelques caractères Grecque : &#931; &#928; &#934; &#937;

</CONTENT>

Quelques caractères Grecque : Σ Π Φ Ω

Utilisation des entités prédéfinies

Enfin, pour clore ce chapitre, que quelque caractères posent, syntaxiquement, problème en XML. Lesquels, à votre avis ? En fait, ils sont au nombre de cinq, est sont tous fortement lié à la syntaxe XML. En effet, pour structurer votre flux XML, il vous faut, au moins, insérer des tags. Or, dans ce cas, comment insérer un caractère d'infériorité dans vos données ?

Pour ce faire, il vous faut utiliser la notion d'entité prédéfinie. Une entité est une construction XML syntaxique qui commence par le caractère "&" et qui se termine par le caractère ";" (comme pour l'injection de caractères Unicode). Le tableau suivant vous présente les cinq entités prédéfinies en XML, leur signification et le caractère associé. Vous auriez, bien entendu, pu utilisé le code Unicode correspondant à la place d'une entité prédéfinie.

<	Less than	<
>	Greater than	>
&	Ampersand	&
"	Quote	"
'	Apostrophe	'

Conclusion

Nous avons donc, au terme de ce chapitre fait un tour d'horizon des règles de syntaxe du langage XML. Pour ceux d'entre vous qui ont déjà manipulé HTML, notez que les choses sont bien différentes. En effet, alors que le langage HTML est laxiste et qu'il laisse passer les erreurs sans en alerter le lecteur, XML, par contre, vérifiera tous les points de syntaxe vus dans ce chapitre. La moindre entorse à ces règles engendrera un message d'erreur et terminera le traitement de la page.

Notons tout de même que les règles de syntaxes restent simples (très simples). Vous ne devriez donc pas rencontrer des problèmes insurmontables lors de la génération de vos fichiers de données.

Par contre, là ou les choses se compliquent, c'est sur ce que a attrait à la grammaire de votre langage. C'est d'ailleurs de ces aspects dont nous allons commencer à parler dans le chapitre suivant, et plus particulièrement de la mise en oeuvre d'une DTD.

¹ UL signifie Unordered List. En parallèle HTML fournit aussi le tag OL (Ordered List). Ils permettent respectivement de définir des listes à puces (non ordonnées) et des listes chiffrées (ordonnées).

Mise en oeuvre d'une DTD

Dans le chapitre précédent, nous nous sommes surtout intéressé aux aspects de syntaxe inhérents au langage XML. Ce nouveau chapitre va être fortement complémentaire du précédent dans le sens ou nous allons maintenant nous intéresser à la définition d'une grammaire XML. En effet, même si vos tags sont correctement formatés, ce n'est pas pour autant que vous les avez utilisé correctement les un par rapport aux autres, relativement à leur sémantique.

Pour vous convaincre de l'utilité d'une grammaire, il vous suffit de penser au langage HTML. En effet, que pourrait vouloir signifier, dans ce langage, l'utilisation d'un tag <TR> (Table Row) à l'intérieur du couple de tag <A> utile pour la définition d'un lien hypertexte. Il est vrai qu'on ne peut, a priori, considérer une ligne de tableau que dans un tableau.

Pour valider que vos fichiers de données sont grammaticalement correcte, vous allez utilisez un langage de définition de grammaire XML. Aujourd'hui, il en existe deux. Le premier est le langage DTD (Document Type Definition) : historiquement, ce fut le premier proposé. Le second, initialement développé par la société Microsoft, est le langage de schemas (il s'agit en fait d'un langage XML dédié à la définition de grammaire). Nous allons, dans ce chapitre, nous focaliser uniquement sur la définition d'une DTD.

Quelques aspects élémentaires

Avant de poursuivre plus en avant l'étude des DTD, quelques précisions et quelques définitions nous permettrons de mieux nous comprendre durant la suite de ce chapitre.

Qu'est ce qu'un document bien formé ?

On parle de document bien formé quand il respecte bien toutes les règles de syntaxes XML. Au terme du chapitre précédent, nous sommes donc bien apte à définir des documents bien formés. En anglais vous retrouverez la terminologie suivante : "well-formed document".

Qu'est ce qu'un document valide ?

Un document valide est obligatoirement bien formé : il respecte donc bien les différentes règles de syntaxe. Mais pour être valide, il doit de plus respecter une grammaire donnée. En anglais, vous retrouverez la terminologie suivante : "valid document".

Les outils de validation

Certains outils, plus ou moins simple, permettent de valider vos fichiers de données. Je ne peux, à ce niveau, que vous conseiller de jeter un coup d'oeil à l'outil XML Spy. Il s'agit d'ailleurs plus d'un environnement de travail, que d'un simple outil. Il est disponible à l'adresse http://www.xmlspy.com.

Sinon, d'autres outils plus simples peuvent être employés au niveau d'une console de commande. Sur plate-forme Windows, la société Microsoft en fournie une multitude. Notez au passage, que l'outil XML Spy (cité précédemment) utilise au final les commandes de bases Microsoft.

Ou définir une DTD ?

Il existe deux possibilités pour définir une DTD. Soit vous embarquez votre DTD au sein d'un fichier de données, soit vous pouvez la définir dans un fichier externe. Les deux techniques peuvent même être mixées. A votre avis, quelle est la meilleure solution ?

Il me semble logique de dire que la seconde alternative est préférable. En effet, il vous sera alors plus simple de partager votre DTD pour un ensemble de documents. On peut raisonnablement dire que si l'on définie une DTD (dit autrement, un langage), ce n'est pas pour un unique document.

Notons, dans les deux cas, que votre DTD va devoir être nommée. Ce nom se doit obligatoirement d'être celui du tag racine de vos fichiers de données (aux minuscules et majuscules près). Sans quoi une erreur vous sera retournée.

Définition d'une DTD embarquée dans un fichier de données XML

Si vous embarquez votre DTD dans un fichier de données, elle sera alors localisée dans le prologue, au niveau du tag <!DOCTYPE ...>. L'extrait de code suivant vous montre qu'elle est la syntaxe à utiliser. Notez que dans ce cas, le nom du tag racine du fichier XML doit obligatoirement être <exemple>.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE exemple [

    <!-- début de la DTD -->

    . . .

    <!-- fin de la DTD -->

]>

<exemple>

    <!-- Suite du document XML -->

</exemple>

Définition d'une DTD dans un fichier externe

La seconde possibilité permet de définir un fichier de validation externe que l'on pourra par la suite associé à plusieurs fichiers de données. Pour lier un fichier de données à une DTD, il vous faut aussi utiliser le tag <!DOCTYPE ... >. L'exemple qui suit vous montre un exemple de liaison. Le mot clé SYSTEM est utilisé pour indiquer ou se trouve la DTD : c'est une URL qui est attendue. Vous pouvez donc lier vos fichiers à une quelconque DTD présente sur le Web.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE exemple SYSTEM "fichier.dtd" []>

<exemple>

    <!-- Suite du document XML -->

</exemple>

Définition des règles d'utilisation des tags

Nous allons maintenant voir le contenu de la DTD, à proprement dit, quelque soit sa localisation. En fait, une DTD définie plusieurs types de choses et notamment des tags et leurs règles d'imbrication, des listes d'attributs et des entités. Nous allons dans cette section nous focaliser sur la définition des tags.

A titre d'exemple, nous allons travailler sur un petit langage de définition de tableaux. En fait, je ne me suis pas compliqué la vie, j'ai simplement francisé les noms des tags HTML de définition de tableaux. Notre objectif est clair : définir une grammaire proche de celle du langage précédemment cité. L'exemple suivant montre un fichier de données illustrant l'utilisation de nos tags de définition de tableaux.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE TABLEAU SYSTEM "table.dtd">

<TABLEAU>

    <TITRE>Titre du tableau</TITRE>

    <LIGNE>

        <CELL-E>\</CELL-E>

        <CELL-E>Statistique 1</CELL-E>

        <CELL-E>Statistique 2</CELL-E>

        <CELL-E>Statistique 3</CELL-E>

    </LIGNE>

    <LIGNE>

        <CELL-E>Expérience 1</CELL-E>

        <CELL-D>25</CELL-D>

        <CELL-D>34</CELL-D>

        <CELL-D>75</CELL-D>

    </LIGNE>

    <LIGNE>

        <CELL-E>Expérience 2</CELL-E>

        <CELL-D>80</CELL-D>

        <CELL-D>56</CELL-D>

        <CELL-D>61</CELL-D>

    </LIGNE>

</TABLEAU>

Pour ce qui est de la signification de nos tags, les choses sont simples. Pour les tags <TABLEAU>, <LIGNE> et <TITRE>, je ne m'y attarderai pas plus longtemps. Le tag <CELL-E> permet de définir des cellules d'entête (des cellules de titre) dans un tableau. Le tag <CELL-D> permet quant à lui de définir des cellules de données.

Définition de tags contenant des données

On peut noter principalement deux types de tags : ceux qui contiennent des données textuelles et ceux qui contiennent des sous tags. Le premier cas est clairement le plus simple à définir. Les règles suivantes définissent les tags de titres, de cellules d'entête et de cellules de données : en effet, chacun de ces tags ne contient que des données.

<!ELEMENT TITRE (#PCDATA)>

<!ELEMENT CELL-E (#PCDATA)>

<!ELEMENT CELL-D (#PCDATA)>

Le mot clé ELEMENT permet d'indiquer que l'on cherche à définir un tag. Le mot clé #PCDATA indique, quant à lui, que ce tag contiendra des données : #PCDATA signifiant Parsed Character DATA.

Définition de tags contenant des sous-tags

Par contre, pour les deux autres tags (<LIGNE> et <TABLEAU>) les choses se compliquent un petit peu. Regardons dans un premier temps quelles sont les possibilités auxquelles nous avons droit. Dans un second temps nous verrons comment définir ces deux tags.

Plusieurs caractères vous sont proposés afin de pouvoir jouer sur l'occurrence d'un tag ou bien pour exprimer un choix. Le tableau suivant reprend ces caractères un à un et vous en donne leur signification

`?`	Occurrence : peut apparaître 0 ou 1 fois.
`+`	Occurrence : peut apparaître 1 ou plusieurs fois.
`*`	Occurrence : peut apparaître 0 ou plusieurs fois.
`,`	Séquence : Les deux parties doivent obligatoirement apparaître et dans cet ordre.
`\|`	Choix : permet de choisir entre deux alternatives.
`ANY`	Choix : le tag peut contenir n'importe quoi.
`EMPTY`	Le tag ne peut strictement rien contenir.

Afin de mieux les choses je vous propose d'analyser ces quelques petits exemples.

<!ELEMENT agenda (personne*) >	Un agenda est constitué d'un nombre indéterminé de personnes
<!ELEMENT personne (nom, prenom?, date)>	Une personne doit posséder un nom puis un prénom (facultatif) puis une date de naissance
<!ELEMENT hr (EMPTY) >	En HTML, le tag HR (Horizotal Rule) est définie comme étant unitaire : il ne contient rien.

Si nous revenons à notre exemple sur les tableaux les choses deviennent plus simples à exprimer. Pour ce qui est du tag <LIGNE>, il doit contenir un nombre indéterminé de cellules de données ou de cellules d'entête. Il nous faut donc cumuler deux caractères : celui de répétition * et celui de choix |. Mais attention à l'ordre dans lequel vous écrivez votre règle : les deux lignes suivantes ne disent pas la même chose. La première dit que l'on peut soit contenir un nombre quelconque de cellules de données soit un nombre quelconque de cellules d'entête. Alors que la seconde dit que l'on peut avoir un nombre quelconque de cellules. Chacune de ces cellules pouvant être soit une cellule de titre, soit une cellule de données. Il est clair que, si l'on veut fonctionner comme en HTML, la bonne règle est la seconde.

<!ELEMENT LIGNE (CELL-E* |  CELL-D*) >

<!ELEMENT LIGNE (CELL-E | CELL-D)* >

Enfin pour la dernière règle, la plus compliquée de toute, nous allons chercher à dire qu'un tableau peut contenir un nombre quelconque de ligne, mais au plus un seul titre (ce dernier étant facultatif). Là, les choses se compliquent. Dans un tel cas, je ne peux que vous conseiller de casser le problème en sous-problèmes plus simples à traiter individuellement. En effet, un peut dire l'éventuel titre est soit en premier, soit au milieu des lignes ou bien à la fin. D'ou la règle suivante.

<!ELEMENT TABLEAU ((        TITRE?, LIGNE*) |

                   (LIGNE*, TITRE?, LIGNE*) |

                   (LIGNE*, TITRE?        )) >

Mais il est vrai que si l'on analyse bien ce que l'on vient d'écrire la première partie de la règle est un cas particulier de la seconde et idem pour la troisième partie. On peut donc simplifier cette règle. Au final, voici notre grammaire de définition de tableau.

<!ELEMENT TABLEAU (LIGNE*, TITRE?, LIGNE*) >

<!ELEMENT LIGNE (CELL-E | CELL-D)* >

<!ELEMENT TITRE (#PCDATA)>

<!ELEMENT CELL-E (#PCDATA)>

<!ELEMENT CELL-D (#PCDATA)>

Définition de listes d'attributs

Un tag ne se limite pas uniquement à contenir des données ou des sous-tags. Il peut aussi contenir des attributs. Si vous cherchez à valider un fichier de données contenant des attributs de tags, il faudra impérativement qu'ils soient définis dans la grammaire (et donc dans notre DTD). Nous allons donc, dans cette section, voir comment définir une liste d'attributs associée à un tag.

Aspects élémentaires de définition d'attributs

Pour introduire une liste d'attributs, il faut utiliser le mot clé ATTLIST. Il est suivi du nom du tag et des données descriptives de chaque attribut. Il est a préciser que la syntaxe utilisée est, ma fois, pas réellement triviale : soyez donc consciencieux et séparez la définition de chaque attribut pas un retour à la ligne (il n'est pas requis mais sans lui la lecture en est très alourdie).

A titre d'exemple, nous allons rajouter des attributs à nos tags de définition de tableaux. Pour ce faire nous allons nous inspirer des tags HTML, tout en francisant les noms d'attributs. Le tag <TABLEAU> acceptera donc les attributs largeur et bordure et le tag <TITRE> se verra associé un attribut alignement. L'exemple suivant vous donne le code des deux listes d'attributs.

<!ELEMENT TABLEAU (LIGNE*, TITRE?, LIGNE*) >

<!ATTLIST TABLEAU

        largeur CDATA "80%"

        bordure CDATA "1px"

<!ELEMENT LIGNE (CELL-E | CELL-D)* >

<!ELEMENT TITRE (#PCDATA)>

<!ATTLIST TITRE

        alignement (top | bottom) "bottom"

<!ELEMENT CELL-E (#PCDATA)>

<!ELEMENT CELL-D (#PCDATA)>

Reprenons ces définitions une par une. La première liste d'attributs est donc associée au tag <TABLEAU> et définit deux attributs. Le retour à la ligne n'est pas obligatoire et aucun caractère ne vient séparer les définitions : je vous conseille donc vivement de procéder ainsi. Trois informations viennent qualifier le premier attribut : il se nomme largeur, c'est une chaîne de caractères quelconque et par défaut sa valeur est de "80%". Vous pourriez me reprocher d'avoir utilisé le type CDATA pour cet attribut ! Pourquoi ne pas simplement dire que c'est un nombre ou un pourcentage ? Et bien par ce que ce n'est pas possible au niveau d'une DTD : soit nous avons une chaîne libre soit une valeur prise parmi une liste de valeur (nous y revenons dans quelques instants). Le second attribut se nomme bordure, c'est une chaîne quelconque et sa valeur par défaut est "1px".

La deuxième liste d'attributs est associée au tag <TITRE> et ne contient qu'une seule définition. Il s'agit de l'attribut alignement qui lui ne peut prendre qu'une des deux valeurs proposées : soit "top" soit "bottom". Sa valeur par défaut est "bottom". Notez bien que lorsque vous définissez la valeur par défaut, il faut la placer entre des doubles guillemets alors que lors des définitions de valeurs autorisées il ne faut surtout pas en mettre.

Aspects avancés de définition d'attributs

Dans l'exemple précédent, pour chaque attribut, nous avons fournit une valeur par défaut (au cas ou aucune valeur ne serait définie dans le fichier de données). Ce n'est pas la seule possibilité : cette section va en présenter d'autres. Mais notez, avant cela, que même si le navigateur ne valide pas par défaut votre document, il va quand même télécharger la DTD (sauf si elle est présente dans le cache de votre navigateur), car il en a besoin : en effet, sinon, comment aurait-il connaissance des valeurs par défaut utilisées par vos attributs ?

Si vous ne fournissez pas de valeurs par défaut, trois autres alternatives vous sont alors offertes. La première consiste à dire que la valeur de l'attribut est à fournir obligatoirement, ce via le mot clé #REQUIRED. Si un fichier de données contient un tag, pour lequel un attribut est obligatoire, et si aucune valeur n'est fournie alors le document générera un message d'erreur. Voici un exemple de définition d'attribut obligatoire.

<!ELEMENT DATE (#PCDATA) >

<!ATTLIST DATE

        format (en | fr) #REQUIRED

<!-- La donnée est manipulable, car on qualifie son format -->

<DATE format="fr">26/08/1973</DATE>

La seconde alternative consiste à forcer un attribut à une valeur donnée. Dans ce cas, l'attribut existe bien. Sa valeur est imposée et l'utilisateur ne pourra en aucun cas changer cette valeur. Il ne sera même pas possible de spécifier l'attribut dans le fichier de données XML sans quoi une erreur sera retournée.

<!-- Comme le tag PRE en HTML -->

<!ATTLIST PRE

        xml:space (default | preserve) #FIXED "preserve"

Enfin, la troisième alternative consiste à définir un attribut facultatif : attention, ce n'est pas la valeur qui est facultative (car fournie par défaut), mais bien l'utilisation de l'attribut. A titre d'exemple, citons l'attribut alt du tag <IMG> en HTML. Celui-ci permet de définir le texte alternatif de l'image : il apparaît, sous forme d'info-bulle, si vous laisser la souris immobile sur l'image pendant quelques instants. L'attribut est facultatif : s'il n'est pas fournit, aucune info-bulle n'apparaîtra (même pas une info-bulle sans texte).

<!ATTLIST MON-IMAGE

        alt CDATA #IMPLIED

Définition d'entités

Dans le chapitre précédent, nous avons parlé d'entités prédéfinies. Une entités est une construction XML qui commence par le caractère "&" et qui se termine par le caractère ";". Cinq entités sont prédéfinie en XML : il s'agit de "<", "&gt", "&", "&apos" et "&quot".

Nous allons maintenant voir qu'il vous est aussi possible de définir vos propres entités. Cela vous permettra, en quelques sortes, de définir des alias que vous pourrez réutiliser par la suite. A titre d'exemple, considérons, encore, le langage HTML : "é", "à", ... sont des entités qui permettent d'insérer des caractères accentués dans un document.

Vos entités commenceront elles aussi par le caractère "&" et se termineront aussi par le caractère ";". Et vous pouvez définir deux types d'entités : les entités internes et le entités externes. Etudions de plus près chacune de ces possibilités.

Définition d'entités internes

Une entité est qualifiée d'interne si sa définition est directement embarquée dans la DTD : c'est le cas le plus simple. Son intérêt consiste à pouvoir remplacer autant de fois que nécessaire l'entité par le texte qui lui est associé. Si vous êtes programmeur C, vous pouvez comparer ce mécanisme à l'instruction #define du pré-processeur C.

L'exemple suivant vous montre comment définir une entité. Notez au passage que le texte de l'entité peut être complexe : il peut contenir des tags, pourvu que la grammaire soit bien respectée après la substitution.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE test [

    <!ENTITY titre "Introduction au langage XML" >

    <!-- . . . -->

]>

<test>

    &titre;

</test>

Encore une fois, j'insiste sur le fait que même si le navigateur ne valide pas par défaut votre document, il est malgré tout obligé de télécharger la DTD (si elle est externe, bien entendu) : c'est elle qui contient les définitions des entités, et le navigateur devra bien les remplacer.

Définition d'entités externes

Le second type d'entités que vous pouvez définir permet de substituer au nom de l'entité un contenu localisé dans un autre fichier. Afin de mieux comprendre le concept, étudions un petit exemple simple. Nous avons deux fichiers XML : chacun de ces fichiers définit un chapitre d'un livre. Bien entendu, un chapitre étant complexe, il est donc structuré via des tags adaptés. Voici un exemple de contenu pour un tel fichier (j'ai volontairement tapé n'importe quoi pour chacune des sections).

<?xml version="1.0" encoding="ISO-8859-1" ?>

<chapitre>

    <titre>le titre du chapitre 1</titre>

    <section>sqgkfjsmqdlks fqjlf</section>

    <section>sqgkfjsmqdlks fqjlf</section>

    <section>sqgkfjsmqdlks fqjlf</section>

</chapitre>

Le fichier "chapitre1.xml"

Maintenant regardons le contenu du fichier "bouquin.xml" : par l'intermédiaire d'entités externes, il rassemble le contenu des deux fichiers de chapitre en un unique document XML. Une autre entité interne y est aussi présente. Notez bien la présence du mot clé SYSTEM utilisé pour signifier que le contenu de l'entité, à l'instar de la déclaration d'une DTD, est localisé dans un autre fichier.

<?xml version="1.0" ?>

<!DOCTYPE bouquin [

    <!ENTITY chapitre-1 SYSTEM "./chapitre1.xml">

    <!ENTITY chapitre-2 SYSTEM "./chapitre2.xml">

    <!ENTITY auteur "Dominique LIARD">

]>

<bouquin>

    <titre>XML blabla</titre>

    <auteur>&auteur;</auteur>

    &chapitre-1;

    &chapitre-2;

</bouquin>

Le fichier "bouquin.xml"

La capture d'écran qui suit vous montre ce qu'affiche le navigateur Internet Explorer si on lui demande d'affiché le document maître "bouquin.xml".

Conclusion

Au terme de ce chapitre, la déclaration d'une DTD ne devrait quasiment plus avoir de secrets pour vous. Nous avons en effet vu comment définir les tags qui vont constituer votre grammaire, ainsi que leurs règles d'utilisation. Nous avons ensuite étudié comment ajouter des attributs aux tags de votre grammaire. Enfin, nous avons détaillé la manière de définir vos entités : qu'elles soient internes ou externes.

Comme nous l'avons déjà dit précédemment, le langage de définition de DTD n'est pas le seul mécanisme dont vous disposiez. En effet, les schémas XML (une autre recommandation du W3C) permettent aussi de faire de même. C'est justement ces aspects que nous allons développer dans le chapitre suivant.