Extensible Markup Language
Un article de Wikipédia, l'encyclopédie libre.
Cet article (ou cette section) est à recycler. Sa qualité peut être largement améliorée en le réorganisant et en le clarifiant.
L'utilisateur qui appose ce bandeau est invité à énoncer les points à améliorer en page de discussion.
.xml |
|
application/xml, text/xml |
|
Développé par : |
World Wide Web Consortium |
Type de format: |
langage de balisage |
Standard(s) : |
1.0 (4ème édition) |
XML (Extensible Markup Language (en)[1], « langage de balisage extensible ») est un langage informatique de balisage générique. Le W3C recommande XML pour exprimer des langages de balisages spécifiques (exemples : XHTML, SVG, XSLT). Son objectif initial est de faciliter l'échange automatisé de contenus entre systèmes d'informations hétérogènes, notamment, sur Internet. XML est un sous-ensemble de SGML dont il retient plusieurs principes dont : la structure d'un document XML est définissable et validable par un schéma, un document XML est entièrement transformable dans un autre document XML. Cette syntaxe est reconnaissable par son usage des chevrons (< >), elle s'applique à de plus en plus de contenus.
Sommaire |
[modifier] Objectif initial
L'objectif initial de XML était de proposer un SGML simplifié. Cette technologie confidentielle concernait l'édition de documentation électronique, elle commençait à se diffuser avec Internet, HTML était d'abord une application SGML. La longue élaboration de ce standard (1991 HTML 1.0, 1997 HTML 4.0, à peu près la version actuelle) a montré des limites et des complications inutiles justifiant l'élaboration d'un nouveau standard au sein du W3C.
- Internationalisation, limites de l'ASCII pour d'autres langues que l'anglais, d'où ces entités caractères (ex. : é pour é) que l'on trouve encore parfois, XML est en Unicode par défaut.
- Complication à implémenter certains raccourcis SGML, comme les balises à fermeture optionnelle (ex : <li>) ou les éléments vides (ex : <br>). En XML, toute balise ouverte doit être fermée.
- Des usages, mais pas de spécification claire pour faire cohabiter plusieurs vocabulaires de balises dans un même document.
De plus, le W3C avait d'autres projets pour lequel une syntaxe plus facilement extensible était utile. En 1999 est publiée la première recommandation RDF. Ce modèle abstrait vise à définir un réseau de métadonnées adapté au web, RDF accepte une expression XML. La même année, James Clark signe XSLT, un langage de programmation XML pour transformer les documents XML. L'année suivante, la recommandation XSL-FO permet de définir la présentation imprimée d'un document en XML. Enfin, il fallait une nouvelle syntaxe schéma tenant compte des espaces de noms pour remplacer les DTDs (ce qui deviendra XML Schema).
Ces directions ont annoncé une très grande plasticité de XML pour de nombreux usages. SGML était une technologie de niche, très judicieuse, sa simplification l'a universalisé avec Internet, il pénètre la plupart des secteurs de l'informatique.
[modifier] Utilisations et langages dérivés
Les promoteurs initiaux d'XML ont voulu en faire une syntaxe simple et commode, ils y sont certainement parvenus si on considère la variété de ses usages : langage de balisage de textes, format de données, langage de programmation, langage de description de format de document (DSDL), langage de représentation (texte, image...), mais aussi, configuration logicielle, protocole de communication. Ces catégories permettent une classification approximative des langages à base XML (ou acceptant une expression XML).
Tous ces dialectes constituent une nébuleuse en croissance continue. L'exhaustivité est illusoire. Par contre, il est très utile d'en proposer une sélection raisonnée, afin en particulier, de discuter la pertinence de cette syntaxe pour tel ou tel usage. Un commentaire critique de ce format dépends largement du contenu auquel il s'applique. On trouvera aussi certains acronymes qui ont fait date, ils seront présentés comme une sorte de référence bibliographique, avec une adresse éditoriale ou un copyright significatif de l'éditeur et de l'histoire de la norme. En une ligne, il s'agit de répondre à des questions comme : à quoi ça sert ? Quelle est l'organisation derrière ce standard ? De quand date la première publication ? Cela donne un panorama très concret des utilisations et des organisations utilisatrices de XML.
[modifier] Balisage de document
Le balisage de document est le métier initial d' XML. Les DTDs SGML publiques comme TEI et Docbook l'ont adopté, signe qu'elles n'y perdaient rien. Cette migration (comme toutes ?) a pris du temps. Le passage d' HTML à XHTML fut long aussi. XML aurait pu permettre l'apparition de nombreux autres schémas, mais ce serait oublier l'énorme déploiement d'XHTML, la possibilité de le surdéfinir ou de l'insérer dans un autre espace de noms. Le temps n'est peut-être plus aux grandes DTD monolithique, ainsi, XHTML se modularise.
- XHTML - eXtensible HyperText Markup Language, Langage de balisage hypertexte, © 2000, 2002, W3C. ("xmlisation" de HTML, © 1989 à 2000 W3C)
- Docbook - documentation technique, 1991 à 1997 O'Reilly, 1998 à ... OASIS, (Norman Walsh).
- TEI - Text Encoding Initiative, balisage de textes académiques, 1987, 1994, 1999, 2002, Text Encoding Initiative.
- EAD Encoded Archival Description, description archivistique, 1993, 2002, Bibliothèque du Congrès.
- NITF News Interchange Text Format, échange d'articles de presse, 2000, 2002, IPTC.
- NewsML News Markup Language, balisage de dépêche de presse, 2000, 2002, IPTC.
[modifier] Format de données
XML s'est imposé comme format de référence pour l'échange de données entre systèmes d'informations hétérogènes. L'exemple d'un transfert d'informations entre base de données relationnelles permettra d'illustrer les avantages et limites de ce format pour cet usage.
L'exportation d'une table peut se faire en csv. Mais ce format comporte vite des limites à grande échelle (Internet). Il n'est pas autodocumenté (encodage du texte, séparateurs, ordre et nom des colonnes ?). Il demande une documentation externe rarement automatisée entre les partenaires. Que faire lorsque les tables source et destination n'ont pas des structures identiques ? Pour cette raison, on peut préférer des échanges en SQL (à la fois langage de définition de données et langage de manipulation de données). Cependant, malgré de nombreux efforts de normalisation, SQL comporte beaucoup de risques d'incompatibilités entre les implémentations [1].
XML est une solution plus robuste, surtout lorsqu'il est associé à un schéma normalisé. Considérons un cas réel sur Internet : un portail veut informer des nouveautés provenant d'autres sites (Syndication). Son modèle (stockage, présentation, recherche...) demande au moins un titre, une adresse, une date, un auteur, et une description pour chaque enregistrement. Un des partenaires maintient une information plus riche (auteurs répétables, géolocalisation...). Un autre est plus limité (pas de description). Dans une logique relationnelle, il faudrait prévoir des développements spécifiques pour chaque cas particuliers. Avec XML, il est assez facile que le destinataire ne prenne que ce dont il a besoin dans tout ce que la source peut offrir, et de prévoir des mécanismes pour remplacer une information manquante (ex: pas de description ou d'abstract, prendre le premier paragraphe de la page). Il y a là un changement de mentalité entre système d'informations fermé (mais très défini), et des système d'échange ouverts, plus riches, mais moins précis (recherche du plus petit dénominateur commun).
Dans cet usage, XML n'est cependant pas indemne de reproches.
Verbosité ? - XML est verbeux. Si un système n'a besoin que d'un export tabulaire, un tableau CSV conserve la désignation d'un champ par la seule position de la colonne. En XML, le nom de la colonne sera répété pour chaque cellule (au moins une fois si l'information est stockée en attribut, deux fois s'il faut fermer un élément). Le poids du fichier généré n'est pas réellement un problème, car ces motifs répétés se compressent très bien (zip). Des contextes où la bande passante est coûteuse (ex. : téléphonie mobile) s'en sont accommodé (WML). Cette verbosité est plus gênante pour le traitement.
Traitement lourd ? - Traiter du XML demande des bibliothèques dédiées (processeur XML). Cela n'ajoute pas vraiment du temps de développement supplémentaire, du moins pour des équipes formées, mais pour encore quelques temps, il faut compter avec la courbe d'apprentissage. Pour des petites tâches, un parseur ligne à ligne est parfois plus simple. Mais si la donnée se destine à se complexifier, à s'échanger plus largement, on pourra regretter de ne pas avoir choisi XML dès le départ.
XML : données ou document ? - Cette section est l'occasion de marquer la distinction entre XML données et XML document. Il ne s'agit pas d'une différence dans la syntaxe, mais dans ses usages, ses outils et ses communautés d'utilisateurs. Par SGML, XML vient du document. On lui a reproché par exemple ne pas avoir (nativement) de typage fort. On rencontre un mouvement analogue mais contraire en SQL. C'est originalement un format de données, on lui demande de plus en plus de traiter du texte (CMS LAMP). En ce qui concerne XML, cette opposition se traduit dans la direction des efforts de spécification (types de données XML Schema, XPath 2.0, XSLT 2.0) avec des réactions du monde documentaire (Relax NG). Au delà des émotions et des discussions, il semble que ce soit la communauté documentaire (minoritaire ?) qui craint de perdre son langage, ou plus exactement, de ne plus bénéficier des développements d'une communauté plus large, de retourner à sa niche (que l'apparition d'XML avait ouvert).
- RDF - Resource Description Framework Réseaux de métadonnées, © 1997 à 2006 W3C.
- RSS Really Simple Syndication ou Rich Site Summary, 1999 à..., (principe plus que norme).
- Atom - syndication, 2003, IETF.
- OWL - Ontologies (W3C)
- GML - Données géographiques (Open Geospatial Consortium)
- Dublin Core - bibliographie (dublincore.org)
- MODS - bibliographie (Bibliothèque du Congrès, USA)
- METS - échange de collection de fichiers (Bibliothèque du Congrès, USA)
- BiblioML - bibliographie (Bibliothèque nationale de France)
- EbXML - commerce électronique (OASIS)
- XBRL - Données comptables
- XMI - XML Metadata Interchange
[modifier] Langages de schéma
Un processus XML complet comporte une étape de validation à la production et à la réception des documents, mais faut-il que la syntaxe de schéma soit en XML ? La question ne se posait pas en SGML qui s'accomodait des DTDs, une syntaxe texte. Pour l'utilisateur, les limites rencontrées concernait la difficulté de documenter un schéma[2]. Cette fonctionnalité apparemment marginale pour un langage est très importante pour la réussite d'un standard XML. La documentation de Docbook ou TEI constituent par exemple des livres complets, avec même des versions imprimées.
Ces communautés ont attendu avec impatience ce que donnerait XML Schema. Les nombreux outils de documentation automatiques qui sont apparus, avec un simple jeu d'XSLTs, prouvent l'intérêt d'XML comme langage de description de format de document. Cependant, pour des choses simples, XML Schema s'est avéré difficile. Est-ce l'effet de trop de concessions dans un travail collectif ? Toujours est-il que malgré le nombre d'éditeurs derrière le W3C, la communauté est très intéressée par Relax NG. Ce modèle accepte une syntaxe XML, et depuis 2003, propose aussi une forme compacte, qui n'est pas XML ; afin de ramener dans le courant les utilisateurs ayant préféré en rester aux DTDs.
Autrement dit, il n'y a plus de réponse unique, un schéma XML peut se définir dans un vocabulaire XML, ou autrement ; et l'évolution actuelle est de pouvoir combiner des extraits de plusieurs langages de schémas, pour par exemple utiliser le typage fort d'XML Schema, avec des motifs XPath de Schematron, dans du Relax NG[2].
- DTD Document Type Definition « définition de type de document », ISO.
- XML Schema langage de Schéma XML, W3C, 2001.
- Relax NG, DSDL acceptant une forme XML et une syntaxe compacte, ISO, 2001.
- Schematron, validation par motifs, ISO, 2001.
[modifier] Langages de représentation
On vante souvent XML pour sa faculté de séparer contenu, présentation et traitement ; ce n'est pas une conséquence directe de sa syntaxe, WHTML prouve que le contraire est possible, mais l'extensibilité de ce langage permet aussi d'exprimer de la présentation, et sans perte pour les applications les plus exigentes. L'adoption de XML comme format natif du traitement de texte Word dans sa version 2003 en est une preuve éclatante.
- OpenDocument - tous documents bureautiques, OpenOffice.org, 2001.
- Word - le format natif du célèbre traitement de texte est en XML depuis sa version 2003, microsoft, 2003.
- XSL-FO - eXtensible Stylesheet Language - Formatting Objects, langage extensible de stylage - formatage d'objets, W3C, 2001.
- SVG - Scalable Vector Graphics, graphiques vectoriels 2D, W3C, 2003.
- MathML - formules mathématiques, W3C, 1999, 2001, 2003.
- SMIL - Synchronized Multimedia Integration Language, Intégration multimédia, W3C, 1998, 2005.
- X3D - 3D multimédia, consortium Web3D.
[modifier] Langages de programmation
De nombreux langages de programmation généraux sont disponibles, mais pour des opérations spécifiques, il est parfois utile de développer une petite syntaxe plus lisible, et parfois même, plus efficace. Avec un schéma, un dialecte XML dispose d'une grammaire (un peu comme BNF), qu'un processeur peut compiler ou interpréter, à destination d'un langage comme Java.
En théorie, la structure en arbre d'XML permet de représenter la hiérarchie d'un programme objets, ou l'imbrication des instructions d'un langage impératif. En pratique, les boucles sont le cas limite à partir duquel XML devient trop verbeux, par contre, cette écriture est remarquablement adaptée aux syntaxes déclaratives (configuration, définition d'interface), et même, popularise les algorithmes fonctionnels (XSLT, logique d'une application web).
Il en résulte que l'on trouve de plus en plus d'XML dans les logiciels. Dans certains frameworks de développement web, il est possible de monter une application complète et complexe, en n'éditant que du XML.
- XSLT - Extended Stylesheet Language Transformations, transformation de document XML, W3C, 1999.
- XML Query - requête et transformation XML, W3C, 2005.
- ANT - scripts de compilation, ASF.
- Servlet - serveur d'application Java, configuration et logique fonctionnelle, Sun Microsystems.
- Log4j - log for Java, configuration d'une bibliothèque d'historique, 1996, © 1999-2006, ASF.
- UIML - User Interface Markup Language, définition d'interface, OASIS, 1997.
- XUL - XML-based User interface Language, définition d'interface, Mozilla, 2000.
- XAML - définition d'interface, Windows Vista, 2006.
- MXML, Flex - définition d'interface, Macromedia.
[modifier] Protocoles d'échanges
Un protocole échange de contenu et des instructions entre un client et un serveur. HTTP est un modèle de protocole (qui n'est pas XML mais textuel). La simplicité et la précision d'un protocole conditionne la facilité à l'implémenter et le succès de la technologie qui le déploie (ex. : Internet). XML peut être un format de contenu et une syntaxe de programmation, donc il peut être un langage pour un protocole. Il apporte en plus la hiérarchie récursive (ex: WebDAV). L'universalité progressive de la connexion HTTP comme des processeurs XML explique pourquoi XML devient une solution courante pour créer un nouveau protocole.
- XForms - formulaires web (W3C)
- OAI - Open Archive Initiative Protocle Archives ouvertes, 2000, 2002 (OAI)
- SOAP - RPC par HTTP (W3C)
- WSDL - Services Web (W3C)
- WebDAV - Lecture/Ecriture distante par HTTP (IETF)
- Jabber/XMPP - Messagerie instantanée (IETF)
[modifier] Langages associés
Les langages associés à XML sont des syntaxes qui ne sont pas en XML mais très attachées à XML. CSS illustrera bien la notion. Il peut être contenu dans un attribut (@xhtml:style), dans un élément (<xhtml:style>), ou relié à un document XML par une instruction de traitement (<?xml-stylesheet href="common.css" type="text/css"?>). XPath fournit un autre exemple de spécification entièrement dédiée à XML, mais qui est justement sans éléments ou attributs, afin d'être associé à un langage XML (XSLT).
- CSS (Cascading Style Sheet)
- DTD (Document Type Definition)
- NameSpaces
- SGML
- XPath
[modifier] Conclusion, étape suivante ?
En 2001 on demandait à James Clark, un expert XML et SGML, What's the next step for XML ? « Quelle est l'étape suivante pour XML » ? Il répondit d'abord que cela revenait à demander, quelle est l'étape suivante pour le texte ASCII ou pour les fichiers à lignes délimitées. XML est en effet devenu un format aussi universel qu'unicode pour structurer des contenus, comme un esperanto de l'informatique. Qu'un arbre XML permette de représenter beaucoup de choses ne signifie pas que ce soit toujours la forme la plus adaptée, chaque utilisation à ses cas limites. La verbosité en particulier, peut faire préférer des écritures de types S-expression, mais cette forme de rédaction pouvant plaire à certains humains ne remet pas en cause un modèle hiérarchique, et les chaînes de traitement XML après une première transformation.
Un arbre XML bute cependant sur un motif simple : l'intersection. Considérez ce texte tuilé : en gras et en italique. Le et appartient à deux zones, chose simulable mais pas native dans un arbre. On peut en faire une représentation xhtml comme ceci <b>en gras <i>et</i></b> <i>en italique</i>, dont on voit d'ailleurs qu'elle n'est pas unique, car la notion d'intersection est perdue. Ce détail se démultiplie dans les applications WYSIWYG qui produisent du XML (traitement de texte, SVG), rendant la source générée de moins en moins lisible par un humain. Ce détail amènera peut-être un nouveau format.
Selon James Clark en 2001, la nouveauté ne viendrait plus du format, mais de l'intégration applicative pour le traiter, c'est encore vrai en 2006.
[modifier] Comparaison à d'autres formats
Pour savoir à quoi ressemble du XML, le mieux est certainement d'en voir. Commençons par un exemple simplifié. Il propose une transposition du début de cet article dans un langage XML appliqué à la documentation technique, DocBook.
<!-- Un petit document XML, en Docbook --> <article xmlns="http://docbook.org/ns/docbook"> <title>Extensible Markup Language</title> <para> <acronym>XML</acronym> (Extensible Markup Language, « langage de balisage extensible »)... </para> </article>
Dans ce code, chacun peut identifier des portions de texte (ex : Extensible, XML...) et des mots clés encadrés de chevrons (<, >) : <article>, <title>, <para>... Ce document est ouvert par le mot clé <article>, et clos par </article>. Notez la barre oblique, elle signifie la fermeture de la balise article. En XML, une balise doit toujours être fermée. . À l'intérieur de cet article, il y a un titre (<title/>), un paragraphe (<para/>), et un acronyme (<acronym/>).
Ce qui est spécifique à XML, c'est le choix des chevrons pour identifier les balises, et l'obligation de les fermer. Les mots clés ne sont pas définis par la norme XML, mais par le vocabulaire choisi. En XHTML, l'élément racine aurait été <html>, en XSLT, cela peut être <xsl:stylesheet> ou <xsl:transform>. Ceci illustre la nature extensible d'XML. Ce n'est pas un jeu de noms réservés (ex : echo, for, public, function, class...), mais plutôt des caractères réservés permettant de définir un «langage».
Cet exemple illustre une autre spécificité de ce format. À part SGML, peu d'autres syntaxes permettent de séparer la définition sémantique de l'information (qu'est-ce qui est titre, lien, section...), de l'apparence qu'on lui souhaite (aujourd'hui un titre est souligné, demain on le voudra peut-être en bleu). Cela fait d'XML un excellent format pour conserver des textes ou des données. Pour s'en convaincre, regardons ce que la même information donne dans d'autres formats.
[modifier] Formats binaires
Les logiciels, surtout pour le grand public, aboutissent généralement à des fichiers. Le format se soucie d'abord d'être fiable et performant, mais est-il échangeable ? Le format d'enregistrement natif du traitement de texte Word est l'exemple du format binaire le plus déployé. Il n'est pas lisible par l'humain. Le texte est séparé de sa mise en forme, les commandes comme gras ou italique sont enregistrées séparément. Dans la pratique, un document word est difficilement lu par d'autre applications, des problèmes peuvent même se poser entre plusieurs versions du même logiciel.
ÐÏ�ࡱ�á > � þÿ ! # � þÿÿÿ ÿÿ% � ð�¿ � � a� � bjbj%ç%ç Extensible Markup Language XML (Extensible Markup Language, « langage de balisage extensible ») � i � � 8 @ñÿ� 8 � � N o r m a l � � CJ� _H��aJ� mH��sH��tH��N �@� � N � � T i t r e 1 � � ÿ [... beaucoup d'informations binaire supprimées ] ÿ ÿÿÿÿ� � À F� Document Microsoft Word MSWordDoc � Word.Document.8 ô9²q
[modifier] RTF (Rich Text Format)
Afin de favoriser l'échange avec d'autres traitements de texte, Microsoft proposa le RTF (1987). Ce n'est pas un format binaire, les commandes sont inscrites en texte lisible, mais elles ne sont pas destinées à être écrite par un humain.
{\rtf {\f2\fs36\b Extensible Markup Language}\par {\b XML} (Extensible Markup Language, « langage de balisage extensible »)... \par }
On retrouve le besoin d'encadrer du contenu avec un marqueur (ici les accolades {}), d'attacher des propriétés à ces groupes. {\b XML} indique que les lettres XML sont en gras, bold : \b. Pour le titre, humains comme logiciels ne peuvent pas l'identifier par "\f2\fs36\b", ce code indique en fait l'apparence du paragraphe (gras, gros...). Ce format a montré qu'il pouvait fonctionner dans des logiciels, mais sa croissante complexité instruit sur ses limites. Il est difficilement extensible, et en tous cas, inutilisable pour structurer la sémantique d'un texte.
[modifier] TEX
Donald Knuth (1938~...), auteur de The Art of Computer Programming « l'Art de la programmation » s'est interrompu en 1977, excédé par la mauvaise qualité d'impression de ses ouvrages. Il développa TEX, une syntaxe très élaborée destinée à l'écriture humaine, spécialement puissante pour les équations mathématiques. On remarquera que RTF lui a repris ses séparateurs (\, {, }), mais pas son système de macros pour factoriser les commandes.
\documentclass[a4paper, 11pt]{article} \title{Extensible Markup Language} \begin{document} \maketitle \end{document}
TEX reste le standard de l'édition scientifique de qualité, en particulier pour la mise en forme des équations complexes. Toutefois, cela reste un langage de programmation d'apparence, et même avec les macros, il n'est pas conçu dès le départ pour structurer un contenu indépendamment de sa destination.
[modifier] wiki
Une syntaxe wiki sait aussi séparer le contenu de la présentation.
=Extensible Markup Language= '''XML''' (Extensible Markup Language, « langage de balisage extensible »)...
Cependant, cette structuration repose ici sur des séquences de caractères particulières (===, '''). Or, le nombre de caractères sans signification n'est pas indéfini. Un tel format peut être approprié pour un seul type de document, mais ce n'est pas une syntaxe générique et facilement extensible.
[modifier] Composants d'un document XML : les nœuds
La plupart des composants d'un document XML peuvent être représentés par un arbre (à l'exclusion du prologue). Ce sont donc des nœuds. Ce modèle fait d'ailleurs l'objet d'une définition très précise (DOM), afin de permettre à des langages de programmation de manipuler du XML. Nous nous limiterons à énumérer les types de nœuds fondamentaux, que l'on peut identifier dans l'exemple artificiel suivant.
<?xml version="1.0" encoding="UTF-8"?> <!-- Commentaire --> <élément-document xmlns="http://exemple.org/" xml:lang="fr"> <élément>Texte</élément> <élément>élément répété</élément> <élément> <élément>Hiérarchie récursive</élément> </élément> <élément>Texte avec <élément>élément</élément> mêlé</élément> <élément/><!-- élémént vide --> <élément attribut="valeur"></élément> </élément-document>
[modifier] La racine du document, /
En informatique, un arbre a généralement une et une seule racine (ce qui n'a pas d'ancêtres). La racine d'un document XML se situe donc derrière tous les nœuds (sauf le prologue, qui n'est pas un nœud). En XPath, la racine du document est notée avec la barre oblique / (comme l'arbre d'un système de fichiers Unix).
Pour être bien formé, un document XML doit avoir un et un seul élément à la racine, parfois désigné par "élément document". La racine accepte aussi les commentaires, et des instructions de traitement, mais surtout pas de texte.
[modifier] Les éléments <élément/>
L'élément est le composant qui fait la spécificité d'XML. Il a un nom (précisément qualifié), et peut porter tous les types de nœuds (attributs, texte, éléments...). Le fait qu'un élément puisse avoir des enfants texte et des enfants éléments a beaucoup de conséquences pour en faire un format de données très souple (comparé par exemple à une table relationnelle). La qualification des noms contribue aussi à la précision sémantique des contenus balisés.
Un exemple de notice bibliographique permettra de mieux montrer le potentiel de ce format, il utilise le vocabulaire Dublin Core.
<ex:collection xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://www.w3.org/1999/xhtml" xmln:ex="http://exemple.org"> <dc:title>Astérix le Gaulois</dc:title> <ex:livre> <dc:title>Astérix chez les Belges</dc:title> <dc:creator>René Goscinny</dc:creator> <dc:creator>Albert Uderzo</dc:creator> <dc:type>Text</dc:type> <dc:description> <b>Astérix chez les Belges</b> est un album de <a href="http://fr.wikipedia.org/wiki/Bande_dessinée">bande dessinée</a> de la série Astérix le Gaulois créée par René Goscinny et Albert Uderzo. Cet album publié en 1979 est le dernier de la série écrit par René Goscinny. </dc:description> </ex:livre> </ex:collection>
- répétable
- Une même propriété peut être répétée. L'exemple montre comment indiquer qu'un livre a plusieurs auteurs (dc:creator). Dans un format tabulaire, avec un nombre de colonnes défini, ce n'est pas impossible, mais moins spécifié.
- ordonné
- L'ordre des éléments est conservé. Quel que soit le langage employé, un outil XML doit permettre de distinguer le premier auteur du second (ex. : en XPath, /ex:collection/ex:livre/dc:creator[1] = "René Goscinny", /ex:collection/ex:livre/dc:creator[2] = "Albert Uderzo").
- hiérarchique
- Les éléments XML sont imbricables. Ceci rend ce format particulièrement adapté à représenter des arbres. Ici, on s'est limité à 2 niveaux (/ex:collection/ex:livre), une collection avec un titre (Astérix le Gaulois), et un exemple d'ouvrage de cette collection (Astérix chez les Belges). XML permet une récursivité complète. Par exemple, un livre, ou une thèse, peut être formaté très économiquement avec un élément <section>. La partie 2.3.5 correspondra à une structure d'imbrication XML /section[2]/section[3]/section[5].
- mélangeable
- Enfin, ce qui fait qu'XML est plus qu'un format de données, c'est la possibilité de mélanger du texte et des éléments. L'exemple montre comment le texte de la description (dc:description) est enrichi avec des balises XHTML (du gras <b> et un lien <a>).
Noms qualifiés - Cette souplesse, et l'eXtensibilité de XML est contrôlée par la qualification des noms. Vous aurez remarqué dans l'exemple de code que la plupart des éléments sont des liens. Comme il s'agit de standards, ils disposent d'une documentation officielle en ligne. Pour une notion commune comme un titre, cela ne semble pas nécessaire. Mais pour des noms beaucoup plus ambigus, comme type, il est très important de déterminer le vocabulaire dans lequel interpréter le mot. Ainsi, Dublin Core est un vocabulaire de métadonnées bibliographiques, type qualifiera des types de document : Text, Image, Sound... Dans un vocabulaire dédié à la documentation informatique comme Docbook, type a le sens de type de données.
xmlns="URI" - En XML, les noms d'éléments devraient toujours être identifiés par une URI. C'est l'objet des attributs xmlns:* sur l'élément racine de l'exemple (xmlns:dc="http://purl.org/dc/elements/1.1/") et des préfixes sur certains noms (dc:type est identifié par l'URI de l'attribut xmlns:dc). Il n'est pas nécessaire ici de détailler plus cette syntaxe. L'essentiel est de retenir qu'en XML, le nom d'un élément ne se choisit pas au hasard, qu'il résulte d'un travail de modélisation, qu'il est précisément identifié.
[modifier] Le texte
Un nœud texte n'a pas d'enfants, il est toujours contenu dans un élément. Par défaut, il sera traité comme de l'Unicode en UTF-8 ou UTF-16. XML permet de spécifier d'autres encodages dans le prologue (ex: <?xml version="1.0" encoding="ISO 8859-1"?>). Ce simple choix a déjà apporté une énorme simplification aux problèmes d'encodages que l'on rencontre encore en informatique.
Dans un schéma XML, le texte est souvent considéré comme un contenu, défini par l'élément qui le contient (et ses attributs). Une anecdote permettra de comprendre cette remarque de style. À un moment, il a été observé que les attributs étaient plus rapides à traiter que les nœuds texte par certains processeurs XML. La tentation était alors de placer tous les contenus dans les attributs, et de ne définir que des éléments vides. Certaines données peuvent s'y prêter, mais c'est probablement une erreur de modélisation de restreindre ainsi l'expressivité qu'XML permet.
espaces vides - Le traitement des espaces et sauts de lignes en XML peut apporter quelques surprises. Sous sa forme texte, un fichier XML sera probablement indenté par son auteur. La recommandation n'oblige pas un processeur XML à conserver ces espaces non significatifs, sauf instructions particulières (exemple : bloc préformaté <pre>). Il en résulte que le texte XML proposé à un processeur peut ne pas revenir à l'identique après traitement, ce qui cause des désagréments dans certaines applications.
texte mêlé - Dans le cas des textes mêlés (ex : <p> du texte en <b>gras</b> dans un paragraphe</p>), l'élément parent a plusieurs enfants texte et éléments qui se succèdent, ce n'est pas le texte qui contient un élément (ex. : p/node()[1]="du texte en ", p/node()[2]="<b>gras</b>", p/node()[3]=" dans un paragraphe"). Cette petite remarque n'a d'importance que dans certaines interfaces de manipulation XML (DOM), elle permet aussi de fixer la définition.
[modifier] Les attributs, <élément attribut="valeur"/>
Un attribut est un nom et une valeur, la valeur peut être vide <element attribut=""/>, mais pas nulle <element attribut> (cette écriture était permise en SGML, on la rencontre encore parfois à propos d'HTML, mais elle n'est pas acceptée en XML). Un nom d'attribut a les mêmes possibilités de qualification qu'un nom d'élément.
La valeur est un texte sans éléments (ni autres nœuds). Un attribut est toujours porté par un élément (dans le contexte de certains langage de programmation XML, par exemple XSLT, il peut arriver que soit généré un attribut volant, le processeur avertira de l'erreur). Un attribut est unique (la répétition d'un attribut de même nom sur le même élément provoquera une erreur du processeur XML). L'ordre des attributs n'est pas significatif (<element attribut1="valeur1" attribut2="valeur2"/> et <element attribut2="valeur2" attribut1="valeur1"/> sont équivalents, même s'ils sont écrits différemment).
[modifier] Les commentaires <!-- -->
Comme tous les langages de programmation, XML a une convention pour inscrire des commentaires. Son contenu ne sera pas interprété (<!-- <element>je suis mal formé mais dans un commentaire -->). Un commentaire a toujours un élément pour parent.
Style - Il est théoriquement possible de traiter le contenu des commentaires XML avec un processeur. Un exemple où cela peut être utile : transformer de la programmation en XML (exemple : XSLT) afin d'en fournir la documentation. Mais il s'agit d'un cas limite, une application XML ne doit pas s'appuyer sur le contenu des commentaires.
[modifier] Le prologue
En XML, le prologue est constitué de la déclaration XML (<?xml version="1.0"?>) et de la déclaration de type de document (DOCTYPE). La déclaration XML est obligatoire à partir de la version 1.1. Cette écriture avait une grande importance en SGML. Elle attache le document traité par un processeur à son schéma (DTD), ce qui permet de la valider, et d'interpréter certains raccourcis (les entités). Désormais, il existe plusieurs langages de validation, et parfois plusieurs manières de les attacher. Le prologue n'a plus la même importance.
[modifier] Autres nœuds
Afin d'être complet on mentionnera aussi
- Les Instructions de traitement, <?xml-stylesheet href="transform.xsl" type="text/xsl"?> <?clé valeur?>, des nœuds destinés aux logiciels traitant le XML
- Les sections d'échappement, <![CDATA[ <ceci> ne sera pas considéré comme un élément ]]>
[modifier] processus XML
XML a désormais prouvé qu'il était une syntaxe très générique de balisage, propre à de nombreux usages. Cette réussite s'explique par des implémentations concurrentes de nombreuses Interfaces de programmation (APIs) précisément spécifiées. Comment entre-t-il dans un processus applicatif ?
Pour détailler ces étapes, considérons le processus le plus simple, accessible depuis quelques années dans Internet Explorer ou Firefox. Ces navigateurs permettent de consulter des fichiers dans un XML sémantique (qui ne contient que des contenus, sans présentation), et de les voir comme des pages accompagnées de couleurs et de navigation. Ils sont transformés par le client, avec une feuille XSLT. Prenons par exemple le site de Norman Walsh[3]. La source de la page servie ressemble à ceci :
<?xml version='1.0' encoding='utf-8'?> <?xml-stylesheet href="/style/browser.xsl" type="text/xsl"?> <essay xmlns="http://docbook.org/ns/docbook" xml:lang="en" version='5.0'> <info> <title>XProc: An XML Pipeline Language</title> <!-- ... -->
Ce n'est pas du xhtml (ou du HTML) mais du Docbook. Les navigateurs ne sont pas capables de lire cette grammaire pour lui donner de la présentation. La page apparente est le résultat d'une transformation, signalée au navigateur par l'écriture <?xml-stylesheet href="/style/browser.xsl" type="text/xsl"?>. Le fichier browser.xsl explique comment transformer du docbook en html. Le processus est immédiat, il est intéressant de le détailler, car on le retrouve dans des applications XML plus complexes.
- produire : le document docbook doit avoir été produit ou résulter d'un import ;
- entrée : dans le navigateur, un parser lit le fichier XML pour construire un objet informatique, et vérifie que le document est bien formé ;
- inclusions : dans certains contextes, il est possible d'inclure des fichiers qui deviendront des noeuds ;
- validation : le document peut être validé, pour vérifier que sa structure est conforme au schéma docbook ;
- transformation : le document docbook est transformé en xhtml ;
- sortie : le navigateur s'occupe de rendre le résulat de la transformation en une page pour un utilisateur.
Cette succession canonique d'étapes illustre ce que peut être le tuyau d'un processus XML complet. Elles vont maintenant être expliquées pour montrer comment elles peuvent apparaître dans d'autres contextes applicatifs, plus complexes.
[modifier] Produire
[modifier] Entrée
Avant d'entrer dans un tuyau, un contenu doit être « xmlisé ».
- SAX utilisé pour les traitements de documents à la volée (cette API est utilisée pour des traitements au fur et à mesure de la réception d'un document XML),
- DOM (utilisable par des langages côté serveur comme Php ou Asp) utilisé pour les accès directs aux éléments d'un document XML, grâce à la construction d'un arbre logique complet contenant toute la structure du document XML (cette API est utilisée quand le document est entièrement disponible). DOM permet également de générer de nouveaux documents XML, en créant un arbre logique, qu'on transforme ensuite en document XML.
Ces API sont les plus utilisées mais d'autres API existent, comme JAXP, JDOM et dom4J pour Java. StAX est une autre API avec une philosophie différente de SAX et DOM, basée sur le motif de conception itérateur.
[modifier] Inclusions
Un document XML peut être constitué de plusieurs fichiers. Il y a deux normes actuellement concurrentes.
- les entités externes, issues de SGML, résolues a priori par un parseur validant, avant tout traitement du document.
- xinclude, un élément XML dédié, pouvant être traité comme une étape séparée.
Les spécifications et les implémentations privilégient maintenant xinclude, bien que son adoption a pu être discutée[4]
Considérons l'exemple d'un catalogue de produits pour voir les effets de l'un et de l'autre. On aura chaque produits sous la forme d'un document XML, et un document maître qui assemble toutes les références. En entités, cela s'explique ainsi.
<!DOCTYPE catalogue [ <!ENTITY article001 SYSTEM "articles/article001.xml"> <!ENTITY article002 SYSTEM "articles/article002.xml"> ]> <!-- Un exemple d'inclusion par résolution d'entité externe --> <catalogue xmlns="http://exemple.net/ns"> <titre>catalogue</title> &,article001; &article002; </catalogue>
On remarquera que les entités sont déclarées en entête de document, puis appelées par une écriture du type &entité;. Cette syntaxe est initialement prévue pour des raccourcis, afin de factoriser l'écriture de variables comme un nom de produit ou une société. Ce mécanisme a été étendu pour résoudre les problèmes d'encodage en ASCII avant l'Unicode. Ce sont les entités caractère comme é=&#E9;=é. Pour le cas d'une inclusion d'un fichier, cela demande deux déclarations, celle du lien, celle de son appel. Ce moyen reste massivement employé par les sociétés qui ont connu SGML, d'autant que son support est beaucoup plus généralisé que celui d'xinclude.
La résolution a priori des inclusions peut avoir des inconvénients, en particulier pour des documents maître très lourds que l'on peut vouloir travailler sans leur dépendances. Xinclude permet cela, ainsi que de générer ces relations automatiquement (XSLT).
<!-- Un exemple d'inclusion par xinclude --> <catalogue xmlns="http://exemple.net/ns" xmlns:xi="http://www.w3.org/2001/XInclude"> <titre>catalogue</title> <xi:include href="articles/article001.xml"/> </catalogue>
On retrouve cette évolution vers la modularisation d'XML où l'inclusion devient une étape optionnelle d'un processus.
[modifier] Validation
La validation est l'opération automatique qui vérifie la conformité d'un document XML à son schéma. Elle a pour but de délivrer des messages comme il n'y a pas de titre au chapitre 5, ou bien, la date de fabrication est dans le futur. La précision et la convivialité de cette vérification dépendent de la syntaxe utilisée.
En SGML, la validation s'effectuait toujours avant l'entrée d'un document XML dans un processus. On parlait de parser validant. Il n'y avait alors qu'un seul langage de validation (les DTDs) déclarés d'une seule manière à l'intérieur du document XML (la déclaration DOCTYPE, Type de document). La pratique a montré que la validation n'est pas toujours nécessaire, et même, contre performante. Dans d'autres cas, plusieurs étapes de validation peuvent être utiles, par exemple, une pour vérifier la structure de l'arbre XML, une autre pour vérifier les liens. L'évolution va vers une étape de validation distincte, déclarée à l'extérieur du document, et gérée selon les besoins du logiciel.
Les parseurs XML gardent l'ancien usage de conserver les bibliothèques logicielles de validation. Cependant la fonctionnalité peut être débranchée, ou appelée séparément. Il existe aussi des librairies uniquement dédiées à la validation. Le déploiement actuel rends la validation XML nativement accessible à la plupart des systèmes, et dans la plupart des langages de programmation.
- MSXML - Microsoft Core XML Services, le parseur XML Microsoft, 2000-2006, intégré au système d'exploitation Windows, validation DTD et XML Schema, accessible aux langages Microsoft.
- libxml2 - Le processeur XML libre du système d'exploitation linux, validation DTD et Relax NG (le support XML Schema est partiel, surtout pour le typage de données au sein de Relax NG), accessible en Python [3], en PHP [4].
- Xerces - XML Java Parser, le parseur XML par défaut d'une machine virtuelle Java, validation DTD et XML Schema, accessible en Java.
- Jing - a Relax NG validator in Java, un validateur qui n'est pas un parseur pour Relax NG et Schematron.
- XSLT - Une transformation XSLT permet une validation très précise sur un type de document, c'est couramment utilisé dans une application web pour rendre à l'utilisateur des messages plus conviviaux, cet outil suffit aussi pour utiliser une implémentation Schematron.
[modifier] Transformation
[modifier] Sorties
- (en) Apache Batik, API Java permettant de générer des documents SVG
- (en) FOP, le sérialiseur XSL-FO d'Apache
- (en) XEP, processeur XSL-FO et SVG commercial, RenderX
[modifier] Stockage
Stocker du XML ne pose aucun problème jusqu'à quelques mégas[5], un Fichier suffit, sans problème de performances en requête ou en transformation. Cela permet d'ailleurs de constituer des sortes de petites bases de données, interopérable, sans l'accompagner d'un logiciel lourd. Une transformation XSLT exécutable par un Navigateur Web permet par exemple la consultation, voire l'alimentation. Cette section concerne le moment ou un seul fichier ne suffit plus.
Prenons l'exemple d'un catalogue de produits. C'est un contenu assez habituel pour une base de données relationnelles. XML permet de maintenir des notices de formats différents, avec un contenu rédactionnel plus riche, sans pour autant perdre la rigueur des identifiants ou des prix. Cette solution peut être intéressante si par exemple, on cherche une impression de qualité. Quelles sont les solutions de stockage pour de nombreuses réréfences ?
[modifier] « Tuyaux » (XML Pipeline)
Les étapes décrites plus haut sont en cours de normalisation par le W3C (XML Processing Model Working Group). Une terminologie est déjà officialisée. Mais ces idées ont déja des implémentation concurrentes dans plusieurs frameworks . L'idée de tuyaux XML existe avant d'avoir été spécifiée.
Un tuyau est une entrée (Input Document), une sortie (Output Document), et une chaîne d'étapes (Step). Ces étapes traitent un flux XML (XML Information Set, Infoset [5]). La notion de flux d'information n'est pas spécifique à XML, on la retrouve à grande échelle dans l'informatique réseau, ou très simplement en ligne de commande Unix, avec le pipe (|). L'originalité réside dans la structuration propre à XML. Les octes traités par ces tuyaux sont des documents structurés. Les étapes sont standardisées et combinables. Elles sont définies par des composants (components) paramétrables (parameter). Chaque étape a une entrée et une sortie spécifiable. Ce modèle théorique permet de décrire un processus XML.
[modifier] Conclusion
[modifier] Notes
- ↑ Ce nom est une idée de James Clark, elle est très bien expliquée par Tim Bray dans sa spécification annotée. Comme en anglais la lettre X se prononce "eks", elle peut être utilisée dans les sigles pour abréger un ou plusieurs mots commençant par ce même son comme eXtensible ou eXperience (XP). Un bon nombre de langages ont également affiché leur parenté avec XML en s'adjoignant un X (ex : XHTML).
- ↑ Eric van der Vlist, RELAX NG, « W3C XML Schema Type Library », O'Reilly & Associates, 2003 (ISBN 0596004214) [lire en ligne]
- ↑ Ou celui de Jeni Tennison et de plusieurs autres.
- ↑ Norman Walsh, XInclude, xml:base, and validation, 2005-04-01.
- ↑ La mesure exacte dépends de la quantité de [[Ressource (informatique)|]] que l'on veut laisser à une application.
[modifier] Voir aussi
- Index alphabétique de tous les articles reliés à XML.
- Utilisations, section de cet article classant des dialectes XML.
Autres technologies et théories intéressant XML.
[modifier] Liens externes
- Spécification XML 1.1 (fr) (en)
- Spécification XML 1.0 (fr) (en)
- (en) Tim Bray, The Annotated XML Specification, version annotée par
- (en) James Clark, Comparison of SGML and XML, comparaison de SGML et XML, W3C, 1997. Cette note est citée en référence non normative de XML, elle indique les règles à configurer dans un parser SGML pour qu'il soit conforme à XML.
- (en) A Triumph of Simplicity: James Clark on Markup Languages and XML, « Triomphe de la simplicité : James Clark, langage de balisage et XML », interview de James Clark par Eugene Eric Kim, 2001. Dans ces paragraphes, James Clark résume son parcours et ses idées technologiques, avec un éloge tout à fait inattendu du parser XML/XSLT de Microsoft, de la part d'une grande figure du logiciel libre.
- (en) Page d'accueil XML du W3C
- (en) Unicode in XML and other Markup Languages, note du W3C, 13 juin 2003
- (fr) Developpez Cours et tutoriels sur XML
- (fr) Developpez FAQFAQ XML
- (fr) SELFHTML: XML
- (fr) Cours de XML sous GNU Free Documentation License
- (fr) 20 notes sur XML
- (fr) 5 cours complets sur XML en pdf
|
|