HL7 est une organisation internationale en charge de la définition et de la standardisation d’un format d’échange d’informations circulant dans les SIH (Systèmes d’Informations Hospitalier). Le format HL7 permet donc à des applications hétérogènes d’échanger des informations cliniques, qu’elles soient d’ordre médico-administratif, comme l’admission d’un patient, médico-technique comme les résultats d’examen de laboratoire, etc.

Les premières versions de ce format d’échange sont antérieures à la spécification XML, elles se reposent donc assez naturellement sur un format spécifique. Un message est composé de segments. Chaque segment est représenté par une ligne. Les trois premières lettres indiquent le type du segment. Un jeu de caractères spéciaux (^~& \ et |) permet de séparer les informations. Ainsi le message d’admission du patient William Jones (exemple tiré de la spécification HL7 2.5) ressemble à :

MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01^ADT_A01|MSG00001-|P|2.5| EVN|A01|198808181123||
PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M||C|1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL|(91-9)379-1212|(919)271-3434||S||PATID12345001^2^M10^ADT1^AN^A|123456789|987654^NC|
NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|

Peu lisible au premier coup d’œil, l’information est pourtant bien compartimentée et le format est efficace, à défaut d’être exprimé dans un format « standard ». Prenons un exemple : la date de naissance du patient venant juste d’être admis pour une hospitalisation se retrouve dans la « case » PID-7 (soit le 7^ème champ du segment PID), c’est-à-dire le 15/06/1961.

Le passage à XML

Comme toute organisation spécifiant des messages d’échange, HL7 s’est intéressée à XML, une fois la recommandation du W3C publiée. Seulement ce projet a été mal conduit. Seul le volet syntaxique a été mené, délaissant totalement le volet sémantique. Ainsi, le groupe de travail centré sur XML au sein de HL7 a produit un document proposant un algorithme de convertion de la notation classique à une version XML. Il s’agit là d’une traduction technique des champs et des segments en éléments XML. Le message d’admission précédent au format XML n’est pas insérable ici tellement sa longueur est rédhibitoire. En ne reprenant que le début du segment PID (jusqu’au champ 8), il est possible de se faire une première idée :

Avec le format classique

PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M||

En XML

<PID>
  <PID.1>1</PID.1>
  <PID.3>
     <CX.1>PATID1234</CX.1>
     <CX.2>5</CX.2>
     <CX.3>M11</CX.3>
     <CX.4><HD.1>ADT1</HD.1></CX.4>
     <CX.5>MR</CX.5>
     <CX.6><HD.1>MCM</HD.1></CX.6>
   </PID.3>
   <PID.3>
     <CX.1>123456789</CX.1>
     <CX.4><HD.1>USSSA</HD.1></CX.4>
     <CX.5>SS</CX.5>
   </PID.3>
   <PID.5>
     <XPN.1><FN.1>JONES</FN.1></XPN.1>
     <XPN.2>WILLIAM</XPN.2>
     <XPN.3>A</XPN.3>
     <XPN.4>III</XPN.4>
   </PID.5>
   <PID.7>
     <TS.1>19610615</TS.1>
   </PID.7>
   <PID.8>M</PID.8>
   .../...
</PID>

Ainsi chaque champ est entouré de balises qui n’exprime pas sa signification mais sa position technique relative au format original ! Le PID-7 se trouve donc dans l’arborescence <PID><PID.7><TS.1>…</TS.1></PID.7></PID>. Apparaissent également certains types de données. Par exemple, le PID-3 est composé de plusieurs éléments CX. En HL7, CX désigne un identifiant étendu.

Au final

• La lisibilité est sans doute pire que dans la version initiale,
• Les messages sont plus complexes, beaucoup plus longs (voir le graphique).

Alors, quel intérêt ?

• La communication entre deux logiciels ? Chaque logiciel capable de produire et de lire du HL7 utilise nativement la version texte. La transformation des messages dans les ESB ou les bus d’échange ? Il est certainement plus rentable de mettre en place un connecteur HL7.
• La génération automatique d’objets métier grâce à la définition de la grammaire XML (proposée par des librairies de type XMLBeans) ? La définition est tellement technique que cela ne représente aucun intérêt !
• La validation des messages ? Sans doute l’aspect le plus intéressant. Cependant, il faut savoir que les échanges de messages dans les SIH se basent certes sur les messages HL7, mais ils s’inscrivent également dans des transactions IHE. Le problème est donc complexe.

Conclusion

Si XML est devenu un passage obligé dans la définition de formats d’échange dans les SI, il ne doit pas être utilisé à mauvais escient. Il semblerait que l’exemple d’HL7 version 2.x montre assez bien ce qu’il ne faut pas faire : un projet technique avec un algorithme de conversion automatique. Sans sémantique, les messages XML n’ont aucun intérêt, se révèlent lourds, verbeux, difficiles à manipuler. Et par conséquent, ils ne sont pas utilisés. HL7 doit en être conscient puisque la philosophie XML de la version 3 (toujours en cours) est totalement différente !

Alors que Tiger - Java SE 5 - est disponible depuis peu et que Sun travaille sur GlassFish - Java EE 5 -, la planification des futurs composants de Mustang - Java SE 6 - est déjà disponible. Il s’agit bien sûr que d’une vue prévisionnelle, puisque sa sortie est prévue mi 2006, mais jetons d’ores et déjà un oeil sur les nouveautés, liées à XML, de cette future plate-forme.

Après avoir intégré de nombreuses technologies XML de bases dans les actuelles machines virtuelles Java, Mustang fait le choix de l’intégration des technologies relatives aux services web. Celles-ci, présentes du coté serveur (Java EE), arrivent du côté des applications clientes (Java SE). Ainsi, JAX-WS 2.0 (Java API for XML Web Services) et JAXB 2.0 (Java Architecture for XML Binding) font leur entrée dans Java 6.

Il s’agit là des deux évolutions majeures. Notons cependant que JAXP - Java API for XML Processing - passera en version 1.4, avec l’intégration de l’API d’analyse syntaxique StAX (JSR 173). Celui-ci est déjà inclus dans le WSDP 1.6 - Web Services Developer Pack. La signature numérique des documents XML - JSR 105, XML Digital Signature API - sera également intégré à Mustang.

JAX-WS 2.0 : Java API for XML Web Services
JAX-WS est la nouvelle appellation de JAX-RPC (Java API for XML Based RPC). En effet, JAX-RPC ne convient plus à l’ensemble des concepts couverts. Cet acronyme donne l’impression qu’il s’agit uniquement de technologies synchrones, relatives à l’appel de procédure à distance et non aux services web. De plus l’intégration de JAXB 2.0 pose de nombreux problèmes de compatibilité avec JAX-RPC 1.1. C’est ainsi l’occasion pour Sun de repenser, mettre à jour, améliorer et surtout rationaliser cette brique logicielle en utilisant les dernières nouveautés du langage lui-même, ainsi que les technologies développées en parallèle dans d’autres groupes de travail.

La volonté du groupe de travail est de supprimer les développements spécifiques - indispensables dans les versions antérieures, en raison de contraintes de calendrier - et de s’appuyer sur des composants éprouvés (JAXB) ou des standards (WS-*). Ainsi, si JAX-RPC 1.x utilise sa propre méthode de correspondance entre données XML et objets Java, JAX-WS 2 s’appuie désormais sur JAXB 2.0. JAX-WS 2.0 utilise également les nouvelles facilités du langage Java, introduites dans la version 5. Les annotations (JSR 175) utilisent des concepts, inhérents au langage Java et aux outils associés, qui facilitent le développement de scénarios classiques côté client mais également côté serveur. Elles déchargent le développeur de l’ajout d’informations jusqu’à lors nécessaires pour transformer un service classique en un service web. Certaines méta-données ont d’ailleurs été spécialement définies pour le compte des services web (JSR 181). Elles permettent de remplacer la technique de correspondance Java - WSDL, en annotant directement le code Java. Doug Kohlert - responsable technique de JAX-RPC - estime que ces nouvelles facilités permettent d’économiser une somme importante de code (en taille et en nombre) allant jusqu’à 85% d’économie. Ces facilités sont complétées par la JSR 109 - Implementing Enterprise Web Services - qui permet de déployer, de gérer et d’accéder à un service web par le biais d’un serveur d’application Java. Cette JSR couvre les modèles de programmation côté client - accéder à des services comme des objets distants traditionnels - mais aussi côté serveur - comment les services web peuvent être mis en oeuvre par une servlet ou un EJB.

Elle aborde également la façon de déployer ces services dans un serveur d’application. Pour compléter le tout, la JSR 183 - Web Services Message Security APIs - utilisée par JAX-WS aborde la sécurité des échanges de message SOAP.

La nouvelle mouture de JAX-WS est bien sûr l’occasion d’intégrer les dernières versions des standards utilisés. SOAP 1.2 est désormais supporté étant donné son statut de recommandation. Cependant, le support de SOAP 1.1, largement déployé, est assuré. WSDL 2.0 n’est pas encore une recommandation mais le sera certainement durant la cycle de vie de cette JSR, qui continuera d’offrir le support de WSDL 1.1. WS-I Basic Profile 1.1 supplante la version 1.0, actuellement supportée par JAX-RPC 1.1. Enfin, JAX-WS permet d’utiliser de façon optionnelle les récentes spécifications du W3C liées à l’optimisation de la transmission de données binaires dans des messages SOAP : MTOM/XOP (Message Transmission and Optimization Mechanism/ XML Binary Optimized Packaging).

Par ailleurs, JAX-WS 2.0 ajoute ou améliore certains concepts connexes. Une opération WSDL pourra désormais être asynchrone. Des mécanismes de gestionnaire d’événement (handler) et de consultation asynchrone de la réponse à une invocation (polling) sont mis en place dans cette JSR. JAX-WS 2.0 améliore aussi le développement de gestionnaires - logiques ou SOAP - permettant de suivre les messages échangés - leur contexte, leur sens de circulation - et d’accéder aux informations présentes dans les messages ou en-têtes. Autre point intéressant, la possibilité de gérer des versions d’un service web apparaît. Actuellement, l’évolution d’un service web est coûteux et délicat, cette JSR tente de faciliter l’évolution et le déploiement d’une nouvelle version d’un service web. Enfin, JAX-WS accentue également la séparation entre les données transportées (XML) et la couche transport, permettant ainsi de faire des invocations de services sur un protocole différent de HTTP. De plus, la gestion de session, liée à HTTP dans JAX-RPC 1.1, pourra se faire grâce à des informations présentes dans les messages SOAP.

Tant de changements impliquent des choix. Et JAX-WS en fait de nombreux. La correspondance données-XML est déléguée à JAXB. Il n’est pas prévu de fournir une possibilité évoluée de changer la technologie sous-jacente de “binding”. Cependant JAXB pourra être désactivé ponctuellement pour faire place à une technologie alternative. Contrairement à JAX-RPC 1.x, cette nouvelle version ne prendra pas en charge l’encodage SOAP 1.2. Cet usage est déprécié par WS-I Basic profile. Même si JAX-WS 2.0 offre un certain niveau de compatibilité ascendante, le fonctionnement du code issu de la génération de JAX-RPC 1.x n’est pas assuré. Il est donc nécessaire de modifier le code afin de s’insérer dans ce nouveau cadre. Enfin JAX-WS s’appuie sur de nombreuses fonctionnalités de Java 5 - annotation (JSR 175), génériques (JSR 14), types énumérés (JSR 201) … - le support des machines virtuelles antérieures ne sera donc pas pris en compte.

JAXB 2.0 : Java Architecture for XML Binding
JAXB 2.0 est l’évolution logique de la version 1.0, définie par la JSR 31. JAXB 2.0 supporte désormais l’ensemble des fonctionnalités définies dans XML Schema, ce qui n’avait pas été possible pour des raisons de calendrier dans la version 1 de JAXB. Là où JAXB 1.0 offrait une façon de partir du schéma pour arriver aux classes Java, JAXB 2.0 ajoute la possibilité d’avoir une correspondance bidirectionnelle. Par ailleurs, il est maintenant possible d’avoir une correspondance limitée à un fragment de document XML.

Alors que JAXB 1 n’assurait pas un processus invariable d’aller-retour entre XML et Java - un bean Java transformé en XML qui est de nouveau transformé en bean Java. JAXB 2.0 impose que ces transformations assurent l’invariabilité des données (Java et XML). La prise en compte d’un XML incorrect, aspect non-traité dans JAXB 1, sera définie. Un effort sur la portabilité des classes annotées permettra de conserver des classes issues d’une mise en oeuvre même si celle-ci est amenée à changer. Les classes JAXB 1 issues du schéma XML devaient être compatibles au niveau du code avec les implémentations JAXB 1, celles de JAXB 2 devront également être compatibles au niveau du bytecode. Enfin, l’utilisation des annotations des javabeans existants devrait permettre aux bibliothèques JAXB de générer automatiquement les objets responsables du chargement et de la sauvegarde de ces beans en XML.

A l’instar de JAX-WS 2.0, JAXB 2.0 fait également des choix. La JSR 222 utilise ainsi pleinement les facilités du langage Java 5, avec les conséquences de compatibilité avec les JDK antérieurs que cela engendre. Du côté des grammaires, seuls les schémas XML sont supportés. JAXB 2.0 part du principe qu’il est simple de convertir une DTD en Schéma - par l’intermédiaire de nombreux outils. La validation à la volée des classes java par rapport à des contraintes exprimées dans un schéma, supportée dans JAXB 1, n’est plus d’actualité dans JAXB 2.0. Enfin, à l’image de JAX-WS, JAXB n’utilise plus l’encodage SOAP, qui est remplacé par WS-I Basic Profile.

Cependant, à l’heure actuelle, il reste des points à préciser. JAXB se propose d’explorer les possibilités d’évolution de schémas, tant dans le domaine des applications centrées sur les données (services web) que dans le domaine des applications centrées sur les documents. JAXB 2.0 doit, par ailleurs, clarifier l’intégration et les relations avec StAX (JSR 173).

Sun a affiché très clairement, lors de la présentation des orientations futures de la plate-forme Java à JavaOne, sa volonté de renforcer la pile des technologies XML présentes dans la machine virtuelle et de faciliter le développement des services web. Graham Hamilton évoque que la version suivante (java 7 ou dolphin) poussera plus loin encore l’utilisation des services web en les mariant avec JMX pour offrir de l’administration à distance par le biais de services web. Il évoque également une possible intégration de XML au niveau même du langage Java. Cependant, cela reste à l’état de projet et ne verra pas le jour avant 2008.

Autres articles :

• La spécification JAXB 2.0 en relecture publique
• Java Web Services Developer Pack, version 1.6
• JAXP 1.3 et 1.4 disponibles

Voir aussi :

• Transparents JavaOne
• Java Platform Update: Roadmaps & Big Directions
• Projet Mustang
• Core Java Technology Features in Mustang
• Kirill Grouchnikov’s Blog : Native XML support in Dolphin

Liste des JSR relatives à XML et aux services web :

• JSR 31 : XML Data Binding Specification
• JSR-101 : JavaTM APIs for XML based RPC
• JSR 105 : XML Digital Signature
• JSR 222 : JavaTM Architecture for XML Binding (JAXB) 2.0
• JSR 224 : JavaTM API for XML-Based Web Services (JAX-WS) 2.0
• JSR 181 : Web Services Metadata for the JavaTM Platform
• JSR 183: Web Services Message Security APIs
• JSR 173 : Streaming API for XML

L’inclusion de fichier est un problème classique, existant depuis les premiers programmes informatiques, quelle que soit la technologie. Curieusement, les spécifications XML (1.0 et 1.1) n’ont pas abordé cette question. Heureusement cinq années après XML 1.0, XInclude vient combler ce manque. Magazine Login: n°129, juin 2005 - Frédéric Laurent

Les longs fichiers monolithiques ont toujours posé des problèmes. A l’inverse, les fragments de fichier permettent de gagner en robustesse, en simplicité de gestion, en factorisation, en partage d’informations, etc. Si c’est vrai pour les programmes (import java, include en C…), ça l’est également pour les documents. Cinq documents de vingt pages sont nettement plus aisés à maintenir et à faire évoluer qu’un long document de cent pages (surtout dans les environnements collaboratifs).

XML n’est pas épargné par ce problème. En ajoutant des balises permettant d’exprimer la structure d’un document, XML enrichit l’information utile, mais la surcharge. Le document est plus gros et plus long. Pouvoir le découper permet de mieux le maîtriser, de réutiliser et de partager les sous-documents et d’assurer une cohérence qui ne peut l’être en dupliquant la même information dans de multiples fichiers. Les exemples d’utilisation sont légion. Un entête et une information sur des droits d’auteur répétés dans chaque page web XHTML, un livre découpé en plusieurs chapitres, des paramètres généraux inclus dans des fichiers de configuration, etc…

Figure 1 : Inclusion d’un fichier
python dans un document XHTML

Cependant, ce sujet semble avoir été oublié par les spécifications et ne fait donc pas partie du coeur de XML. Plusieurs solutions ont donc été imaginées pour faire des inclusions : par exemple, l’utilisation des instructions de traitement ou des entités externes.

Si les instructions de traitement ont l’avantage de pouvoir être placées à tout endroit du document et de ne pas être intrusives pour la DTD ou le schéma (aucune déclaration nécessaire), elles présentent un inconvénient de taille. Elles demandent un traitement spécifique de la part de l’application qui doit reconnaître l’instruction, la traiter et ainsi gérer l’inclusion du fichier. De plus, le processus de gestion des erreurs est totalement déporté dans l’application, voire inexistant.

Une autre solution, l’utilisation des entités externes, s’est plus largement répandue. Elle se base sur un mécanisme défini par les DTD. Il s’agit de déclarer une entité qui fait référence à un fichier externe, désigné par son URI (voir listing 1). Lors du traitement du fichier XML, le processeur remplacera chaque appel d’entité par son contenu. Le processeur lira donc le contenu du fichier externe désigné et procédera au remplacement de l’appel d’entité.

Cependant, ce système d’inclusion est confronté à de nombreuses limitations. Le document inclus ne peut pas être un document XML bien formé de façon globale, car les déclarations <!DOCTYPE> et <?xml ?>ne peuvent pas être présentes et le document importé peut contenir deux racines. Par ailleurs, il n’est pas possible d’importer un document qui n’a pas une syntaxe XML. L’inclusion d’un fichier java devant figurer dans un document XHTML technique est impossible. Si un problème survient lors du chargement du fichier désigné par l’entité, le processeur provoque une erreur fatale. Aucune gestion des erreurs n’est donc possible. De plus, seule la totalité du document peut être importée. Une inclusion plus fine, c’est-à-dire, une inclusion d’un fragment de document est impossible. Enfin, les entités nécessitent d’être déclarées dans le sous-ensemble interne (voir le listing 1) ou dans la DTD. C’est un processus intrusif qui peut avoir des répercutions désagréables.

<?xml version="1.0"?>
<!DOCTYPE html [
  <!ENTITY haut SYSTEM "head.xml">
  <!ENTITY bas  SYSTEM "tail.xml">
]> 

<html>
  <head><title>test entite</title></head>
  <body>
    &haut;
    <p>texte du document</p>
    &bas;
  </body>
</html>

Listing 1 : inclusion à l’aide d’entités externes

L’inclusion avec XInclude

XInclude permet de faire l’inclusion d’un document XML entier, d’un fragment de document XML ou d’un fichier non XML. Le mécanisme est très simple. Il se compose de deux éléments : include et fallback. Ces deux éléments sont présents dans un espace de noms qu’il faut déclarer. L’espace de noms http://www.w3.org/2003/XInclude est souvent associé au préfixe «xi», bien que le préfixe ne soit pas important puisque seul l’URI compte. Le listing 2 montre un exemple simple d’inclusion.

<!DOCTYPE html PUBLIC
   "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"
   lang="fr" xmlns:xi="http://www.w3.org/2001/XInclude">
  <head><title>test xinclude</title></head>
  <body>
    <xi:include href="head.xml" mce_href="head.xml"/>
    <p>texte du document</p>
    <xi:include href="tail.xml" mce_href="tail.xml"/>
</body>
</html>

Listing 2 : inclusion grâce à XInclude

L’élément XInclude

Les attributs de cet élément en détail… (lire la suite)

L’élément xi:includedéfinit six attributs : href, parse, xpointer, encoding, accept et accept-language (voir encadré 2). Ils permettent de fournir l’information nécessaire en terme de localisation (du fichier et de la zone réelle à inclure qui peut être une partie du fichier), d’encodage et de négociation de contenu. L’inclusion est récursive. Chaque fragment inclus est analysé à son tour et les inclusions qu’il définit sont traitées. Les inclusions circulaires sont détectées et ne peuvent pas aboutir à un processus infini. XInclude permet d’inclure des données, XML ou non, en les considérant comme non-analysables. Cette fonctionnalité, forte intéressante, permet alors d’intégrer des documents Java, C#, python ou même XML dans un autre document (figure 1). Dans ce traitement spécial, les caractères de balisage sont échappés. Le caractère ‘<’, par exemple, est transformé en < ;

Négociation de contenu

L’inclusion de fichier peut faire intervenir des serveurs HTTP locaux ou distants. Certains offrent une gestion de contenu fine, c’est-à-dire prenant en compte la valeur des paramètres accept et accept-language des requêtes HTTP, et ne se contentent pas de renvoyer la même page quelles que soient ces valeurs. Il s’agit de la négociation de contenu. Selon la valeur de ces paramètres, fixée par le client par le biais de ses préférences, le serveur cherche la représentation de la ressource qui correspond la mieux.

Figure 4 : La négociation de contenu
permet d’obtenir des versions différentes
d’une même ressource

XInclude fait l’analogie avec les en-têtes HTTP, puisque l’expression des préférences en matière d’inclusion se fait par l’ajout des attributs accept et accept-language. Le premier définit le format souhaité de la ressource demandée, c’est-à-dire html, text, xml, etc. Le second permet d’exprimer la préférence quant à la langue, il s’agit d’une valeur ayant la forme, fr-Fr, fr, en-us, etc. Une valeur “fr-fr, en” signifie : je préfère une représentation en langue française utilisée en France, par opposition au français utilisé au Canada par exemple, mais j’accepte aussi toute forme de ressource en langue anglaise. Ainsi, il est possible de demander une version française et html d’une page web ou cette même page dans un format XML et en anglais. Par exemple, le serveur web qui héberge la documentation du serveur apache permet d’utiliser la gestion de contenu. Il délivre un URL différent selon la langue choisie. Dans l’exemple suivant, la page française est demandée:

<xi:include href="http://httpd.apache.org/docs-2.0" mce_href="http://httpd.apache.org/docs-2.0"
        accept-language="fr"  accept="text/html"/>

La figure 4 montre un exemple plus détaillée d’utilisation de la négociation de contenu avec ce site.

Gestion d’erreur

L’inclusion de document externe est sujette à tous les problèmes de défaillances informatiques classiques. Le fichier peut être absent, il peut être inaccessible en raison d’un échec du réseau, d’un blocage de requête par un proxy, d’une suppression de la ressource par un tiers, ainsi de suite… La possibilité de définir un comportement en cas d’échec de l’inclusion constitue un apport non négligeable de Xinclude. Cette possibilité était une carence de l’inclusion faite avec les entités externes. L’élément xi:fallback permet de spécifier ce comportement. C’est un élément fils de l’élément xi:include. Son contenu sera inséré à la place de l’élément xi:include en cas d’erreur. Le contenu de xi:fallback est libre. Il peut s’agir d’un simple texte, d’un fragment de document ou d’une nouvelle instruction xi:include, comme nous pouvons le voir dans le listing 3.

<body>
  <xi:include href="head.xml" mce_href="head.xml">
      <xi:fallback>
        <xi:include href="errHead.xml" mce_href="errHead.xml"/>
      </xi:fallback>
  </xi:include>
  <p>texte du document</p>
  <xi:include href="tail.xml" mce_href="tail.xml">
      <xi:fallback>Probleme d'inclusion</xi:fallback>
  </xi:include>
</body>

Listing 3 : gestion des erreurs

L’inclusion conditionnée par la détection d’erreur est intéressante à plus d’un titre. Imaginons l’inclusion d’un document externe EnteteComplexe.xml (listing 4).

<xi:include href="EnteteComplexe.xml" mce_href="EnteteComplexe.xml">
   <xi:fallback>
      <xi:include href="EnteteSimple.xml" mce_href="EnteteSimple.xml">
         <xi:fallback>erreur d'inclusion du fichier
         externe et du fichier alternatif </xi:fallback>
      </xi:include>
   </xi:fallback>
</xi:include>

Listing 4 : inclusion alternative en cas d’erreur

Si celui-ci n’est pas atteignable, un document alternatif, EnteteSimple.xml, sera inclus. Mais s’il ne peut l’être, suite à une nouvelle erreur de localisation du fichier par exemple, on peut imaginer un simple texte laconique, qui sera présent dans le document original et sera donc toujours disponible. Dans tous les cas, la gestion d’erreur est traitée correctement.

L’inclusion partielle

Xinclude permet de faire des inclusions partielles de document. La technologie XPointer permet d’y parvenir. Elle est utilisée à travers l’attribut xpointer de l’élément xi:include. Les processeurs ne sont pas obligés de fournir un support complet de XPointer, seuls le schéma element() et les pointeurs abrégés sont obligatoires. Par ailleurs, certains processeurs, comme celui de libxml ou XInclude.net, offrent la possibilité d’utiliser les schémas xpointer() et xmlns(). Par exemple, l’inclusion ci-dessous permet d’avoir la liste de l’ensemble des documents techniques (Technical Reports ou TR) du W3C, dont le sujet contient RDF :

<xi:include href="http://www.w3.org/TR" mce_href="http://www.w3.org/TR"
  xpointer="xmlns(html=http://www.w3.org/1999/xhtml)
  xpointer(//html:dt[@class='TR']/html:a[contains(
  text(),'RDF')])">

Figure 2 : Inclusion d’un fragment de
document distant en utilisant XPointer

Dans l’attribut xpointer, le schémaxmlns() permet de déclarer l’espace de noms du document référencé. Cet espace de noms sera utilisé pour localiser l’information dans le schéma xpointer(). Le contenu du schéma xpointer est une expression XPath, dont une version française pourrait être : “toutes les balises <a> qui ont pour élément père une balise <dt>, dont l’attribut class vaut TR, et dont le contenu textuel (de la balise <a>) contient le texte RDF” (figure 2).

Support de xml:base

XInclude utilise la spécification du W3C xml:base. Le processeur XInclude positionne l’attribut xml:base sur la balise racine du fragment inclus, de sorte que chaque lien relatif, contenu dans le fragment, soit correct. Ainsi deux liens vers doc.xml ne pourront pas être confondus car ils seront relatifs à l’URL spécifié par leur attribut parent respectif. Par exemple, l’incorporation de la liste des technologies proposées par le W3C ne pose pas de problème relatifs aux liens hypertextes, grâce au positionnement d’un attribut xml:base. Les liens ne sont pas modifiés (<a href="/amaya/" mce_href="/amaya/">Amaya</a>) et l’URL est correct car il est chapoté par une déclaration xml:base permettant de construire le lien cible (voir figure 3).

Figure 3 : Le processeur insère un attribut
xml:base rendant les URL consistants

xml:base peut également être utilisé par le document faisant l’inclusion. Les inclusions seront alors spécifiées relativement à cette base, évitant de ressaisir les URI complets. Cette facilité apporte non seulement de la lisibilité mais aussi de la robustesse car le risque d’erreur dans les URI est diminué.

<doc xml:base="http://www.site.org/mondocument">
  <xi:include href="chapitre1.xml" mce_href="chapitre1.xml" />
  <xi:include href="chapitre2.xml" mce_href="chapitre2.xml" />
  <xi:include href="chapitre3.xml" mce_href="chapitre3.xml" />
</doc>

Quelques limitations

Malgré ses nombreux atouts, XInclude présente quelques désagréments. Cette spécification a pris pas de moins de cinq années pour voir le jour. Ce temps extrêment long dans le domaine des formats XML, a vu éclore nombre de spécifications ne prenant pas en compte XInculde, jugé dans un état instable. Ainsi les définitions de schémas (DTD, XML Schémas, schémas RelaxNG, etc) ont fait l’impasse sur XInclude et cela vient perturber la validation. Il faut en effet déclarer l’espace de noms XInclude pour permettre au processeur de traiter les balises d’inclusion, mais cette déclaration reste dans le document après la transformation. Une spécification XHTML, même récente, ne s’attend pas à trouver une déclaration xmlns:xi="http://www.w3.org/2003/XInclude" sur sa racine.

Support de XInclude

De nombreux processeurs mettent déjà en œuvre XInclude mais de façon très inégale (lire la suite)

Le document, après inclusion sera donc invalide. L’ajout par le processeur de l’attribut xml:base pose le même type de problème. Plusieurs solutions sont envisageables. On peut imaginer de ne pas valider le document résultant, de modifier les grammaires pour prendre en compte ce genre d’information ou encore de définir au niveau même de XML, que les attributs xmlns ou xml:* peuvent être présents à tout endroit dans un document et ne doivent pas être pris en compte par la validation. Quoi qu’il en soit, cet inconvénient risque de prendre du temps avant qu’il ne soit totalement résolu.

Une option à explorer

XInclude vient remplacer l’utilisation délicate des entités externes. Cette nouvelle spécification comble ainsi un manque important dans l’espace XML et formalise un mécanisme d’inclusion robuste, qui utilise les concepts XML fonctionnant par ailleurs (élément, URI, espace de noms, xml :base). Même si certains questions restent posées, notamment sur la post-validation, et que la mise en oeuvre de cette spécification par les processeurs est aujourd’hui disparate, XInclude repésente une avancée vraiment intéressante pour les documents orientés données. Le développement rapide de cette technologie permet d’envisager à terme un support natif par les navigateurs Internet, fournissant alors la possibilité de faire des inclusions dans les pages XHTML.

Les sources de l’article

• XInclude avec XOM : TestInc.java
• test de accept : xi-accept.html
• test de xpointer xi-xpointer.html