1snajaint.free.fr/livreblanc/XML_et_son_utilisation_pour_l'E… · Web view- III - XML et son utilisation pour l'EDI Autour d'une grammaire aussi simple que rigoureuse, en s'appuyant

- III - XML et son utilisation pour l'EDI

Autour d'une grammaire aussi simple que rigoureuse, en s'appuyant sur vingt ans de travaux en matière de documentation structurée et sur une norme ISO, en allégeant les contraintes et en assurant une communication étonnamment efficace, le Web consortium a mis en route, avec XML, une transformation profonde de la manière dont les systèmes d'information vont être perçus et conçus.

XML est d'abord et avant tout la concrétisation de la prééminence croissante du réseau et de la communication par rapport à une vision statique et fermée des univers informationnels.

La boîte de Pandore est ouverte. Le bouleversement est énorme, et tous les aspects des systèmes d'information sont affectés.

Certains, comme Tim Berners Lee, considèrent que tout développement impliquant des échanges de données et n'utilisant pas XML doit être sérieusement justifié. C'est aussi lui qui a dit que "You ain't seen nothing yet". Il dispose de quelque crédibilité, en tant que développeur initial du Web.

D'autres, eux aussi assez crédibles, comme Microsoft, considèrent que toute communication entre applications doit être écrite en XML. Cette position de Microsoft ne fait pas peu pour le prestige de cette technique, surtout quand on considère que Sun, IBM et quelques autres la partagent assez largement et s'investissent.

Cependant, comme toujours en informatique, le problème est le temps de développement. Il ne faut donc pas sauter aux conclusions, comme les médias y pousseraient parfois, et penser que tous les problèmes soulevés par l'introduction d'XML vont être réglés rapidement. De même, il n'y a pas de raison que la nouvelle technique facilite la mise en place de systèmes de communication qui posent de redoutables problèmes d'organisation et de concurrence. En outre, comme toujours aussi, il serait absurde de changer des systèmes qui fonctionnent avant que cela devienne indispensable.

CANOPE – tenorCONSEIL 2

Surtout, il suffit de considérer la cartographie des groupes qui développent des applications et travaillent à modifier à peu près tous les aspects de l'informatique pour comprendre que la reconstruction de la maison commune ne va pas pouvoir se réaliser

en très peu de temps. Certaines applications vont donc être rapidement disponibles, alors que d'autres sont encore assez éloignées dans le temps.

C'est cette évolution qu'il convient de suivre et d'apprécier.

Par ailleurs, et en raison même de cette situation, il est très difficile et pour partie illusoire de vouloir faire le point sur le développement d'XML. Littéralement des centaines de groupes de travail, qui s'expriment dans autant de sites sur le Web, sont actuellement actifs.

Plus encore que cela n'a été le cas avec le Web jusqu'ici, il va falloir vivre dans un monde en constante évolution pendant une longue période.


SOMMAIRE

1. Un métalangage universel sur le réseau.................................................7

1.1. Historique.........................................................................................................7

1.1.1. SGML........................................................................................................71.1.2. L'émergence d'HTML avec Internet..........................................................91.1.3. Le développement d'XML.........................................................................9

1.2. Les principes..................................................................................................10

1.2.1. Un meta langage, non un langage ou une syntaxe...................................101.2.2. Le transport de structures dans du texte..................................................11

1.3. Le document XML........................................................................................12

1.3.1. Les principes généraux............................................................................121.3.2. La définition de la structure d'un document............................................131.3.3. DTD : La définition de type de document...............................................151.3.4. Les Schémas XML (Le langage "XML Schema")..................................17

1.4. Langages de présentation et de transformation des documents...............22

1.4.1. Langage de feuille de style : CSS............................................................231.4.2. Langage de feuille de style : XSL...........................................................231.4.3. Langage de transformation : XSLT.........................................................24

1.5. XML Namespace : Espace nominal.............................................................25

1.6. Autres langages et standards : vers les outils..............................................27

1.6.1. Les langages de lien d'adressage : XPATH, XLINK et XPOINTER......271.6.2. Mécanismes de manipulation des documents XML : API (interfaces de

programmation applicatifs)......................................................................321.6.3. Format d'interchange de méta données : XMI.........................................341.6.4. Les annuaires : DSML.............................................................................361.6.5. Cadre de description des ressources : RDF.............................................37

1.7. Tendances et enjeux : les référentiels..........................................................38

1.7.1. XML : un méta langage et des outils conçus pour le réseau...................381.7.2. Les répertoires et serveurs de schémas : l'enjeu et les stratégies.............40


2. Domaines d'application......................................................................45

2.1. La diversité des usages et la nécessité d'une approche globale.................45

2.2. L'échange inter-applications........................................................................46

2.3. La publication sur le Web ou les Intranets, les portails.............................47

2.3.1. Création de pages dynamiques................................................................482.3.2. Transmission de données et mises à jour................................................492.3.3. Présentation sur de multiples supports....................................................492.3.4. La personnalisation..................................................................................512.3.5. Les portails..............................................................................................522.3.6. Le retour utilisateur : WebDAV..............................................................522.3.7. Un Web de plus en plus dynamique........................................................52

2.4. XML pour la gestion des données................................................................53

2.4.1. XML et la gestion de contenu / GED......................................................532.4.2. XML pour créer et maintenir un référentiel de données normalisées.....582.4.3. XML outil de création et de gestion de méta-données............................582.4.4. XML comme format de stockage de données.........................................59

2.5. XML comme outil informatique de base.....................................................59

2.5.1. L'unité d'un ensemble de technologies nouvelles : modélisation objet et XML.........................................................................................................60

2.5.2. XML pour mise en relation des applications et informatique répartie.........................................................................................................................62

2.5.3. XML ne remplace pas tout…..................................................................65

3. XML EDI.............................................................................................67

3.1. "Comparaison" de solutions EDIFACT XML...........................................67

3.1.1. L'économie des produits et services........................................................683.1.2. Une vue d'ensemble.................................................................................693.1.3. Qualité et conditions de mise en œuvre...................................................70

3.2. XML et le commerce électronique...............................................................71

3.2.1. Des applications verticales......................................................................723.2.2. Des applications spécialisées...................................................................733.2.3. Projets généraux......................................................................................74


3.3. La normalisation EDI, ebXML....................................................................76

3.3.1. Impact d'XML sur les travaux de normalisation EDI..............................763.3.2. Les principaux problèmes pour faire de l'EDI en XML..........................793.3.3. ebXML : les fondements.........................................................................803.3.4. Le transport des messages XML via Internet..........................................823.3.5. Registres et répertoires............................................................................853.3.6. Modèle et sémantique..............................................................................873.3.7. La vision du commerce électronique de ebXML....................................873.3.8. Un exemple de scénario...........................................................................883.3.9. Des développements................................................................................893.3.10. Une avance rapide...................................................................................92

3.4. La sécurité des échanges...............................................................................92

3.4.1. Signature XML........................................................................................923.4.2. PPP : Platform for Privacy Preferences...................................................933.4.3. La carte : SmartXML de la société GEMPLUS......................................93

3.5. XML et l'évolution de l'Edi..........................................................................95

4. L'état d'un immense chantier..........................................................100

4.1. Une prolifération de logiciels en développement......................................100

4.1.1. Des fonctions.........................................................................................1004.1.2. Des catalogues.......................................................................................1004.1.3. Une communauté mondiale de développeurs et des systèmes i

ndustrialisés...........................................................................................103

4.2. Impact d'XML sur l'informatisation.........................................................104

4.2.1. Un impact actuel fort mais caché..........................................................1044.2.2. Impact économique...............................................................................1054.2.3. Impact sur l'organisation de l'informatique...........................................105


XML pour l'EDI juin 2 000Etude pour la CNAV et la MTIC- III - XML

1. Un métalangage universel sur le réseau

1.1. HistoriqueTechniquement, XML résulte de la rencontre entre SGML et le Web. Pratiquement, il répond au besoin de l'échange de données généralisé, dans les entreprises comme sur Internet, et à la pression des besoins du commerce électronique.

1.1.1. SGML

XML est au départ une forme restreinte de SGML, le langage normalisé de balisage généralisé, objet de la norme ISO 8879 : 1986. SGML est utilisé principalement pour créer et gérer des documentations techniques complexes et volumineuses. XML, langage de description et d'échange de données structurées est développé dans le but d'une utilisation sur le Web. Par construction, les documents XML sont des documents conformes à SGML.

Cependant, il faut indiquer d'emblée que XML est aussi un nouveau développement de la norme et qu'il se complexifie avec la prise en compte de nombre de nouveaux outils, la plupart orientés vers l'accessibilité et la communicabilité sur le réseau.

…XML, comme SGML est un langage de balisage. Le principe est d'introduire à l'intérieur de fichiers texte des éléments d'information de structure, exprimés dans des balises qui encadrent des éléments du document. La définition des balises et l'organisation de la structure, si nécessaire, sont externes au document (dans une "définition type" ou un autre type d'information). Les balises indiquent le nom de l'élément et fournissent des informations complémentaires dans des attributs, comme des valeurs, des renvois à des références etc.)Leur définition externe éventuelle précise des caractéristiques concernant les éléments correspondants. En particulier, cette définition peut indiquer si l'élément considéré en contient obligatoirement d'autres (comme par exemple "une adresse doit contenir un nom de pays"). Le nom peut avoir trait à la nature de



l'élément (prix-unitaire, ou ville-de-residence etc.), à son rôle dans le document (titre, note etc.) ou à tout autre aspect. Le choix des noms, définitions de balises est libre (compte tenu de règles sur les caractères). De tels ensembles de balises et de contraintes constituent en fait des langages. Précisément, c'est parce qu'XML lui-même est un metalangage qu'il donne cette possibilité de création de langages. Une fois ceux-ci définis, en revanche, les outils vérifiant la conformité à la grammaire seront non tolérants aux erreurs. Les règles fondamentales sont simplesRappel : bien que HTML soit une application très simple de SGML, il a introduit de mauvaises interprétations parce que les règles en question ne sont pas strictement respectées. Elles le sont en XML.Règles de base : Tout élément est encadré par une balise de début et une balise de fin.Les éléments peuvent s'imbriquer mais jamais se chevaucher. La structure fondamentale de tout document XML est donc un arbre, et tout document est contenu dans un élément racine unique, qui contient tous les autres.

Langages de balisage : le principe

DocumentStructure type

Définition etorganisation deséléments(balises, structure)

< >A< > (relation B C) B< >C

logiciel de validation et d’analyse(“parseur”)ou simplement

règlesde grammaire+ dictionnaires

< ><

>

< > < >

< >>

<

/AAB

C /C

/B

ou...



1.1.2. L'émergence d'HTML avec Internet

Les développeurs du Web avaient besoin d'un outil permettant d'afficher des informations sur des systèmes divers, des formats d'écran divers. Ils se sont tournés vers la seule solution qui était à leur portée, c'est-à-dire SGML, et ils ont rapidement développé une application particulière de SGML, une DTD (définition de type de document, cf. infra). Cette DTD, ensemble de règles pour produire un document, est un peu étrange du point de vue SGML, puisqu'elle associe des informations de structure et des informations de présentation, ce que précisément SGML a pour vocation d'éviter.

Cette caractéristique d'HTML le rend peu évolutif car les limites apparaissent rapidement, tant pour véhiculer des informations que pour effectuer des présentations.

De plus, il fallait qu'HTML soit très tolérant, ou plutôt que les navigateurs soient tolérants aux erreurs et au non respect de règles pourtant strictes de la grammaire SGML.

En choisissant de développer ainsi HTML, le W3C a permis le succès impressionnant du langage et du Web. Cependant, la liberté laissée aux développeurs a rapidement conduit à des divergences et à des difficultés croissantes. Elles sont compensées par la simplicité d'un langage qu'un nombre croissant de personnes maîtrisent.

C'est bien la diffusion d'HTML qui a conduit à XML, car le besoin de véhiculer des données est apparu, et la crédibilité était acquise, alors qu'auparavant, SGML avait une réputation de technique complexe et chère. Le seul défaut peut être que la diffusion d'HTML suscite des confusions : il n'y a pas à comparer HTML et XML.

1.1.3. Le développement d'XML

Le développement de XML, langage de balisage extensible, en anglais Extensible Markup Language, a débuté en 1996. En février 1998, la première version 1.0 des spécifications de XML a fait l'objet d'une recommandation du W3C (Word Wide Web Consortium). Cette reconnaissance fait de XML une norme industrielle de fait.

Les objectifs de conception de XML sont les suivants :

XML doit pouvoir être utilisé sans difficulté sur Internet ; XML doit soutenir une grande variété d'applications ; XML doit être compatible avec SGML ; Il doit être facile d'écrire des programmes traitant les documents XML ; Le nombre d'options dans XML doit être réduit au minimum, idéalement à aucune ; Les documents XML doivent être lisibles par l'homme et raisonnablement clairs ;



La conception de XML doit être préparée rapidement ; La conception de XML doit être formelle et concise ; Il doit être facile de créer des documents XML ; La concision dans le balisage de XML est de peu d'importance.

XML, comme SGML, impose et permet une séparation stricte entre :

la structure : la définition de la structure d'un document, le contenu : la description du contenu d'une occurrence du document, et la présentation : la "mise en page" du document.

Cette séparation apporte une indépendance du document par rapport aux évolutions technologiques matérielles et logicielles et ainsi une pérennité d'utilisation à court et moyen terme. C'est cette caractéristique de séparation entre structure, contenu et présentation qui va favoriser l'utilisation de XML dans l'échanges d'informations entre applications informatiques.

1.2. Les principesXML est défini par un ensemble de recommandations, publiées sous l'égide du W3C. Les paragraphes suivants présentent ces différentes recommandations. La première d'entre elles, nommée1.0, est la définition du langage de base à partir du quel un ensemble d'extensions vont être élaborées.

XML : Langage de balisage extensible (XML) 1.0 - Recommandation du W3C, 10 février 1998

http://www.w3.org/TR/1998/REC-xml-19980210

1.2.1. Un meta langage, non un langage ou une syntaxe

Cette recommandation énonce les spécifications de XML. Elle définit un métalangage, c'est à dire un langage permettant de décrire d'autres langages, en précisant l'ensemble des règles et stratégies autour desquelles un document XML doit être désigné, structuré, et construit.

Ces règles constituent ce qui est appelé la grammaire formelle de XML.


http://www.w3.org/TR/1998/REC-xml-19980210


Le terme "formel" est a prendre au sens mathématique, c'est à dire qu'il signifie "non ambigu". Cette grammaire est décrite à l'aide d'une notation mathématique appelée notation simple de forme Backus-Naur étendue (EBNF). La forme de Backus-Naur est le standard technique pour définir la syntaxe d'un langage informatique. Elle permet de décrire un langage de programmation, un protocole ou dans le cas présent un document XML. Elle n'est pas née de la "génération Internet" mais est utilisée de longue date pour spécifier des langages de programmation tel que Pascal, Ada ou autres.

Cet aspect théorique des fondements mathématiques de XML, bien que quelque peu hermétique, pourra être apprécié comme déterminant dans une comparaison des langages EDIFACT et XML.

1.2.2. Le transport de structures dans du texte

En se plaçant du point de vue de l'utilisateur, il a pu être écrit que XML est tout simplement un moyen de transporter des structures de tous types dans un fichier ASCII.

XML permet en effet de transporter des informations structurées dans un format unique, dans un fichier texte. Cela lui confère une grande universalité. En dehors du monde de la documentation technique, les informations structurées sont pour l'essentiel gérées dans des bases de données, actuellement le plus souvent selon un schéma en tables relationnelles. Il ne s'agit pas de revenir sur ce très puissant niveau de structuration mais de permettre d'une part de gérer des documents riches (et non les informations habituelles des bases de données, organisées en champs et structurées de façon très rigide), d'autre part d'échanger des données et documents entre les multiples bases de données et applications des entreprises.

Une structure exprimée en texte va ainsi permettre la convergence entre le monde du document (un livre, mais aussi un formulaire ou un bon de commande) et le monde de la donnée, avec ses requêtes structurées (SQL), ses fonctionnements client-serveur etc. Des interfaces seront intégrés aux bases de données qui leur permettront de produire des documents XML à partir d'un enregistrement ou d'un ensemble d'enregistrements. Le fait que XML soit un standard très répandu conduira les offreurs de gestionnaires de bases de données à intégrer des outils élémentaires pour produire ou interpréter les documents XML, alors que, pour d'autres solutions, comme EDIFACT, tout le travail repose sur des traducteurs et souvent des interfaces ad hoc.

Cette universalité d'XML va en particulier permettre d'inscrire (d'imbriquer) un extrait de base de donnée à l'intérieur d'une page HTML dynamique et de fournir ainsi, aisément et de façon standard, des informations à jour dans les sites Web.



Les schémas qui suivent indiquent les principes d'utilisation d'XML, dans les applications les plus simples actuelles.

1.3. Le document XML

1.3.1. Les principes généraux

Un document XML est un ensemble de données structurées. Ce peut être une transaction commerciale, administrative ou financière, un tableau, un annuaire, des paramètres de configuration ou un catalogue de dépannage.

Exemple :

<liste-messages-panne>

<message>

<description>FUITE HUILE MOTEUR</description>

<marque-vehicule>PEUGEOT</ marque-vehicule >

<type>MAU000AKL683</ type >

<numero-panne>HM003</numero-panne>

<procedure-reparation href="pr.xml" title="Procedure de reparation" show="new" content-role="reference" >PSA HM003-01</procedure- reparation>

</message>

<message> . . </message>

</liste-messages-panne>

L'exemple, ci-dessus, met en évidence différents composants d'un document XML ; des données analysables "PEUGEOT", "HM003", et des balises <marque-vehicule>. Le balisage <liste-messages-panne>, <message>, </message>, </liste-messages-panne> décrit la structure du document.

XML, à l'opposé de HTML, autorise une personnalisation du système de balisage. L'auteur d'un document va pouvoir définir son propre jeu de balises. Cette caractéristique est "la meilleure et la pire des choses". Elle donne la possibilité à l'auteur



d'un document de décrire la sémantique associée aux données transmises, c'est à dire d'indiquer le sens précis qu'il donne à l'élément transmis. Cette faculté ouvre des possibilités importantes de traitements des données, mais va nécessiter la mise en œuvre de méthodes et de moyens non moins importants pour garantir que la sémantique d'un document est bien partagée par les utilisateurs et destinataires de l'information.

L'exemple, ci-après, met en évidence qu'un même terme, utilisé en tant que balise, peut avoir plusieurs sens et que le seul usage du système de personnalisation des balises est insuffisant pour répondre aux besoins de sémantique dans l'échange d'information :

<titre>Directeur</ titre >, <titre>Discours de la méthode</ titre >

Notre langue naturelle n'est malheureusement pas formelle !

XML distingue deux types de documents :

Les documents "bien formés" : Ce sont des documents qui respectent les règles grammaticales de XML. Des logiciels, parseurs XML, réalisent l'analyse syntaxique du document pour vérifier la bonne application des règles. Les documents "valides" : Ce sont des documents XML "bien formés" respectant en plus des contraintes de structuration. Elles sont précisées par une DTD : Définition type de document ou un Schema XML associé au document.

1.3.2. La définition de la structure d'un document

Afin de faciliter l'échange et le traitement de documents, il est apparu nécessaire de bâtir des référentiels de structures types de documents. Ces structures peuvent être définies et partagées par des communautés d'utilisateurs afin de garantir une cohérence structurelle et sémantique dans l'usage des documents.

La définition de ces structures est en fait une production de langage. XML comme SGML permettent d'écrire aussi bien des structures mathématiques (MathML) que des structures de flots multimédia (SMIL) ou celles de documents juridiques ou commerciaux.

Dans l'histoire des langages balisés, les structures ont d'abord été celles de documents statiques lourds, puisque SGML était destiné à gérer des documentations techniques de porte-avions… Le mécanisme défini dès les début a été la DTD - Document Type Definition (elles seront reprises ci-après car elles sont aujourd'hui le seul outil stabilisé).

Les limites des DTD ont rapidement été atteintes, s'agissant de transférer de façon très souple des informations sur Internet. Après de nombreuses propositions, c'est une définition beaucoup plus riche qui est en cours de mise au point avec le langage de schémas.



Les choses vont très vite sur le Web. Après XML-Data en janvier 1998 (Microsoft, proposition qui devait conduire aux schémas), DCD en août 1998, (Document Content Description), SOX en septembre 1998, (Schema for Object-oriented XML) et DDML en janvier 1999, (Document Definition Markup Language), le Web Consortium et l'ensemble des acteurs se sont orientés vers la définition d'un langage combinant les apports des différentes propositions.

En décembre 1999, la première spécification de XML Schema était proposée par le W3C. Ce document en deux parties (Part 1 : Structures, Part 2 : Datatypes) a fait l'objet d'une première publication (un "draft") du Web Consortium en février 2 000. Les schémas sont discutés actuellement, le draft étant une "Request for comment".

Trois principes de base, trois tendances

SGML avait été développé pour structurer et pérenniser des documents lourds. Dans ce domaine, l'essentiel était que l'ensemble des éléments d'un document, par exemple un manuel technique, soient présents et correctement organisés. La gestion de données et les problèmes de communication ne se posaient pas fortement. Dès lors, tout document doit se conformer à une structure unique, qui doit être immédiatement accessible au logiciel parseur qui va valider le document, au logiciel d'affichage etc.

XML a été développé pour permettre des échanges sur le Web. Il peut s'agir de messages courts, et la diversité des possibilités de communication a conduit à permettre que les règles soient définies par les parties en présence assez librement. Dès lors, il est possible d'envoyer un document formé d'un ensemble d'éléments avec des balises non connues initialement du destinataire mais avec une structure correcte, que ses logiciels pourront interpréter. Ainsi pourra-t-il constater qu'une "adresse" contient toujours un "nom de rue", par exemple. Cette solution, quoique risquée, laisse toute latitude aux acteurs.

En revanche, il s'agit souvent de transporter des données, et il est très important, en commerce électronique, de savoir de quelle donnée il s'agit, de connaître les échelles, de pouvoir effectuer des contrôles avant de lancer des applications. Aussi les acteurs du commerce sont ils très intéressés par la possibilité d'inclure dans les définitions XML et dans les messages des règles concernant les données. C'est cette nouvelle tendance qui a donné naissance aux schémas, proposés initialement par Microsoft. Ces schémas véhiculent, comme les DTD, des informations de structure, mais ce sera en général sur des objets plus restreints que les DTD (qui traitent d'un moteur d'avion, d'un dossier médical…) car concernant des messages ou des éléments d'actes commerciaux ou autres (comme une facture ou une adresse). En revanche, les schémas permettront de mieux contrôler les valeurs particulières véhiculées (c'est le typage des données).



Ces aspects sont repris dans les différents paragraphes du présent document.

1.3.3. DTD : La définition de type de document

W3C XML Specification DTD ("XMLspec") Révision 1.2 du 10 Septembre 1998

http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm

Une DTD permet de définir de façon formelle la structure de référence d'un document indépendamment de son contenu. C'est un ensemble de règles de structuration qui précise ce qui est autorisé ou non dans un document.

La DTD permet de définir des structures de référence pour des documents, des formulaires administratifs, des transactions commerciales ou financières, etc. L'émetteur d'un formulaire pourra faire référence à la DTD de ce formulaire pour valider son document.

L'encart qui suit présente le début d'une DTD. Il est à noter (et c'est l'un de leurs inconvénients) que les DTD sont exprimées dans une notation particulière qui n'est pas SGML (donc pas XML). Au contraire, les schémas sont exprimés à partir d'un langage de définition qui est lui-même un langage XML et pourra être défini….par un schéma.

La DTD présentée ici correspond au mini-document figuré dans le schéma précédent.

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

<!—Exemple de DTD -->

<!ELEMENT liste-message-panne (message+) >

<!ELEMENT message (description, marque-vehicule, type, numero-panne, procedure-

reparation) >

<!ELEMENT description (#PCDATA) >

<!ELEMENT marque-vehicule (#PCDATA) >

<!ELEMENT type ((#PCDATA) >

<!ELEMENT numero-panne (#PCDATA) >

…………

"Cette DTD très simple montre entre autres que l'élément racine liste-message-panne doit comprendre au moins un élément message (indiqué entre () dans la première


http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm


ligne). Elle donne ensuite la liste des éléments eux-mêmes contenus dans cet élément message puis leur description.

Attention #PCDATA signifie Parsed Character Data, c'est à dire ensemble de caractères à vérifier par le parseur (ne devant pas contenir des caractères interdits, etc.).

Le concept de "définition de type de document" a été introduit par SGML, il n'est pas défini en syntaxe XML. Ce dernier point fait de la DTD un outil à l'avenir limité dans le monde XML. Une DTD ne permet de décrire qu'un nombre limité de contraintes syntaxiques et structurelles d'un document. Elle ne supporte par la définition de type de données ou la définition de la cardinalité d'un élément. N'étant pas extensible, la DTD ne répond que partiellement aux besoins des échanges d'information. Ceux-ci nécessitent une description très fine et précise de la structure du document ou du message.

De premières tentatives

DCD : Description du contenu de document (Document Content Description)

http://www.w3.org/TR/1998/NOTE-dcd-19980731

La DCD a été la première réponse des concepteurs XML du W3C aux limites de la DTD. La DCD, comme la DTD est un langage de description du contenu d'un document mais elle est écrite en syntaxe XML. C'est un ensemble de propriétés utilisées comme contraintes de structure et de contenu d'un document XML.

Les principes qui ont conduit aux spécifications de la DCD sont les suivants :

Les possibilités sémantiques d'une DCD doivent être un sur-ensemble de celles proposées par les DTD.

Le modèle de donnée et la syntaxe d'une DCD doit être conforme avec ceux de RDF (cf. infra).

Les contraintes données par une DCD doivent être utilisables par des outils appropriés ou d'autres applications qui souhaitent récupérer des informations sur le contenu et la structure d'un document.

Une DCD doit être lisible et raisonnablement explicite.

La DCD permet de définir des contraintes, absentes des DTD :

- sur les types d'éléments et les noms d'attributs apparaissant dans un document XML, et…

- sur le contenu des éléments et les valeurs des attributs.


http://www.w3.org/TR/1998/NOTE-dcd-19980731


Ces contraintes peuvent être utilisées de la même façon que celles exprimées dans une DTD mais proposent des propriétés complémentaires sur les types de données.

Les spécifications de la DCD comprennent un sous-ensemble de XML-Data et l'expriment en cohérence avec RDF, Resource Description Framework. DCD est un vocabulaire RDF (cf. infra).

DDML : Document Definition Markup Language

http://www.w3.org/TR/NOTE-ddml

Autre proposition pour remplacer les DTD par une expression XML, cette fois très proche des DTD elles-mêmes.

1.3.4. Les Schémas XML (Le langage "XML Schema")

http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215

XML Schema est un langage de définition de schémas écrit en syntaxe XML. C'est un sur-ensemble des possibilités offertes par les DTD. Un schéma XML propose un ensemble de règles pour définir la structure et l'articulation des informations d'un document XML.

L'objet d'un schéma XML est de définir et de décrire une classe de documents XML pour les contraindre et en préciser le sens, l'utilisation permise et les relations entre les parties constituantes ainsi que contraindre et préciser le type des données, les éléments et leur contenu, les attributs et leur valeur.

Un schéma XML peut être utilisé pour définir, décrire et répertorier le vocabulaire XML pour des classes de documents XML. Toute application qui utilise un document XML "bien formé" peut utiliser le formalisme XML Schema pour exprimer les contraintes de syntaxe, de structure et de valeur applicable pour cette instance de document.

Le dernier appel à commentaires sur la première version du langage a été lancé par le groupe de travail XML Schemas le 7 avril 2000.

La recommandation devrait intervenir au plus tard dans le courant de l'été 2 000. C'est à quoi s'est engagé le groupe de travail XML Schemas du Web Consortium. Jusque là, XML n'est pas stabilisé. Il faut noter aussi que, une fois le langage défini, de nombreux outils et extensions restent en développement, au W3C et ailleurs : à côté de la syntaxe de base, de nombreux groupes importants travaillent sur des éléments indispensables comme par exemple l'expression et le transport des signatures numériques dans les documents et messages XML.


http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215

http://www.w3.org/TR/NOTE-ddml


Les schémas : une évolution importante. Comme cela a été indiqué, un document XML peut se passer de définition externe de ses balises et structures. Il peut aussi se référer à une DTD, celle-ci pouvant d'ailleurs être distante. Il va pouvoir bientôt se référer à des schémas. Ceux-ci représentent une évolution importante pour l'utilisation d'XML. Proposés d'abord par Microsoft, ils ont d'abord été âprement débattus mais l'unanimité s'est faite et, comme le promet le groupe de travail, ils feront l'objet d'une recommandation et donc d'un standard du W3C en 2000. Les schémas correspondent en effet à des demandes pressantes des acteurs du commerce électronique parce qu'ils répondent à des besoins que les DTD ne satisfont qu'imparfaitement. Ils sont particulièrement importants pour les EDI. Il est très probable que les schémas vont progressivement remplacer les DTD dans la plupart des applications, en tout cas dans les applications du commerce électronique au sens large, et donc dans l'EDI.En effet, les DTD ont été le fondement de la démarche SGML depuis quinze ans mais elles présentent des inconvénients qui étaient très supportables dans une approche documents mais sont de plus en plus gênants pour le commerce électronique. Elles ne sont pas écrites en XML, ne permettent pas la définition et l'affectation de types de données, ne possèdent pas de mécanisme d'héritage. Les schémas visent, entre autres, à remédier à ces inconvénients. Ils sont réutilisables, assemblables. Ils permettent de fixer précisément caractéristiques et contraintes pour des données dans le cadre de types prédéfinis. C'est aussi avec les schémas que sont introduits des solutions nouvelles fondamentales comme les Namespaces (cf. infra). Les schémas sont en fait les briques qui vont permettre de créer rapidement des messages et des documents, d'autant qu'ils sont écrits en XML et supportent l'héritage. Il est donc possible, en utilisant les outils XML qui se diffusent, d'assembler rapidement des schémas pour en créer de nouveaux, et de se référer à des ensembles de schémas pour créer des messages.Les schémas permettent en fait la constitution de dictionnaires et de répertoires qui comprennent les dictionnaires de données mais comprennent aussi toute la structure propre à telle ou telle donnée. Par rapport à d'autres syntaxes, et encore une fois par rapport à EDIFACT, ils représentent un concept qui regroupe les éléments, les segments et jusqu'aux messages.Les schémas permettent en particulier de préciser, pour une donnée, non seulement le type mais les bornes ou d'autres informations sur les valeurs. Ils permettent donc des validations automatiques lors de l'analyse des messages et documents par les parseurs, évitant de passer des données aberrantes aux applications. En fait, les schémas vont permettre d'intégrer des contraintes sur les données qui étaient celles figurant dans les dictionnaires de données, dont en particulier ceux d'EDIFACT ou des autres systèmes de normalisation d'échanges.(cf. ci-après les conséquences en matière d'organisation des réseaux et des communautés et les stratégies correspondantes)



L'exemple qui suit est destiné à montrer le fonctionnement des schémas. Un document XML est présenté, puis le schéma qui lui correspond. Le document représente une commande envoyée par un client à un équipementier automobile.

Le document :

<?xml version '1.0' ?>

<Commande DateCommande="2000-05-20" xmlns="http://www.canope.com/cmmd">

<Client type="FR">

<Nom>Emile Dupond</Nom>

<Rue>12, quai André Citroen</Rue>

<Codepostal>75015</Codepostal>

<Ville>Paris</Ville>

<Pays>FR</Pays>

</Client>

<DateLivraison>1999-05-25</ DateLivraison >

<Commentaire>Me livrer rapidement, ma voiture est en panne </Commentaire>

<Items>

<Item>

<NumeroProduit="PSA-676-123-002">

<NomProduit>Carter a huile</ NomProduit >

<Quantite>1</Quantite>

<Prix>2 345,50</Prix>

<Commentaire>Confirmez-moi la disponibilite</Commentaire>

</Item>

<NumeroProduit="PSA-523-178-108">

<NomProduit>Filtre a huile</ NomProduit >

<Quantite>1</Quantite>

<Prix>310,00</Prix>

</Item>

</Items>

</Coimmande>



Le schéma XML, qui est présenté ci-après, permet de définir une structure de référence du secteur automobile pour l'échange d'une commande. Le document XML correspondant à une commande va devoir respecter la structure et les caractéristiques définies ci-dessous pour être validée. Certains termes communs figurant dans l'exemple, Adresse, Commentaire, Items, sont précédés d'un préfixe "cm:". Ce préfixe permet de préciser que les termes associés appartiennent à un dictionnaire ou un répertoire se trouvant sur un serveur dont l'adresse est mentionnée dans les premières lignes du schema (xmlns=:cm=http://www.automobile.fr/cmmd). Cette caractéristique recouvre la notion d'espace nominal abordée par la suite.

On remarque dans le schéma l'emboîtement des définitions. Ainsi, Commande est du type Commandetype, qui est défini ensuite et contient différents éléments. L'un d'eux, adresse, renvoie à une définition placée après, etc. Dans d'autres cas, le type ne renvoie pas à une définition mais à un type de donnée standard : string (chaîne de caractères), décimal etc.

Première ligne : targetNamespace précise l'adresse de l'URI du namespace en relation avec le schema en cours.

Deuxième ligne : Déclaration du domaine de nom sans préfixe, il constitue le domaine par défaut associé à tout les éléments du document dont le nom n'est pas préfixé.

Troisième ligne : Définition du préfixe cm permettant d'associer aux éléments du schéma préfixés par cm l'adresse du namespace mentionné.

Le schéma :

<schema targetNamespace="http://www.automobile.fr/namespace/cmmd"

xmlns="http://www.automobile.org/xmlschema-commande-2000-001"

xmlns:cm="http://wwwautomobile.fr/namespace/cmmd">

<element name="Commande" type="cm:Commandetype"/>

<element name="Commentaire" type="string"/>

<type name="Commandetype" >

<element name="Client" type="cm:Adresse" />

<element name="Datelivraison" type="date" />

<element ref="cm:Commentaire" minOccurs="0" />


http://www.canope.fr/cmmd

http://www.automobile.org/xmlschema-commande-2000-001




<element name="Items" type="cm:Items" />

<attribute name="DateCommande" type="date" />

</type>

<type name="Adresse" >

<element name="Nom" type="string" />

<element name="Rue" type="string" />

<element name="Codepostal" type="integer" />

<element name="Ville" type="string" />

<element name="Pays" type="string" />

<attribute name="type" type="string" />

</type>

<type name="Items" >

<element name="Item" minOccurs="0" maxOccurs="*" />

<type>

<element name="NomProduit" type="string" />

<element name="Quantite" >

<datatype source="integer" />

<minExclusive value="0" />

</datatype>

</element>

<element name="Prix" type="decimal " />

<element ref="po:Commentaire" minOccurs="0" />

<attribute name="DateCommande" type="date" />

</type>

</element>

</type>

</schema>



1.4. Langages de présentation et de transformation des documentsDans toute démarche qui distingue le contenu de sa présentation ou de son utilisation, il est nécessaire d'indiquer, indépendamment dudit contenu, la manière dont il doit être présenté sur tel ou tel support. Les traitements de texte eux-mêmes (Word) permettent de définir des feuilles de style, que l'utilisateur crée en indiquant simplement qu'un titre de niveau X doit être en telle police, tel corps, avec telle position etc. Cependant, cette approche lie trop la structure et la présentation dans un même fichier. HTML a reproduit cette démarche sur le Web, avec des indications qui peuvent mêler la structure (titre, paragraphe) et les caractéristiques de mise en page (gras etc.). SGML avait conduit au contraire à une définition très stricte d'un langage pour définir des mises en page. Ce langage interprète la structure (l'arbre SGML) et permet d'écrire, pour les mêmes documents, des feuilles de style adaptées à l'écran, au papier, voire au vocal, par exemple. La norme correspondante (Document Style Sheet Specification Langage – DSSSL) est peu appliquée parce que très lourde et rigide. Néanmoins, c'est d'elle que le W3C est parti pour définir un langage d'écriture de feuilles de style.

Une feuille de style définit un mécanisme de présentation d'une page d'information sur le Web. Il est possible à l'aide d'une feuille de style de spécifier l'aspect visuel ou sonore d'un document. Après la publication de deux recommandations, CSS1 et CSS2, le W3C continue de faire évoluer le langage CSS, Cascading Style Sheets.

Pour des publications plus complexes, telles que la production automatique de tableaux ou la conversion d'un document XML en document HTML, le W3C, profitant de l'expérience des langages CSS et DSSSL, développe actuellement le langage XSL, Extensible Style Sheets Language. La perspective fondamentale est de passer à une définition structurée des présentations en XML, avec XSL. Plus profondément, il ne s'agit plus seulement de présentation mais de toute transformation, pour différents usages, avec l'évolution vers XSLT.

Une autre étape essentielle. Au delà des aspects techniques, l'approche par les feuilles de style et un langage de transformation est tout à fait fondamentale pour passer à une nouvelle démarche de conception des systèmes, et ceci en environnement ouvert multi-partenaires.

A partir des mêmes informations de base, il est en effet possible de définir, par exemple, de multiples messages, formulaires, transferts de données, affichage dans le Web. Les serveurs qui vont se développer auront de plus en plus accès non seulement à des bases de données et documents mais à des répertoires de feuilles de style. Elles leur permettront de générer aussi bien un message qu'une



présentation sur un site Web, en tenant compte de la génération des navigateurs. Le même message XML pourra être traité automatiquement par une application mais aussi affiché dans une forme utilisable par un humain, à la demande.

Plus encore, l'utilisation de ces mécanismes de mise en forme va permettre de gérer des environnements acceptant des messages dans des langages XML différents. C'est ce qui est évoqué plus loin avec XSLT.

1.4.1. Langage de feuille de style : CSS

Le langage CSS est un langage déclaratif simple pour mettre en forme des pages HTML ou des documents XML. CSS n'est pas en syntaxe XML. CSS permet de préciser les caractéristiques visuelles et sonores de présentation d'un document : les polices de caractères, les marges, les interlignes, les bordures, les couleurs, le volume du son, etc.

Exemple :

Titre {font-size: 24pt; font-weight: bold; color: blue; } aura pour résultat : TitreLe terme de "Cascading" Style Sheets sous-entend qu'un document peut faire référence à des feuilles de style en "cascade" et de différentes sources pour produire la présentation finale d'un document. En particulier, il est possible de définir un style pour une page puis, à l'intérieur de cette page, de fournir des informations plus précises ou différentes pour présenter certains éléments.

Il existe deux versions du langage CSS, CSS1 et CSS2. Le CSS2 est simplement une nouvelle version du premier avec des caractéristiques complémentaires de présentation.

1.4.2. Langage de feuille de style : XSL

http://www.w3.org/TR/2000/WD-xsl-20000112/

XSL, Extensible Stylesheet Language est un langage de conception de feuilles de style.

XSL comporte deux parties :

Un langage de transformation de document XML, Un vocabulaire XML pour spécifier les éléments sémantiques de mise en forme.


Norbert, 03/01/-1,

id

http://www.w3.org/TR/2000/WD-xsl-20000112/


La deuxième partie de la spécification va donc permettre de construire des documents XML axés non plus sur le contenu mais sur la présentation – c'est-à-dire un HTML qui serait puissant, bien formé et ne mélangeant pas contenu, logique et présentation.

La première partie indique comment une feuille de style va indiquer aux outils de manipulation comment traduire un document XML, en général structuré en fonction du contenu, en un document XML visant à la présentation. C'est à dire que ce langage va devoir identifier quels contenus (un item, une adresse, un titre) va jouer tel ou tel rôle dans la structure de mise en forme et quelles caractéristiques typographiques ou autres vont lui être appliquées. Remarque : cette transformation peut d'ailleurs permettre de passer d'une feuille de style à une autre, puisqu'une feuille XSL est un document XML…

1.4.3. Langage de transformation : XSLT

http://www.w3.org/TR/xsl/

XSLT, Extensible Stylesheet Language Transformation, est un langage de transformation de documents XML en d'autres documents XML. XSLT a fait l'objet d'une recommandation du W3C en novembre 1999.

Cette transformation va permettre de transformer une structure XML en une autre – un arbre devenant un autre arbre. Elle est d'autant plus nécessaire que de nombreux langages professionnels ou scientifiques vont se développer qui traiteront de problèmes similaires mais avec des structures d'organisation des informations différentes.

Ce que fait un moteur XSLT, c'est de lire l'arbre XML en se référant à des règles de transformation.

XSLT va donc permettre de transformer de l'XML en…XML.

C'est là entre autres une réponse à la prolifération aujourd'hui des DTD, demain des schémas.

Pour des éléments d'information, des documents ou des messages correspondant à la même fonction, d'éventuelles différences entre des groupes ou communautés d'utilisateurs reflèteront seulement des choix de mise au point. Si les modèles sous-jacents et les données sont en fait les mêmes, une transformation symétrique entre des formes différentes est possible et automatisable. Cette démarche va notamment permettre la cohabitation d'approches concurrentes pour l'organisation des schémas lorsqu'elle ne peut être évitée. Des logiciels et services sont déjà proposés (par exemple ceux d'Extensibility).


http://www.w3.org/TR/xsl/


Dans les cas où de véritables différences existent, et où l'information transportée n'est pas la même, XSLT permettra de gérer un plus grand commun dénominateur. Il permettra de convertir des messages exprimés pour un domaine en ceux d'un autre domaine ou d'une autre spécialité, en écartant éventuellement les informations non utilisables dans le nouvel environnement.XSLT pourra être aussi utilisé, entre autres applications, pour convertir des feuilles de style.

XSLT n'effectue pas de mise en forme, mais il est conçu pour travailler, entre autres, en association avec XSL (par exemple pour passer d'un document XML vers un autre lui-même traitable avec une feuille XSL de présentation associée).

En fait, les outils qui se construisent en utilisant XSLT vont souvent dépasser l'objectif initial et manipuler l'arbre XML pour obtenir des structures fondamentalement différentes. C'est ainsi que des produits permettent de générer des fichiers PDF à partir de XML (PDF faisant lui-même une partie du chemin).

1.5. XML Namespace : Espace nominalhttp://www.w3.org/TR/1999/REC-xml-names-19990114/

XML Namespace est un langage de définition d'espaces nominaux écrit en syntaxe XML. Un espace nominal XML est un répertoire de noms utilisables comme noms d'élément ou d'attribut dans un document XML.

L'espace nominal qualifie ou identifie des noms utilisés de façon unique sur le Web pour éviter les conflits de terminologie entre des éléments de nom identique.

Un espace nominal peut être déclaré soit explicitement soit par défaut dans un document XML. Lors d'une déclaration explicite, on définit un préfixe se substituant au nom complet de l'espace nominal. On utilise ce préfixe pour qualifier les éléments appartenant à cet espace. Les déclarations explicites sont utiles quand un document contient des éléments de différentes nomenclatures.

L'espace nominal permet de garantir que les noms utilisés dans une DTD ou dans un Schéma sont non ambigus. Les noms de différentes DTDs et Schémas peuvent être combinés dans un seul document, si nécessaire. L'espace nominal est un apport sémantique, utilisé pour éviter les conflits de noms et éviter de mélanger les vocabulaires.

Conformément à une orientation qui fait des standards autour d'XML des outils réseau (cf. infra Tendances), l'espace nominal est identifié par une ressource : soit un URI,


http://www.w3.org/TR/1999/REC-xml-names-19990114/


Universal Resource Identifier, soit un URL, Uniform Resource Locator, soit un URN, Uniform Resource Number (L'URI est un sur ensemble).

Il faut cependant noter que les Namespaces ne sont pas encore stabilisés, précisément en raison de désaccords sur l'utilisation des références externes (URI). La recommandation pourrait être retardée mais devrait être disponible avant la fin 2 000, le principe n'étant absolument pas en cause.

L'utilisation des Namespaces est certainement l'une des avancées les plus notables de XML. Le Web consortium s'est trouvé rapidement confronté à la prolifération de groupes travaillant à créer des langages spécialisés ou locaux grâce à XML. Chaque entreprise peut créer ses propres noms de balises et ses propres structures. C'est un avantage d'XML, mais c'est aussi le risque d'une vaste cacophonie et une possibilité d'erreurs si les mêmes noms sont choisis pour désigner des éléments différents. En fait, l'utilisation même d'XML deviendrait rapidement impossible dans des espaces non strictement fermés.Dans des approches préexistantes, et notamment celle de la norme EDIFACT, la démarche logique avait été de normaliser les dictionnaires de façon très stricte. EDIFACT n'est pas qu'une syntaxe, c'est un ensemble précis qui comprend des jeux de messages, des dictionnaires, des éléments, des listes de codes. Cette approche correspondait à un monde très régulé. Elle n'est absolument pas envisageable dans le bourgeonnement actuel du commerce électronique et des réseaux. Pourtant, la rigueur reste nécessaire : l'automatisation des échanges entre systèmes informatiques suppose bien de se référer de façon univoque à un même dictionnaire, aux mêmes codes etc.La réponse du Web Consortium est de faire systématiquement appel aux références sur le réseau, en fonction du contexte. Elle a progressé radicalement avec les Namespaces. Désormais, il est toujours possible, pour toute structure référée en XML, de préciser qu'elle appartient à un Namespace particulier. Tout groupe peut donc créer ses propres références, en particulier ses balises et ses schémas – même s'il ne faut pas abuser de cette faculté. Le document XML est capable d'indiquer que tout un ensemble d'informations relève d'un certain Namespace.En outre, plusieurs Namespaces peuvent être utilisés dans un même document, référant ainsi à plusieurs domaines sémantiques.Ainsi, des communautés d'utilisateurs peuvent utiliser des langages généraux et adapter un certain nombre d'éléments pour leurs besoins propres.L'utilisation des espaces nominaux va être essentielle pour récupérer les dictionnaires multiples qui peuvent exister dans un domaine, et ceci sera particulièrement important dans toute période de transition où plusieurs dictionnaires d'organismes, de groupements et de communautés vont être utilisés. L'utilisation de Namespaces pour indiquer quel dictionnaire est utilisé et permet aux outils d'aller chercher une information si nécessaire.



Exemple :

xmlns:cm=“http://www.automobile.fr/namespace/cmmd”

<element name="Commande" type="cm:Commandetype"/>

<element name="Client" type="cm:Adresse" />

xmlns:cm : Définition d'un préfixe contenant le nom du préfixe de l'espace nominal (cm) utilisé pour associer les éléments de cmmd (commande) à cet espace. “http://www.automobile.fr/namespace/cmmd” : Nom de l'espace nominal référençant le dictionnaire qui définit l'élément commande.

1.6. Autres langages et standards : vers les outils

1.6.1. Les langages de lien d'adressage : XPATH, XLINK et XPOINTER

Les liens d'adressage font référence aux mécanismes permettant de "surfer" sur le Web. Ces liens d'adressage sont aussi appelés "liens hypertextes". Ils permettent de mettre en relation différentes ressources sur le Web.

Par la richesse de ses capacités de référencement et de gestion des liens, XML représente une très puissante extension (et non une simplification) par rapport à SGML.

Xpath

http://www.w3.org/TR/1999/REC-xpath-19991116

Xpath, n'est pas à proprement parler un langage de lien d'adressage. C'est un langage de description de la structure d'un document, de son arborescence hiérarchique et de ses nœuds (nodes) permettant d'adresser des parties d'un document XML. Il est conçu pour être utilisé par XSLT (XML Stylesheet Transformation) et Xpointer. Xpath a fait l'objet d'une recommandation du W3C le 16 Novembre 1999. Xpath utilise une syntaxe non XML.


http://www.w3.org/TR/1999/REC-xpath-19991116


Xlink

http://www.w3.org/TR/1999/WD-xlink-19991220/

Le langage Xlink permet de créer et de décrire des liens entre des ressources du Web. Les liens qu'il est possible de créer sont de différents types, allant de liens simples internes à un document XML et similaires aux liens hypertextes utilisés actuellement dans des documents HTML, à des systèmes de relations plus complexes , tels que des liens étendus vers des ressources multiples ou des bases de données de liens.

Liens simples

Reprenons notre exemple pour illustrer un exemple de lien simple en ligne :

<procedure-reparation href="pr.xml" title="Procedure de reparation" show="new" content-role="reference" >PSA HM003-01</procedure-reparation>

Avec HTML , seule la balise prédéfinie <a> (anchor ou ancre) permet de créer un lien hypertexte. Avec XLink, toute balise peut être la source d'un lien, par exemple la balise <procedure-reparation> à laquelle il est possible d'associer différentes caractéristiques :

L'attribut href indique le nom de la ressource destination du lien pr.xml, L'attribut title indique le rôle du lien "Procedure de reparation",

Liens étendus hors-ligne et base de données de liens

Notre procédure de réparation au format XML peut, par exemple, accéder à une base de données de liens dits étendus. La différence entre un lien étendu et un lien simple (de type HTML) se résume en deux points :

Le lien étendu peut connecter une multitude de ressources et non pas seulement deux ressources (la source et la destination), Les liens étendus sont le plus souvent hors ligne. Un lien hors ligne est un lien dont le contenu ne fais partie ni de la source, ni de la destination du lien. Les liens étendus résident dans des bases de données de liens auxquels les utilisateurs ont accès.Les liens étendus permettent à l'auteur du lien de créer des liens hypertextes provenant de documents sur lesquels il n'a pas droit d'écriture, par exemple dans le but d'annoter un document.


http://www.w3.org/TR/1999/WD-xlink-19991220/


Par exemple : En accédant, au travers de la procédure de réparation, à une base de données de liens étendus, un utilisateur "Olivier" remarque qu'un de ses collègues "Collègue" a ajouté une note à la procédure en question.

"Olivier" décide alors d'ajouter sa propre "annotation" pour faire part à ses collègues du service "études", de son expérience concernant la procédure de réparation.

Le lien étendu pointe vers chaque ressource participante par l'attribut href de l'élément <locator> :

<annotations xml:link="extended" inline="false">

<locator href="pr.xml" role="Procedure de Reparation">

<locator href=Collegue.xml" role="annotation"/>

<locator href=Utilisateur.xml" role="annotation"/>

</annotations>

Liens multidirectionnels

Les liens étendus sont aussi appelés liens multidirectionnels parce que le lien peut être initié de n'importe quelle ressource participante :

"Norbert", un collègue d'"Olivier" peut accéder à l'"annotation" d'"Olivier" en cliquant sur le lien à partir de la procédure de réparation, De même, "Claude", du service "études" pourra accéder à la procédure de réparation en cliquant sur un lien à partir de l'annotation d' "Olivier".

Xpointer

http://www.w3.org/TR/xptr

Xpointer est une extension du langage Xpath. Langage simple, Xpointer fournit un mécanisme permettant de spécifier un point précis dans un document XML en fonction d'une localisation source pour y sélectionner des éléments. Il opère sur la structure arborescente et les nœuds des documents. Il peut être utilisé par Xlink pour établir des liens au sein même d'un document XML. Les fonctionnalités de Xpointer permettent


http://www.w3.org/TR/xptr


aux liens Xlink de pointer vers un point précis d'un document qui peut être un élément, un texte ou une partie d'un document.

Par exemple : Xpointer associé à XLink offre la possibilité à "Norbert" de pointer et sélectionner directement le paragraphe 2.1 de l'annotation d' "Olivier"

Accès aux bases de données : XQL ?

http://www.w3.org/Style/XSL/Group/1998/09/XQL-proposal.html

Comme XML a prétention à être utilisé comme un format universel d'échange d'information, il a été envisagé de disposer d'un langage universel de requêtes pour accéder à ces informations.

XQL a été conçu comme un langage de requête pour XML, adapté à la recherche d'information dans un document XML. C'est une extension de la syntaxe XSL Pattern permettant de pointer sur des éléments spécifiques d'un document XML et de rechercher des nœuds d'un document ayant des caractéristiques particulières.

Néanmoins, la démarche XQL est très contestée. Pour beaucoup des concepteurs du langage, elle relève d'un purisme mal placé, qui veut tout transformer en XML. En effet, l'avantage qu'il y a à remplacer le langage universellement accepté et normalisé d'interrogation SQL par une expression XML à peu près équivalente ne semble pas très notable au regard de la perte de l'unité dans les langages de requête. Le sujet reste à l'étude au printemps 2 000.

Afin de mieux cerner la portée du langage XQL, nous proposons dans le tableau, ci-après, une comparaison entre le langage de requête SQL des bases relationnelles "classiques", et XQL. Pour chacun des deux langages, le tableau précise la définition de "base de données", "langage de requête", "Entrée" et "Résultat" d'une requête.


http://www.w3.org/Style/XSL/Group/1998/09/XQL-proposal.html


ConceptSQL XQLBase de données Un ensemble de tables Un ensemble d'un ou

plusieurs documents XML.

Langage de requête SQL : Langage de requête utilisant les tables comme modèle de base.

XQL : Langage de requête utilisant la structure des documents comme modèle de base.

Entrée d'une requête La clause FROM détermine les tables examinées par la requête.

Précise en entrée un ensemble de nœuds d'un ou plusieurs documents, et examine ces nœuds et leurs descendants.

Enoncé du résultat Le résultat est une table contenant un ensemble de rangs répondant à la requête.

Le résultat est un ensemble de nœuds de documents XML, qui peuvent être regroupés à partir d'un nœud racine pour créer un nouveau document XML bien formé.

Reprenons notre exemple :

La requête XQL :

message [numero-panne="HM003"]

aura pour résultat :

<message>

<description>FUITE HUITE MOTEUR</description>

<marque-vehicule>PEUGEOT</ marque-vehicule >

<type>MAU000AKL683</ type >

<numero-panne>HM003</numero-panne>

<procedure-reparation href="pr.xml" title="Procedure de reparation" show="new" content-role="reference" >PSA HM003-01</procedure-reparation>

</message>



1.6.2. Mécanismes de manipulation des documents XML : API (interfaces de programmation applicatifs)

Modèle objet de document : DOM

http://www.w3.org/TR/DOM-Level-2/

Le DOM est une interface de programmation (API) pour des documents XML ou HTML. Cette interface est indépendante des plates-formes et des langages de programmation. Elle doit permettre aux scripts et aux programmes d'accéder et mettre à jour dynamiquement le contenu, la structure et la présentation d'un document XML. Les travaux de spécifications du DOM se font sous le couvert du W3C. Ces spécifications devraient faire l'objet d'une recommandation dans les prochains mois.

Le nom, "Document Object Model" ou DOM a été choisi en référence aux méthodes de conception orientée objet. Les documents sont modélisés en mettant en évidence la structure du document, son comportement et les objets qui les composent. Les nœuds d'un document ne représentent pas une structure de données mais des objets, ayant une fonction et une identité.

Le DOM identifie :

les interfaces et objets utilisés pour représenter et manipuler un document, la sémantique de ces interfaces et objets (comportement et attribut), les relations et les collaborations entre les interfaces et les objets.

Le DOM fournit :

un ensemble d'objets standards pour représenter un document XML un modèle de référence présentant les liens entre ces objets, une interface standard pour y accéder et les manipuler.

Le DOM doit permettre aux offreurs de logiciels de proposer des applications Web avec une interface standard utilisable dans tous les environnements et avec toutes les autres applications Web indépendamment de la plate-forme et du langage de programmation de l'application.

Le schéma indique le principe de DOM (et de tout interface de traitement de document XML : l'interprétation de la structure en arbre que véhiculent les balises XML.


http://www.w3.org/TR/DOM-Level-2/


Document

<

>

< > < >

< >>

<

/A< >AB

C /C

/B

< >< >

D

/D< >E < >E

< >A

Document

< >B

< >C < >D

< >E

=

Application

API DOM

Document Object ModelAPI de manipulation de documents dans une démarche objet

Outil de manipulation : SAX

A côté de la manipulation complète de documents, Simple API for XML (SAX) est une spécification très précieuse pour l'écriture des applications. En effet, elle permet de traiter des sous ensembles sans avoir à connaître tout le document. SAX peut permettre à une application de manipuler des vues globales de l'arbre XML d'un document, ou encore de traiter le document en streaming. Cela signifie que le parser ayant une interface SAX et les applications associées vont pouvoir travailler au fur et à mesure, par exemple, de l'arrivée d'un message XML, construisant l'arbre ou traitant des informations dès qu'un élément est correctement constitué.

Java XML API : JDOM

Le langage Java inclut ses propres interfaces de programmation et appel à des fonctions et des objets. Aussi, les développeurs ont ils introduit en mai 2 000 une interface de manipulation de documents XML depuis tous les programmes Java. JDOM travaille dans l'esprit du DOM mais il est présenté comme beaucoup plus utilisable et pratique (mais seulement dans les environnements Java).



1.6.3. Format d'interchange de méta données : XMI

ftp://ftp.omg.org/pub/docs/ad/99-10-02.pdf

L'objet principal de XMI, XML Metadata Interchange, est de permettre l'échange de métadonnées entre outils de modélisation basés sur UML, Unified Modeling Language, et la communication des répertoires de méta données basés sur le MOF, Meta Object Facility, deux standards de l'OMG, Object Management Group.

L'effet économique et technique est important, parce que jusqu'ici il était à peu près impossible à une communauté de travail, un groupe d'entreprises etc. de travailler sur des modèles communs en utilisant des outils de conception provenant de fournisseurs différents.

XMI sert d'outil permettant de faire travailler concouramment de tels produits. C'est ce qu'illustre l'annonce récente de Rational et IBM qui font une offre commune autour de leurs outils de génie logiciel, utilisant XMI pour les échanges.

XMI se fonde sur les trois standards XML, UML et MOF.

UML est un formalisme orienté objet de conception et de documentation d'applications, MOF est une technologie de définition et de représentation de métadonnée en tant qu'objets CORBA (Common Object Request Broker Architecture). CORBA est un concept permettant à deux applications de communiquer entre elles sans se soucier de leur localisation ou de leur mode de conception.

Les spécifications XMI consistent à proposer un ensemble de règles de transformation de structures MOF en DTD XML, des DTD pour UML et MOF, un ensemble de règles de production de documents XML pour manipuler des méta données MOF.

XMI est développé par l'OMG.

Une autre pierre fondamentale de l'édifice : XMI – pour UML et les modèles objet

XMI est donc la rencontre entre deux mondes importants, celui des objets et celui des structures de données et documents.

(cf. des schémas joints)

L'Object Management Group rassemble tous les acteurs industriels concernés par les technologies objet, c'est-à-dire pratiquement tous les industriels informatique télécom et de nombreux grands utilisateurs. La démarche objet suppose une modélisation poussée des données et des processus, pour identifier les classes d'objets, les types d'instances, les actions possibles, les


ftp://ftp.omg.org/pub/docs/ad/99-10-02.pdf


dialogues et transactions entre objets. Le but de l'OMG est fondamentalement la communication entre toutes les applications, voire en fait la disparition à terme du concept même d'application au profit des relations entre des objets. Ceux ci sont avant tout définis par des interfaces, qui sont en fait ce que le monde extérieur perçoit. La démarche de l'OMG, une fois défini un langage d'interface (IDL,) a été de permettre la mise en relations de systèmes divers, quelle que soit leur nature – et donc des systèmes existants – en créant des vues de ces systèmes capables de communiquer. Entre ces systèmes, les Object Request Brokers et autres logiciels de middleware établissent alors la relation.

Deux éléments importants ont donc été produits. L'un est le Meta Object Facility, qui permet de décrire les structures et caractéristiques des systèmes en présence, ce qui permet au middleware de définir les objets communicants. L'autre est un langage de modélisation, UML.

UML (Unified Modeling Language) est un langage graphique conçu pour décrire, spécifier, développer et documenter un système informatique. UML est le résultat de l'unification de méthodes orientées objet, avec pour objectifs la modélisation, de la conception à la mise en œuvre, le développement d'un formalisme de représentation de la phase de modélisation. La version UML 1.0, a fait l'objet d'une standardisation en 1997 par l'OMG.

Le succès d'UML a été très rapide. En effet, jusqu'ici, la modélisation des systèmes produisait des descriptions et des schémas à partir de logiciels divers mais ces descriptions ne pouvaient être transférées autrement que sous forme de textes et de dessins. Le besoin d'un langage commun devenait pressant.

XMI et les règles d'utilisation correspondantes vont, dans ce contexte, jouer plusieurs rôles :

• permettre le traitement et la manipulation des méta données (création de DTD exprimant une structure, génération et manipulation de documents XML correspondants)

• permettre la mise au point des modèles pour des ensembles d'acteurs hétérogènes en réalisant l'échange des notations UML

• fournir un ensemble de règles pour traduire les modèles UML et produire les messages correspondant à des scénarios d'échange

Cette dernière possibilité est désormais intégrée dans les démarches de groupes EDI.

Le schéma suivant esquisse le dialogue entre deux entités A et B qui souhaitent développer des échanges d'information. Ces deux entités peuvent être des éléments d'une même entreprise comme des partenaires de commerce, ou encore deux applications sur deux domaines différents. Elles ont des vues du monde qui s'expriment



dans des modèles, et leurs relations représentent obligatoirement une vue commune pour une partie de leurs activités. Une fois exprimé le scénario d'échange ou d'interaction en UML, l'expression en XMI des éléments relatifs à leur relation permet la mise au point progressive d'un scénario commun.

Système A B

Négociation, partage XMI

vue du monde A B

XMI : langage de partage de modèles

modèles UML

Une fois les modélisations réalisées, des outils (actuellement bien rares) vont permettre de construire les ensembles de messages XML qui vont véhiculer les différents flux identifiés. C'est en tout cas ce que recherchent plusieurs groupes de travail et le Web Consortium. Des règles sont en effet mises au point pour passer des modèles UML aux documents et messages XML. Dès lors, la phase de modélisation de toute activité – et de l'EDI – devrait permettre de produire automatiquement les instances concrètes des messages.

1.6.4. Les annuaires : DSML

AOL, IBM, Microsoft, Novell, Oracle et Sun coopérant sur un standard, l'événement mérite d'être noté. C'est semble-t-il bien le cas pour DSML, Directory Service Markup Language, qui est un standard XML pour exprimer les services et les informations des annuaires. DSML permet d'interfacer les applications de commerce électronique B2B aux annuaires des différents partenaires des échanges.



La disponibilité d'annuaires communs est une condition du commerce électronique et en général des échanges. La recommandation (norme télécom) X500 permettait l'interconnexion des annuaires mais avec des contraintes assez fortes. Le Web a amené à un format d'échange simplifié (Light Directory Access Protocol). Jusqu'ici, les entreprises étaient amenées à écrire des interfaces LDAP spécifiques pour leurs différentes applications. Avec le nouveau standard, les applications accèdent aux annuaires par LDAP mais toutes les requêtes et toutes les informations sont véhiculées dans un langage XML standardisé, et permettant donc un commerce plus ouvert dans des communautés.

La spécification 1.0 a été remise en décembre à OASIS mais aussi au W3C et à Biztalk – l'implémentation sera conforme en particulier à Biztalk (cf. infra ces organisations)

L'importance des annuaires dans tout développement coopératif comme l'est Net-Entreprises amène à suivre de très près ce standard.

1.6.5. Cadre de description des ressources : RDF

RDF est une spécification développée par le W3C pour décrire toute ressource sur le Web – et donc en pratique toute ressource. La ressource peut être un document, un site, une base de données. RDF est donc un système de description de structure très général, indépendant au demeurant de XML. Cependant, cette description, qui peut être exprimée dans divers langages, peut être évidemment exprimée en XML, puisque c'est justement un langage pour décrire des structures. RDF les définit et les analyse et XML permet d'exprimer RDF pour communiquer l'information de structure à des applications – par exemple à des navigateurs, pour les informer sur l'organisation et le contenu d'un site.

RDF représente en fait une évolution importante des systèmes d'information parce qu'il permet de généraliser et élargir l'utilisation de meta-données pour décrire les documents. Cependant, il exige une analyse des documents, l'accord sur les structures, une modélisation et représente une évolution en profondeur. C'est pourquoi son application reste encore très limitée. C'est une technique très importante mais dont la diffusion sera lente.

Pour des développements importants, à l'intérieur de groupes – et donc dans des communautés d'intérêt – l'investissement sur l'analyse RDF des ressources mises en place et l'accord sur les outils de description pourra représenter un atout pour le fonctionnement ultérieur des systèmes d'information.



RDF utilise des concepts basés sur un ensemble de définitions mathématiques très rigoureuses relevant de la théorie des graphes.

Indiquons simplement que du code RDF définit des relation entre deux nœuds (textes, ressources, URL, valeur... ou même une relation précédemment définie). Cette relation est étiquetée.

Par exemple, au nœud constitué par un tableau, on peut associer par la relation auteur le nœud constitué par la valeur textuelle "N". Puis au nœud constitué par la relation précédemment définie on peut associer la valeur "MS Excel" (s'il s'agit de préciser l'outil ayant servi à réaliser le tableau) avec l'étiquette comment.

Le code RDF permet donc de définir un graphe dont le parcours à l'aide d'une requête permet de retrouver une information ou une ressource. Aucun langage de requête n'a encore été défini mais le développement pourrait s'orienter vers un langage proche de SQL.

RDF permet en particulier d'associer à un texte les information du Dublin Core – description de documents et ensembles de documents standardisée par les associations de spécialistes de l'information.

RDF est en fait très puissant et rien n'empêche de gérer un système documentaire complet avec des fichiers RDF indépendants des documents qu'ils référencent.

1.7. Tendances et enjeux : les référentiels

1.7.1. XML : un méta langage et des outils conçus pour le réseau

Une caractéristique fondamentale d'XML est qu'il est conçu dans un environnement réseau. Cette caractéristique a des conséquences importantes, qui vont apparaître progressivement avec l'expansion continue d'Internet et la connexion directe ou indirecte de tous les partenaires des échanges à Internet ou à diverses formes d'Intranet, de façon intermittente mais, de plus en plus, continue.

Les bases posées par le W3C pour XML prévoyaient le recours à l'information externe sur le réseau mais la tendance n'a fait que s'accélérer avec l'entrée en force des acteurs du commerce électronique, qui ont rejoint et bientôt dépassé dans les groupes de travail les spécialistes issus du monde du document et de SGML.



Dès le départ, XML a rompu avec la philosophie très stricte de SGML en ce qui concerne les structures de référence. En SGML, et pour des applications qui avaient toutes trait à la gestion de documents lourds, il n'est possible de traiter le document que si la DTD est localement présente. Cette DTD est unique et doit être auto-suffisante. Elle doit donc comprendre toutes les entités et toute l'information nécessaire pour analyser les documents ou permettre à des programmes de les manipuler.

D'entrée, l'approche XML a été certes plus légère, puisqu'un document peut n'être que bien formé. Surtout, elle a permis le renvoi à une DTD externe, ou à plusieurs DTD. Cette approche est d'ailleurs directement issue de celle retenue par la norme Hytime, extension de SGML destinée au multimédia et en général aux documents transportant des objets divers et dépendant d'une base de temps.

Les DTD distantes

Ainsi, en XML, la pratique du pointeur, générale sur le Web, est intégrée dans la syntaxe, qui prévoit expressément l'emploi d'Universal Resource Identificater (URI) pour trouver une DTD. Un document XML est ainsi soit autosuffisant soit dépendant d'informations externes (et cela est indiqué dès la déclaration initiale). Certes, l'URI peut être une adresse sur le disque de l'utilisateur mais elle peut, et c'est supposé devoir être fréquent, être une adresse sur le réseau. En fait, il s'agit d'une identification, non d'une adresse, qui renverra, dans une table, sur une URL. Ainsi, une DTD d'usage fréquent sera finalement chargée localement, mais une autre pourra être distante. C'est aux gestionnaires des échanges d'optimiser.

Les références externes

L'usage des pointeurs ne s'arrête pas là. La gestion des pointeurs est une force d'XML – elle est elle aussi issue des travaux sur Hytime.

Ainsi, XML permet le renvoi à des adresses pour toute information, comme notamment des codes, des références diverses.

D'une certaine manière, ce mécanisme est le même que celui qui, dans la syntaxe EDIFACT, permet d'utiliser des codes différents dans un message, grâce à la suite d'identifiants 1131 – 3055. Face à la diversité des codes dans certains domaines, les auteurs de messages peuvent indiquer qu'ils se réfèrent au code N, celui indiqué dans la donnée, en précisant l'organisme responsable du code (dans l'élément 3055) et la nature de celui-ci (dans 1131). Cependant, il reste aux développeurs ou utilisateurs à s'informer. En XML, les outils peuvent immédiatement aller chercher l'information manquante sur un serveur, le renvoi se trouvant dans la DTD ou le schéma (cf. infra).



L'évolution vers le réseau continue avec l'émergence rapide des schémas et le probable remplacement des DTD par cette nouvelle manière de définir des structures. Les schémas font appel de façon très systématique au référencement réseau et peuvent s'imbriquer, à partir même de sources différentes, en exploitant les Namespaces.

L'introduction des Namespaces a en effet confirmé et élargi de façon décisive la tendance. Désormais, il est possible d'identifier tout ou partie d'un message ou d'un document comme relevant d'un espace sémantique particulier et de rechercher éventuellement les dictionnaires sur le Web ou sur tout autre support.

La conséquence : un fonctionnement en réseau

L'heure, pour les applications, est au développement rapide et à la composition d'éléments obtenus dans des communautés de développeurs. Ce mouvement est extrêmement fort avec aussi bien les bibliothèques d'objet Java qu'avec les logiciels libres mais aussi, même, avec des objets ActiveX dans les environnements Microsoft.

La démarche pour les éléments XML est d'emblée dans cette perspective.

Les communautés de métier, les entreprises et leurs partenaires, les groupements scientifiques s'apprêtent à partager des éléments et en particulier des schémas.

De même que, sur le Web actuel, beaucoup de fonctions sont obtenues en faisant appel à un serveur distant (par exemple les sélections de publicité, de nombreux services, des moteurs etc.), de même, dans le commerce électronique qui s'annonce, beaucoup d'opérations ne pourront être résolues que grâce à la présence d'un middleware représenté par des sites disposant de référentiels, de dictionnaires, de schémas etc. Beaucoup de messages XML ne peuvent être utilisés, dans le cas le plus général, en dehors d'une architecture de serveurs pour fournir les éléments éventuellement prévus comme externes ou manquants, pour aller préciser les balises à l'intérieur d'un Namespace etc.

En particulier, les éléments et messages peuvent avoir été définis par des groupements différents mais les transactions demeureront possibles en faisant appel à des sites capables de convertir les schémas (s'ils sont fonctionnellement et sémantiquement équivalents).

1.7.2. Les répertoires et serveurs de schémas : l'enjeu et les stratégies

Avec l'introduction des schémas, la flexibilité d'XML, la relative facilité d'usage et la très large diffusion des outils vont être encore une fois la pire et la meilleure des choses.



En effet, le risque est que non seulement les contenus, dictionnaires et codages soient différents mais aussi que les structures pour créer et décrire les schémas ne soient aussi multiples. En fait, cela a commencé de se produire avant même que le W3C ait publié les premières recommandations.

L'unification des schémas dans des groupes, le contrôle de services capables de fournir les bonnes références, d'effectuer des conversions et autres opérations, la diffusion de serveurs de commerce supportant de façon native des ensembles de schémas représentent des enjeux économiques et industriels. En effet, la plupart des entreprises et autres intervenants vont chercher à se référer à des standards à l'intérieur d'un groupe pour pouvoir développer leurs échanges. La construction des serveurs de référence, la fourniture d'outils et la création de communautés représentent des perspectives importantes pour les acteurs qui seront capables de contrôler les serveurs, les services ou les logiciels.

Une vraie normalisation mais une normalisation souple

Comme ce fut le cas pour tous les développements précédents des techniques informatiques, le choix est entre une véritable normalisation, avec des standards ouverts, et la définition par des groupes fermés de formats propriétaires.

Il faut s'entendre ici. Il est tout à fait possible d'utiliser XML, même devenu une norme, pour créer des mots, des phrases intelligibles ou manipulables seulement dans des univers restreints. Il suffirait pour cela que les informations nécessaires à l'interprétation se situent dans des espaces fermés. Non seulement XML fait appel à des URI mais il est possible d'encapsuler des ordres divers non XML à l'intérieur des documents. Il est donc possible de faciliter les échanges dans une communauté mais en contrôlant le langage.

Etant donné qu'il n'est pas question de revenir à une définition unique des éléments comme dans les dictionnaires EDIFACT, il faut définir un niveau de normalisation tel qu'il sera toujours possible d'interpréter un schéma et des données en s'adressant à des ressources ouvertes. Il faut aussi limiter la dépendance des messages par rapport aux systèmes propres des partenaires de l'échange : les messages doivent être autosuffisants ou recourir à des références normalisées ou pouvoir accéder à des références externes, indépendamment des applications.

Pour cela, il faut que les groupes de définition des langages et structures s'accordent sur des méta-systèmes.



C'est l'objet …

- de la définition d'un langage de définition de schémas par le Web consortium - de la définition d'un système de renvoi vers des dictionnaires mais avec l'adhésion à un consortium ouvert et enregistrant des standards puis des normes- de la définition par le Web consortium en liaison avec OASIS de normes d'interface pour les serveurs de schémas

La normalisation repose donc sur le fait de pouvoir toujours trouver une référence, de pouvoir toujours interpréter un schéma, même non connu à l'avance. Des services se développeront autour de ces possibilités.

Les serveurs de schémas et dictionnaires

La première société qui s'est engagée dans une stratégie forte de développement de XML est Microsoft. A partir de la norme, et en participant à sa définition, Microsoft a proposé les schémas, pour faire d'XML un outil efficace de transferts de données entre applications, grâce notamment au typage des données. Ainsi doté de ces nouveaux mécanismes, XML devient plus aisément la lingua franca aussi bien dans l'entreprise que pour les EDI inter entreprises. Les propositions de Microsoft ont conduit à un ensemble, Biztalk (cf. aussi infra "applications"), qui comprend à la fois des propositions de structures (un langage de schéma, en attendant la standardisation) et un forum associatif où sont enregistrés les schémas proposés pour divers éléments et messages. Biztalk est à juste titre fortement orienté réseau et comprend donc une architecture pour un répertoire de schémas et d'informations. Les schémas enregistrés dans le site de Biztalk peuvent être partagés par tous.

http://www.biztalk.org

Microsoft a placé Biztalk entre les mains d'un consortium comprenant de nombreuses sociétés importantes (notamment SAP).

Cependant, le Web consortium et un très vaste ensemble d'intervenants – pratiquement tous les acteurs (y compris d'ailleurs Microsoft) – considèrent qu'il faut définir des standards sur une base très ouverte en en tenant compte du travail déjà accompli, en particulier, par les mondes EDIFACT et ANSI X12, HL7 etc.

C'est l'objet de la constitution d'OASIS (Organisation for advancement of structured information standards – cf. 1) et de la création de XML.org, qui vise à être un pôle pour le renvoi vers des répertoires de schémas et des dictionnaires.


http://www.biztalk.org/


La toile

Quel que soit l'aboutissement des diverses stratégies, le fonctionnement d'un monde d'échanges utilisant les technologies Internet et XML est maintenant connu. Il s'appuiera sur une toile d'araignée de serveurs de schémas et de référentiels. Ces serveurs vont s'emboîter et fonctionner grâce à des hyperliens. Ils seront utilisés par les développeurs et gestionnaires d'application pour initier et paramétrer des scénarios d'échange et ils seront utilisés éventuellement dans le cours même des échanges pour interpréter des messages, trouver des adresses, des référentiels etc.

L'accord entre OASIS et l'UN CEFACT, qui a conduit à eBXML garantit que cette toile inclura les serveurs fournissant, avec les interfaces adaptées, les informations issues des dictionnaires EDIFACT comme elle pourra en inclure beaucoup d'autres. Elle sera également capable de fournir des services de conversion, jusqu'à des conversions de syntaxe.

Concrètement, en France, par exemple, la situation pourra être la suivante :

- des entreprises pourront définir des sous ensembles particuliers- elles remonteront pour l'essentiel des échanges à des serveurs des communautés EDI- celles-ci seront organisées autour d'un site EDIFRANCE qui pointera vers telle ou telle communauté et gèrera les parties génériques- elles pointeront également vers les sites de domaines scientifiques ou de communautés EDI internationales- enfin, des sites centraux organisés par OASIS et le CEFACT joueront dans une certaine mesure le rôle que jouent les serveurs répertoires de noms de domaine dans le Web

La force de cette nouvelle approche est qu'elle est souple. Il est tout à fait possible que plusieurs langages et sémantiques existent pour une même fonction. Il suffira qu'un serveur carrefour aiguille vers les ressources correspondant aux demandes des développeurs ou aux paramètres des messages.

L'exploitation des ressources existantes, les dictionnaires

La constitution de dictionnaires de données doit être indépendante de toute technique informatique. Les groupes qui ont développé des standards et normes de communication ont toujours été amenés à proposer des dictionnaires. Une erreur dans certains cas a été de sembler lier ces ressources à la syntaxe. Cette erreur est particulièrement flagrante



dans le cas d'EDIFACT, où les dictionnaires sont à tort réputés inséparables de la norme, dont ils sont une partie.

Il faut au contraire généraliser leur emploi et exploiter l'énorme investissement qu'ils représentent.

Si la traduction "mot à mot" des structures EDIFACT en structures XML est en général une erreur, la communauté des dictionnaires est au contraire une évidence dans la mesure où ils reposent sur une analyse du modèle de données et sur des définitions rigoureuses.

De ce point de vue, la proposition la plus mûre actuellement pour généraliser les dictionnaires du commerce électronique est celle de l'ISO avec le BSR (cf. ci-dessus 1).

Cependant, dans la pratique, un très grand nombre de dictionnaires existent, et en particulier les dictionnaires de données dans les grandes entreprises. Ainsi, les applications internes en XML seront créées à partir de ces dictionnaires - ces applications vont se développer plus rapidement que les applications inter-entreprises, puisque les problèmes d'organisation et de sécurisation sont moindres.

A l'extérieur, et à côté des dictionnaires sectoriels, d'autres tentatives existent pour créer des répertoires de termes ou de schémas et DTD – par exemple l'Universal Repository d'UNISYS, basé sur XML, qui comprend des méta données et des données business, (www.unisys.com/marketplace/urep), ou le DII COE XML Registry; initiative du DOD (Département de la défense des Etats-Unis.

(http://www.diides.ncr.disa.mil/xmlreg/index.cfm)


http://www.unisys.com/marketplace/urep)


2. Domaines d'applicationIl est très difficile de distinguer les domaines d'application d'XML parce que, précisément, cette technique va remettre progressivement en cause le découpage en domaines (cf. infra l'impact sur l'informatique).

2.1. La diversité des usages et la nécessité d'une approche globaleFondamentalement, XML est un système pour construire des langages de communication et partage de données et documents. Il concerne donc la gestion des données, leur publication, leur échange entre des partenaires etc.

XML est bien plus ou bien moins qu'une technique pour échanger des informations ou pour adapter des pages Web. Chacun semble le percevoir en fonction de ses préoccupations propres.

En fait, XML est une manière de prendre en compte le contenu de l'information pour la traiter, la véhiculer et la présenter. Il s'applique donc à tous les domaines de l'informatique et des systèmes d'information.

XML va permettre de très nombreuses applications, dans des domaines très différents.

XML trouve ses applications notamment dans :

la gestion et l'organisation de bases de documents riches l'interface entre les bases de données, applications et bases de documents l'édition multi-supports et la diffusion de pages HTML ou XML adaptées à des terminaux et utilisateurs différents l'EDI le référencement et la description de ressources etc.De ces nombreuses possibilités vont naître d'ailleurs des divergences d'appréciation et des tendances parfois centrifuges dans le développement des normes et standards construits à partir d'XML. Déjà s'opposent dans certains domaines, par exemple en ce



qui concerne le dossier médical, ceux qui veulent proposer des structures pour la gestion et l'organisation des dossiers eux-mêmes et ceux qui privilégient une approche pratique limitée aux échanges entre systèmes hétérogènes existants.

Au delà de ces débats, il reste qu'XML permet une vision d'ensemble, et sans doute va y inciter. Ainsi, le débat évoqué ici va s'estomper parce que les deux points de vue vont se rapprocher. Les travaux sur les échanges vont influencer à terme les structures des dossiers gérés dans les bases de données et surtout les systèmes en développement.

Le découpage entre le domaine interne des entreprises et les échanges externes est de moins en moins pertinent du point de vue organisationnel et, avec XML, du point de vue technique. En pratique, pourtant, il reste fondamental parce que le temps de développement des applicatifs internes est bien plus court. Les systèmes multi-partenaires exigent à la fois consensus et mise e œuvre de systèmes de sécurité, donc un effort social et un effort technique importants. Même pour la publication sur le Web, l'introduction d'une nouvelle technique comme XML est gênée par la diversité des systèmes clients et la présence de navigateurs de toutes les générations.

XML est déjà présent dans de nombreux systèmes mais c'est surtout à l'intérieur des systèmes centraux des entreprises et des fournisseurs d'information.

2.2. L'échange inter-applicationsD'une certaine manière, c'est l'origine d'XML et c'est l'application à laquelle la plupart des autres se ramènent.

Microsoft, et beaucoup d'autres offreurs, proposent la démarche très simple du "tableau blanc" pour réaliser ce qui est aujourd'hui une préoccupation importante des gestionnaires de systèmes d'information, l'EAI (Enterprise Application Integration).

Ce mécanisme indique bien le rôle fondamental du langage. L'entreprise doit définir évidemment ses langages et modernes internes (sémantique, organisation des flux) et utiliser ou développer la capacité de tous les systèmes, notamment les bases de données, à produire une représentation d'une information en XML.

Il est en effet très facile d'extraire un enregistrement d'une base et de le présenter sous forme d'un schéma XML. Dès lors, les diverses applications vont, par un mécanisme de "publication – abonnement", écrire et lire dans une application "tableau blanc".



Le schéma montre la mise en relation de deux structures de bases de données.

XML outil simple d’échange d’informations structurées

< ><

>< > < >

< >>

<

< ><

>< > < >

< >>

<

><

< >

< >

< >< > < >

Base Base

Tableau blanc

.

2.3. La publication sur le Web ou les Intranets, les portailsL'impact est ici déjà très important. Il ne s'agit pas du transfert de XML vers les navigateurs, encore que cela s'annonce. Il s'agit d'abord de la préparation des pages HTML vers ces mêmes navigateurs. A terme, c'est tout le fonctionnement du Web qui va se trouver remis en cause.



2.3.1. Création de pages dynamiques

La première application d'XML s'est trouvée être le "push" et elle subsiste désormais dans tous les "canaux" des différents services et navigateurs.

Les serveurs extraient des informations des bases de données et utilisent des formats pré-définis par l'utilisateur ou par un service pour adresser à chacun ce qu'il a demandé. Chaque canal prépare ses pages à partir d'un document XML qui précise quelles données sont à placer et où. Ce principe se retrouve dans toutes les applications sur le Web – ou les Intranets.

< ><

>< > < >

< >>

<

><

< >

Base

outil de création de pages

XMLpourproduireHTML

HTML

XML

canal pré-défini



2.3.2. Transmission de données et mises à jour

XML va être utilisé (est utilisé en Intranet) pour n'envoyer des données à des utilisateurs, ou à des pages déjà prêtes sur le serveur, sans rafraîchir toute la page, ce qui réduit de beaucoup les transferts. Ainsi, un prix, une statistique, une grandeur météorologique etc. peuvent être mis à jour de façon régulière. Ils sont repérés par une balise et suivis par une mini-application.

< ><

< >> ><

BaseXMLpourplacer des donnéesdans HTML

HTML

< >

< >

2.3.3. Présentation sur de multiples supports

Le Web se diversifie et sera bientôt couramment accessible depuis un ordinateur graphique très puissant, une petite machine de poche, une télévision, un téléphone.

Non seulement les caractéristiques de l'écran mais l'usage de ces différents outils vont amener à différencier les informations ou les pages qui sont adressées. Déjà aujourd'hui,



des sociétés issues en général de la mouvance SGML (car la multi-présentation y était à l'ordre du jour) proposent des serveurs qui sont capables d'extraire automatiquement des données et documents d'une base unique et de les transférer vers une station de travail, un PC, un organiseur Palm, un téléphone WAP. Le profil de la page envoyée est, comme on pouvait s'y attendre, assez différent.Le principe est toujours le même : définition d'un extracteur XML et application d'un format prédéfini qui va se présenter sous la forme d'une feuille de style XSL pour chaque support. Ces applications sont d'abord réalisées sur des documents qui sont stockés avec des balises, donc en général des documents SGML, parce que le travail de structuration est effectué.

Il faut toujours en effet rappeler qu'il n'y a pas de solution miraculeuse. Pour savoir qu'il faut adresser les schémas détaillés à la machine graphique mais les prix à jour au téléphone, il faut avoir analysé l'information et structuré les documents auparavant, ou le faire à la volée. C'est pourquoi les documents déjà stockés en SGML (comme les documentations techniques ou les dictionnaires) permettront des applications immédiatement plus riches.

Le schéma montre la diffusion vers un micro-ordinateurs, vers un système d'impression et vers un système de lecture vocale.

Structure type

Définition etorganisation deséléments(balises, structure)

< >A< > (relation B C) B< >C

< ><

>

< > < >

< >>

<

Document

/AAB

C /C

/B

Outils de mise en page

un affichage...

une page...

en vocal...

Distinction structure, contenu, mise en pageDiffusion multi-supports



2.3.4. La personnalisationD'ores et déjà, la personnalisation qui est à l'œuvre dans beaucoup de services est réalisée grâce à des profils d'utilisateurs qui sont exprimés en XML. La génération des pages est effectuée de façon dynamique grâce à une combinaison de formats pré-définis en XML, dont les éléments sont remplis grâce à des profils utilisateurs eux aussi écrits en XML. La diffusion et le formattage se font en utilisant des feuilles de style prédéfinies pour les différentes cibles (cf. supra multi-diffusion) et qui produisent des pages HTML. Demain, ces mêmes pages pourront être en XHTML, version rigoureuse du langage, désormais oonforme à la grammaire XML générale.

< ><

>< > < >

< >>

<

><

< >

une requête. un autre affichage...

un affichage...

Feuilles de style (profils, présentation XSL)

Données, documents XMLBase donnéesdocuments

Extraction

Requête (CGI etc.)

Feuilles stockées

Serveur WEB(HTTP)

petite machine

L’utilisation d’XML par les sites Web pour personnaliser et adapter les réponses



2.3.5. Les portails

Les portails, la nouvelle vague des applications en entreprise et sur le Web, sont en fait essentiellement la combinaison entre deux types d'application :

- la personnalisation de l'accès et de la publication- l'accès depuis un serveur frontal à des passerelles vers de multiples sources d'information, dans l'entreprise ou sur le Web (bases de données, bases de documents etc.)

XML joue un rôle essentiel dans ce développement. Du côté de l'utilisateur, il assure la personnalisation. Du côté des données, il va permettre de constituer une base de "méta-données" sous forme de fiches XML, qui vont décrire les informations accessibles. Il peut également permettre de gérer une partie des données sur le site du portail lui-même, mais ceci n'est qu'un problème d'optimisation.

(cf. infra la gestion des données)

2.3.6. Le retour utilisateur : WebDAV

Web direct authoring and versioning est une spécification en discussion au W3C. Elle va normaliser les conditions d'une mise à jour directe, depuis un navigateur, par une personne autorisée. C'est un autre composant essentiel d'un Web de plus en plus dynamique : le responsable d'une page particulière dans une organisation pourra directement transférer des fichiers et des données vers la zone qu'il contrôle. Du point de vue des systèmes d'exploitation des ordinateurs, il sera possible de faire apparaître des dossiers du site de façon absolument identique à ceux du disque de l'utilisateur, entre autres. Cette capacité est déjà utilisée par des offreurs de services (par exemple de simple sauvegarde, ou des systèmes de travail collaboratif).

Evidemment, WebDAV est un langage XML particulier, qui détermine pour les logiciels le contrôle de l'échange des ordres entre le serveur et le navigateur (ou un autre client).

2.3.7. Un Web de plus en plus dynamique

Ainsi, l'impact d'XML sur le Web sera très grand. Pour l'essentiel, sa diffusion et généralisation vont permettre le développement d'un Web support d'applications et de communication de données, ramenant la partie "présentation" et vitrine du Web à de très modestes proportions par rapport aux parties dynamiques et automatiques. La plus grande partie des pages sera générée à la demande, à partir d'applications et de bases de



données et d'une bibliothèque de feuilles de style. De ce fait, d'ailleurs, le rôle et le fonctionnement des moteurs de recherche sera profondément transformé puisque les pages statiques ne domineront plus. Les sites devront donc présenter leur organisation, leurs données et leurs fonctions dans une vitrine spéciale.

Heureusement, les sites se présenteront grâce à des "meta-données" en XML…

2.4. XML pour la gestion des données

2.4.1. XML et la gestion de contenu / GED

L'un des géniteurs de XML est SGML, qui est la norme ISO pour constituer et gérer des documents. La question qui est d'ailleurs posée aujourd'hui aux spécialistes de SGML est l'avenir de celui-ci par rapport à XML. Cependant, d'une part, la rigueur de SGML n'a pas entièrement été maintenue non dans la syntaxe des langages XML mais dans les applications. Il est d'ailleurs normal que la rigueur ne soit pas de même ordre que celle exigée pour des documents statiques lourds décrivant l'agencement des pièces dans un moteur d'avion. De plus, les outils SGML sont nombreux, puissants, documentés, industriels, ce qui est loin d'être le cas pour XML.

Il n'empêche que, en tout cas pour toute une nouvelle classe de documents, XML va être utilisé. Ce sera en particulier le cas pour stocker les documents issus d'échanges EDI – par exemple une prescription médicale.

La question du mode de stockage des documents

La question de la relation entre SGML et le stockage des documents s'est posée depuis longtemps.

Dans le cas de SGML, les documents sont en pratique des ensembles très lourds. Plusieurs cas se présentent, qui peuvent être illustrés par exemple, en France, par les Documents Techniques d'Urbanisme (CSTB) ou les bases dictionnaires d'une société comme Larousse.

Pour gérer des données, il faut construire un modèle des relations, qu'il s'agisse d'un dictionnaire ou d'un système d'information. Le modèle du dictionnaire va exprimer des relations entre des entités (les entrées) et un certain nombre d'éléments qu'elles contiennent, des groupements par lettres etc. Le modèle des DTU va comprendre un certain nombre d'éléments avec des contraintes conditionnelles etc.



Dans les deux cas, ce type de structure peut s'exprimer en SGML par une DTD et peut aussi s'exprimer dans une structure de base de données relationnelle.

La gestion est bien alors celle de données, non de documents. En effet, dans le second cas, il s'agit de considérer des documents comme un ensemble et de les retrouver en effectuant des recherches documentaires. Ici, il s'agit de pouvoir effectuer des extractions sélectives – notamment dans la base dictionnaires – pour produire des dictionnaires spécifiques, résumés etc.

Cependant, il serait possible de structurer la base directement à partir de la DTD SGML, et une base de données orientée objet serait sans doute plus adaptée qu'une base relationnelle. Ce sera encore plus vrai avec XML, plus directement orienté objet (les schémas supportent l'héritage).

Le support de XML dans les systèmes

La plupart des offreurs de systèmes de GED annoncent aujourd'hui le support d'XML mais il faut s'entendre sur la signification de cette assertion.

Les propositions les plus crédibles sont celles d'offreurs de systèmes de gestion de documents SGML et en général de sociétés ayant une expérience ancienne du domaine. Elles proposent effectivement des bases contenant des documents SGML et savent y effectuer des recherches en utilisant les structures et les sémantiques des documents. De tels systèmes peuvent mettre à jour des éléments retrouvés dans un document, gérer des versions etc. Les spécialistes de ce type indiquent qu'ils attendent la véritable arrivée de documents XML pour appliquer les capacités de leurs produits mais qu'il ne s'agit actuellement que de potentiel. Ce d'autant plus que les nouveaux outils de recherche et de gestion purement XML, XQL, Xlink, Xpointer, n'en sont qu'au stade de draft et que l'accord n'est même pas fait dans le monde XML sur les méthodes en ce domaine. En revanche, il est certain que l'ensemble des outils en développement permettra de construire des systèmes puissants et ouverts de gestion à l'intérieur des réseaux d'entreprise, voire de réseaux partagés.

La situation même des standards fait justice des annonces les plus osées. Il existe cependant de véritables solutions qui se limitent à gérer les documents avec les moyens actuels, mais proposent effectivement de les stocker en XML (cf. Software AG Tamino) De telles solutions sont aussi utilisées par des systèmes serveurs qui transforment, par exemple, en utilisant XML, les pages de documents de PAO et les gèrent ainsi.

L'autre manière d'utiliser XML est de créer une base de références en XML, c'est-à-dire de méta-données pour décrire des documents situés sur le réseau de l'entreprise, et de



gérer cette base. C'est ce que font les nombreux logiciels portail qui se diffusent actuellement (ex. Sequoia)

Les bases pour stocker les documents XML

L'utilisation de documents XML et la prolifération de leurs échanges impose ou va nécessiter de se poser les questions suivantes :

Quelle peut-être la meilleure solution technique de stockage des documents XML ?

Les technologies actuelles les plus répandues de base de données relationnelles ou objets permettent-elles de répondre totalement à cette problématique ?

Cette question est un peu différente de celle qui se pose pour le stockage de données, pour lesquelles le document XML n'était qu'un véhicule.

Afin d'éviter toute confusion, il est important de noter les points suivants :

La problématique du stockage des documents XML, que nous abordons dans ce paragraphe, est à dissocier de celle du langage de requête utilisé pour accéder à l'information contenue dans un document XML. Le second réfère au langage de requête XQL présenté précédemment, le premier à une problématique de structure technique de bases de données.

Un document XML comporte des données et des balises reflets de la structure du document. Le problème à résoudre est uniquement celui du stockage des données, non celui des balises, la gestion des balises est du ressort d'une application ou du gestionnaire de la base de données.

La gestion des données serait sans doute plus naturelle dans l'environnement des bases orientées objet, mais – et c'est leur problème général, les bases objet ont un marché beaucoup plus restreint que les bases relationnelles, et c'est pourquoi les systèmes vont le plus souvent être construits autour de ces dernières.

La tendance actuelle est donc aussi de voir les offreurs de ces produits ajouter des interfaces et des fonctionnalités permettant de manipuler des documents XML ; c'est le cas de la version 8i d'Oracle comme de la version SQL Server 7 autour de laquelle Microsoft construit ses architectures XML et son offre Biztalk.

Les bases orientées objets présentent quant à elles de nombreuses caractéristiques nécessaires au stockage et à la manipulation de documents XML. Ces bases de données permettent une représentation aisée de la structure hiérarchique d'un document XML et plus important les nœuds dans la structure d'un document peuvent être associés à des objets.



Ces deux types de solutions semblent répondre aux besoins pour le développement de projets XML. De plus, le nombre important d'utilisateurs de bases relationnelles, voire objet, permet de penser que les adaptations nécessaires pour répondre plus précisément aux besoins XML seront effectuées lorsque les différentes spécifications se seront stabilisées.

Au de-là de ces deux types de bases de données pouvant être utilisés dans un environnement XML, apparaissent aujourd'hui sur le marché de nouveaux produits intitulés "serveur XML" dont le plus connu est le produit Tamino de la société Software AG. Ces produits stockent des objets XML sans transformation de format ; Les objets peuvent être du texte, des images, des sons ou des tables relationnelles. Ce type de "serveur d'information" interface avec les produits "classiques" du marché, base de données relationnelles ou les produits bureautiques. L'absence de recul sur l'utilisation de ces produits ne permet pas d'en préciser les aptitudes ou performances opérationnelles.

Conséquences de l'utilisation d'XML pour la description des documents

XML va aussi être utilisé pour créer des bases d'information constituées de méta-données permettant de documenter, notamment, les ressources sur le Web ou dans un réseau d'entreprises.

Le catalogage en documentation a utilisé des méta-données - données structurées à propos des données - bien avant XML. Les formats traditionnels MARC et RCAA2 (Règles de catalogage anglo-américaines) peuvent techniquement remplir les fonctions d'indexation du Web : MARC définit la syntaxe de transport et les RCAA sont les règles qui régissent l'énumération des méta-données. Mais, pratiquement, la masse d'informations est telle que ce travail pour bonne part manuel, est trop important pour la gestion courante de fonds documentaires ou pour l'indexation de sites Web.

Le monde de la documentation a donc conçu une norme pour la description des ressources d'information, le Dublin Core (DC). Cette norme de méta-données descriptive, est composée de 15 balises pour la description des documents :

éléments sur le contenu du document : titre, sujet, description, source, langage, relations avec d'autres sources, et couverture, c'est à dire référence de temps et d'espace. éléments liés à propriété intellectuelle de la ressource : créateur, éditeur, contributeur, droits. éléments correspondants à la matérialisation de la ressource : date, type, format, identifiant.



Tous les éléments sont optionnels et répétables, on peut créer des sous-éléments (par exemple rajouter sous "auteur" des champs "contact", "surnom", etc.).

Le récipient de telles métadonnées pour les documents Web, le RDF (cf. ci-dessus), s'exprime en XML. Il permet de dépasser l'hétérogénéité des applications s'échangeant des métadonnées, avec une syntaxe exprimée en XML, mais une sémantique librement définie par les utilisateurs. RDF est un cadre qui peut recevoir Dublin Core et d'autres normes existantes et futures. Une fois le cadre et la sémantique normalisés, les données sont plus efficacement traitées par machine avec des zones d'information spécifiées.

L'utilisation des méta-données balisées XML dans le monde Internet enrichit les traitements possibles. Elles permettent de décrire précisément les relations entre des éléments dans un corpus de documents (site Web), et leur contenu. Pour les moteurs de recherche, la présence de champs et zones à l'instar des bases de données ne peut qu'améliorer la pertinence des résultats. Par conséquent, les agents intelligents rapatrient eux aussi des résultats meilleurs que par le butinage des pages HTML. Le contenu peut être classé selon des degrés de difficultés ou selon des publics types. Les balises peuvent aussi stocker des informations pour la protection des droits d'auteur, des règles et autorisation de diffusion/reproduction des documents. La signature numérique peut être encodée.

Des documents multi-usages et adaptables

Une entreprise vendant des produits à l'échelle internationale doit être en mesure de produire une abondante documentation : documents de garanties, mode d'emplois et catalogues, qui seront adaptés à chaque pays. En Espagne, si le modèle A de produit n'est pas commercialisé, le catalogue devra tenir compte de cette absence. Tous ces documents seront traduits pour chaque langue de commercialisation, et seront conformes aux législations de chaque pays importateur. Chaque produit, chaque modèle est également susceptible d'évoluer régulièrement : nouveau prix, nouvelles fonctions, nouvelles options, etc. De plus, si cette entreprise travaille avec plusieurs supports, les documents devront être produits pour les versions papier, Internet, CD-ROM, etc., dans toutes langues des marchés.

La gestion des éléments d'information

XML permet de traiter l'information à un niveau plus précis que le document : les éléments d'information. En délimitant et définissant des zones d'information dans un document, le traitement peut porter sur un paragraphe, un chapitre, une petite unité. La gestion individuelle de chaque élément permet donc la publication ou non pour chaque élément sur un support donné, et le ciblage des utilisateurs. Tels profils d'usagers auront



tel type de document, adapté à leur besoin et compétences techniques, par exemple. Les éléments peuvent être réutilisés dans différents documents, et lorsqu'un changement intervient sur un élément, tous les documents l'utilisant seront automatiquement mis à jour.

Cette gestion par éléments permet aussi le travail collaboratif simultané de plusieurs personnes sur un même document, chaque personne travaillant sur des éléments définis. Dans le cas de la traduction, cela permet à un rédacteur de produire le document original et à un autre d'en commencer la traduction dans une autre langue avant même que le document ne soit complet.

2.4.2. XML pour créer et maintenir un référentiel de données normalisées

L'utilisateur d'XML a besoin de référentiels de données, puisque XML permet le transport de données signifiantes. Or, la mise au point et la maintenance de référentiels peuvent précisément tirer avantage d'XML.

L'exemple du BSR (cf. ci-dessus) est a priori parlant. Chaque définition de données est considérée comme une classe, et les commentaires placés à droite spécifient de façon de plus en plus précise des définitions. Malheureusement, le BSR n'est actuellement pas structuré par un langage XML. En outre, le BSR contient pour chaque définition la traduction en plusieurs langues et l'arbre XML prendrait cela en compte.

Le maintien d'un référentiel se fait par échange de messages XML et il importera que, dans les réseaux d'entreprise comme dans les réseaux de communautés ou dans des espaces publics, un langage particulier normalisé permette de récupérer des données et d'en transmettre.

Comme cela a été indiqué, les dictionnaires sont essentiels. Au delà des données, les schémas vont véhiculer des structures et des relations entre données, ainsi que des indications sur les unités et les contraintes (le typage). Progressivement, un espace sémantique riche peut être mis en place.

Pour ce qui concerne les schémas et DTDs, OASIS et le W3C ont commencé d'exprimer les contraintes pour les requêtes aux répertoires.

2.4.3. XML outil de création et de gestion de méta-données

Un aspect essentiel des possibilités ouvertes par XML est la gestion de méta-données.



Dans un espace ouvert et hétérogène, la seule voie pour permettre l'interopérabilité et l'accès aux systèmes d'information extérieurs et aux données réparties dans des bases diverses est de s'accorder sur des méta-données. Devant les bases de données, devant les sites Web, les applications etc., il est possible de placer des descripteurs précisant les contenus, la structure, les liens, les caractéristiques.

Actuellement, les pages des sites Web contiennent quelques balises meta qui permettent aux moteurs de repérer quelques informations sur les contenus mais c'est très insuffisant. Tous les systèmes de repérage actuellement mis en place dans le Web (PICS, Dublin Core) sont des structures RDF exprimées en XML (cf. ci-dessus). Il en est de même de XMI pour les méta-données décrivant la structure des bases de données et systèmes d'information. Ainsi, chaque base de données et ressource va être accompagnée d'ensembles d'informations en XML, qui constitueront elles-mêmes des bases de données sur les données.

2.4.4. XML comme format de stockage de données

Dans le cas d'XML, et contrairement à SGML, la question peut se poser rapidement de la relation entre le format d'échange de données qu'est XML et le format des bases de stockage.

En effet, XML est précisément adapté à transporter et transférer des informations issues des bases de données. Il en décrit la structure et transporte en fait des images d'extractions des bases (enregistrements, séries de valeurs). Les bases de données vont donc se doter de mécanismes pour importer et exporter en XML. Progressivement, les dictionnaires de données utilisés pour désigner les éléments dans les bases relationnelles ou objets vont se rapprocher des dictionnaires utilisés pour les transferts, même dans le cas d'échanges externes.

Avec en sus des outils de requête qui apparaîtront pour l'utilisateur comme interrogeant une structure XML, les bases apparaîtront comme utilisant XML pour le stockage.

Il reste que les structures et modes de gestion optimisés des bases de données n'ont guère de rapport avec le système d'expression de structure qu'est XML.

2.5. XML comme outil informatique de baseXML n'est pas un langage de programmation, comme C ou Java, mais un langage de description de données et documents. Cependant, les frontières ne sont pas toujours



nettes et surtout la synergie entre un ensemble de technologies nouvelles amène à reconstruire des éléments de base des systèmes et des outils informatiques.

2.5.1. L'unité d'un ensemble de technologies nouvelles : modélisation objet et XML

Ce n'est pas la volonté du Web consortium, ni les actions de tel ou tel offreur, qui ont déclenché l'engouement pour XML mais aussi pour des technologies pourtant relativement complexes : UML, CORBA, Java. C'est le résultat en même temps que le moyen d'une évolution profonde des systèmes d'information.

Devant la complexité croissante des organisations et les exigences des utilisateurs, notamment en matière de rapidité de développement, pratiquement tous les services informatiques d'entreprise et les SSII ont adopté des démarches objet : production et réutilisation de composants objet. Ils ont aussi adopté une vision répartie de l'informatique, dans laquelle la localisation des traitements doit demeurer secondaire.

Ces démarches sont maintenant largement suivies.

En même temps, la banalisation du Web a contraint à une évolution rapide vers une bien plus grande ouverture des systèmes d'information sur l'extérieur. Cette évolution est renforcée par la mobilité des personnels et par les reconfigurations fréquentes des entreprises avec des fusions acquisitions, des modifications de la distribution, la création de liens divers internationaux etc.

Dès lors, la pression au partage et à la répartition devient très forte, et quatre technologies fondamentales se retrouvent dans un mouvement commun :

- UML pour modéliser les processus et partager les modèles, pouvoir les échanger- CORBA pour faire se parler tous les systèmes, quel que soit le langage- Java pour implanter des applications réparties indépendamment des plate-formes, partout où une Java Virtual Machine peut exister- XML enfin qui est aux données ce que ces techniques sont aux objets logiciels

La synergie entre ces différentes techniques est désormais évidente. Le mouvement "open source" et son produit phare, Linux, participent aussi, d'ailleurs, de cette nouvelle approche de l'informatique – notamment en raison du co-développement réparti que ce mouvement implique.

Comme cela est souvent indiqué, ces techniques permettent de former des couples idéaux (a marriage made in heaven… disent les américains). Une fois de plus, ce n'est pas un hasard, puisqu'elles résultent d'une évolution commune.



• UML répond à la nécessité de faire se parler des systèmes indépendamment des implémentations techniques et de permettre à la fois diversité, changement de partenaires et d'organisation, évolution des outils de base mais aussi pérennité. Pour cela, la modélisation est indispensable, à un niveau supérieur au simple développement d'applications ou, pour les échanges, de messages.

• UML permet une modélisation partageable mais aussi orientée objets, et donc la mise en œuvre des trois autres techniques à partir d'éléments de modélisation qui peuvent être directement appliqués aux outils orientés objet. Cela ne signifie pas, d'ailleurs, que les outils souvent plus précis liés, entre autres, à l'approche relationnelle, doivent être abandonnés. Ils sont seulement plus près de la réalisation pratique, UML donnant une vue plus générale.

• CORBA et Java ont des passerelles (entre les Enterprise Java Beans, les objets Java et les interfaces des objets conformes à CORBA – cf. ci-dessus in "XMI")

• La parenté est très grande enfin entre XML et l'approche objet. En fait, les objets métier vont souvent se parler en se transmettant des messages XML. Les schémas vont être conçus de façon à représenter la sémantique de ces échanges, et vont, grâce à une modélisation, refléter effectivement ce que des objets du monde de l'assurance, de l'automobile ou de la santé ont à échanger.

Surtout, UML va permettre de réaliser des outils de génération automatique de messages XML inter-applicatifs (EDI intra ou inter-entreprises).

Enfin, comme cela va être vu, le mariage va plus loin en ce que XML va permettre de véhiculer des ordres d'exécution entre les objets.

Le schéma suivant évoque l'enchaînement des technologies.



UML

ApplicationsObjets

couplage serré IIOP, EJB, DCOM

échange par messages

Modélisation

XML

couplage XML + SOAP (cf.infra)

ApplicationsObjets

Tous systèmes

Espace Java

Espace Windows

CORBA

Java

DCOM

Des technologies...

2.5.2. XML pour la mise en relation des applications et l'informatique répartie

L'insuffisance de l'approche "tableau blanc"

La nouvelle étape de l'informatisation, dans les grandes entreprises en particulier, est "l'EAI", Enterprise Application Integration. C'est la capacité à intégrer les applications hétérogènes – ce qui signifie une démarche nouvelle par rapport à la refonte systématique des systèmes d'information et à la conception de vastes systèmes intégrés. L'autre application en rapide développement est le portail d'entreprise, qui est chargé d'intégrer les ressources d'information.

Comme cela a été vu ci-dessus (échange inter-applications), les tableaux blancs et les portails s'appuient largement sur XML.



Ces mécanismes sont plus légers et plus souples que les systèmes d'intégration en client-serveur et les systèmes de communication inter-application formés à partir des Object Request Brokers.

Cependant, ils ne peuvent répondre à des besoins d'intégration dans lesquels deux applications se mettent directement en relation et se demandent mutuellement des services.

Or, dans des cas de plus en plus nombreux, l'informatique est véritablement répartie, c'est-à-dire que des applications sont créées qui mettent en jeu des systèmes distants, lesquels se demandent l'un l'autre l'exécution d'opérations par des "appels de procédures à distance" (Remote Procedure Calls). Les méthodes correspondantes ont d'abord été définies comme des requêtes procédurales échangées au travers de protocoles en leur temps développés notamment par le forum pour les systèmes ouverts (OSF). Les objets métier interagissant sont ensuite apparus et leurs interfaces sont normalisés par différents groupes ou industriels, le plus important étant l'Object Management Group.

Cette évolution aurait pu être distincte de celle du Web, avec des canaux plus directs entre les entreprises et, du point de vue des protocoles, l'utilisation de dialogues de type "protocoles inter-objets" définis par l'Object Management Group ou, dans les univers particuliers de Microsoft et de Java, DCOM ou les invocations de procédures Java (Java RMI).

Pourtant, il a paru de plus en plus opportun de permettre que soient utilisés, pour transmettre les ordres entre des applications et objets, les mécanismes universels que sont HTTP, SMTP et les messages en XML, et ce d'autant que les autres protocoles sont souvent arrêtés par les pare-feu.

Il a aussi paru indispensable de faire se parler les modèles d'objets de Microsoft, IBM ou Sun. Dès lors, le Web et les technologies Internet devaient de nouveau jouer leur rôle d'unificateur de systèmes hétérogènes, et c'est ce qui est en train de se passer avec le développement de protocoles de dialogue utilisant XML et, parmi eux, de celui qui semble devoir s'imposer, SOAP – Simple Object Access Protocol.

Le monde semblait bien ordonné : la construction de systèmes objet ou client serveur était clairement distincte de la mise en place de systèmes de type EDI internes ou externes.

Pourtant, une fois encore, rien n'est simple. XML est très flexible et efface les frontières de l'informatique, et les messages peuvent véhiculer des commandes…



Les systèmes d'interaction entre objets

Sur le Web comme dans les entreprises, il est possible d'utiliser des systèmes de dialogue objet à objet.

Actuellement, les mécanismes de communication entre objets sont des outils CORBA ou DCOM, ou encore des interfaces propres à Java et permettant de créer des requêtes (Remote Method Invocation) entre objets Java (les Java Beans sont les interfaces dans cet univers). CORBA est le standard de l'OMG, DCOM celui de Microsoft (respectivement Common Object Request Broker et Distributed Component Object Model). Ces systèmes définissent des méthodes de dialogue et des interfaces afin de permettre à une application de parler à une autre, grâce à des interfaces normalisées. Le transport des requêtes entre applications sur le Web se fait par des protocoles spécialisés : chez Microsoft, DCOM intègre le protocole. Le protocole issu de l'OMG est l'Internet InterORB Protocol, IIOP, qui est déjà inclus dans Netscape, entre autres.

La technique alternative, le Message Oriented Middleware, consiste à tolérer des échanges par message, donc moins d'intégration que par les échanges inter-objets. Ces échanges se font en XML et sont véhiculés par le protocole le plus courant du Web, HTTP. Les objets eux-mêmes peuvent être dotés d'interfaces leur permettant de générer les messages XML.

Le développement du Message Oriented Middleware consiste à permettre aux applications de communiquer en créant des messages XML contenant aussi des ordres de programmation, des commandes applicatives, des commandes aux objets. Cette technique a été proposée par plusieurs sociétés de développement et Microsoft à l'IETF, sous le nom de SOAP - Simple Object Access Protocol. Il faut noter que le type de commande véhiculé ainsi peut être conforme à différentes syntaxes et langages (comme entre autres Java, COM, CORBA).

Vers l'utilisation d'XML pour les liaisons objet : SOAP

SOAP (Simple Object Access Protocol ) est développé depuis deux ans par Microsoft, UserLand, et Developmentor.

SOAP répond à deux préoccupations : dépasser l'hétérogénéité désormais inévitable des protocoles et des méthodes d'interconnexion des objets dans les systèmes d'entreprise, et faciliter simultanément leur déploiement, notamment dans l'inter-entreprises.

Sur le premier point, force est en effet de constater que les trois techniques co-existent. CORBA domine dans les systèmes d'entreprises, suivi par Java puis par les outils DCOM du monde Windows. Or, il est nécessaire pour un très grand nombre d'entreprises d'intégrer les serveurs et systèmes Ws 2000 aux environnements UNIX et aux grands systèmes.



La préoccupation des développeurs était que des échanges XML puissent véhiculer des mécanismes de sérialisation des commandes, de traitement de Namespaces spécifiques d'une procédure, de mécanismes génériques contrôlant la persistance des objets invoqués etc.

Le ralliement d'IBM puis de Sun garantit maintenant une interopérabilité des applications et va faire de SOAP la lingua franca des objets divers, y compris s'ils se parlent en utilisant, entre autres, les primitives définies par le langage IDL de l'OMG. Une fois encore, XML fournit un langage pour exprimer des structures et véhiculer des informations.

La version 1.1 de SOAP, désormais disponible, vient d'être soumise au W3C pour homologation. SOAP est maintenant supporté par un ensemble croissant d'industriels, dont Ariba, Commerce One, Compaq, Extensibility, IONA, Intel, IBM.

Il est maintenant très vraisemblable, compte tenu des sociétés participantes, que la proposition SOAP va s'imposer. L'impact peut être à terme important aussi sur l'EDI (cf. infra l'évolution de l'EDI).

2.5.3. XML ne remplace pas tout…

Certes, beaucoup d'applications pourraient être revues avec les nouvelles technologies disponibles. L'effet de mode ou la passion technique aidant, des offreurs intéressés vont souvent prétendre qu'il faut tout revoir en XML (ou en UML, objets etc.). Certains dans les entreprises seront tentés.

Or, la situation est toujours la même en informatique : le changement est coûteux et doit être justifié pour les systèmes existants. COBOL n'a pas disparu de nombreuses chaînes de traitement.

En outre, les techniques nouvelles ne sont pas toujours mûres, les outils ne sont pas prêts – ce qui va se vérifier avec l'EDI.

Surtout, XML n'est pas obligatoirement préférable aux techniques installées. Il n'y a certainement aucune raison de remplacer des bases relationnelles par des bases stockant de façon native des documents de structure purement hiérarchique. Les bases gérant XML ont d'autres objectifs et ne seront pas employées pour l'enregistrement de comptes bancaires… Ainsi aussi, comme cela a été rappelé, une majorité actuellement de spécialistes XML conteste le développement de XQL, parce que SQL remplit très efficacement sa fonction.



Dans de nombreux cas, la conversion vers XML risque d'être un pur exercice de style, dont l'utilité reste à prouver. ASN1 en fournit peut-être un exemple.

Encodage d'ASN1 en XML : XER

ASN1, Abstract Syntax Notation One est une grammaire ou un métalangage spécifique de description de messages principalement tourné vers l'écriture de protocoles de communication. ASN1 est subdivisée en deux parties :

Les règles de syntaxe pour décrire le contenu d'un message en terme de type de données, de séquence et de structure du contenu,

La manière de coder chaque élément dans un message.

ASN1 est définie par deux normes ISO :

- ISO 8824/ITU X.208 spécifie la syntaxe,- ISO 8825/ITU X.209 spécifie les règles de base de la codification ASN.1.

C'est un langage de notation pour développer des applications dans le modèle OSI (Open System Interconnection).

Le réflexe XML a amené certains auteurs comparer les deux métalangages que sont ASN1 et XML, tous deux utilisés pour l'écriture de messages. Les comparaisons ont principalement porté sur le volume d'octets à transmettre pour décrire un message et la lisibilité du message. Ces travaux ont débouché sur la production de règles appelées XER ou XML Encoding Rules, se résumant en une tentative de décrire ASN1 comme un sous-ensemble de XML.

Il est très difficile de porter une appréciation sur l'utilité et l'avenir de tels travaux en l'état actuel des développements.



3. XML EDIDans le domaine de l'EDI, chacun compare XML à EDIFACT. Ce dernier n'a lui-même convaincu les communautés d'utilisateurs que récemment (cf. la partie précédente sur l'EDI). La comparaison n'est en fait pas pertinente. EDIFACT tire son avantage et ses limites de ce qu'il est, c'est à dire un ensemble prêt à l'emploi qui comporte à la fois les données, les dictionnaires de segments et messages, les règles syntaxiques. Fondamentalement, c'est une organisation positionnelle des données dans un fichier avec des indicateurs de rang et de position plus importants que la nature de la donnée. XML n'est au départ associé à aucun dictionnaire ou règle particulière, c'est un outil brut de base. A priori, le caractère formel de la grammaire sous-jacente et la richesse des possibilités laissent présager qu'XML sera plus puissant à terme.

La question du volume des messages a été posée. Il est vrai qu'XML est bavard, alors que EDIFACT a été optimisé, et que les intitulés de segments sont compactés. Actuellement, en moyenne, un message XML devrait occuper un volume double de celui d'un message EDIFACT. Cette remarque doit être nuancée : d'une part la bande passante est malgré tout moins rare que par le passé, d'autre part ces messages sont de toutes façons peu volumineux et, de plus, XML peut être fortement réduit par la compression, car il est précisément assez bavard (répétition de chaînes de caractères).

La "comparaison" étant en soi peu intéressante et peu pertinente, elle sera évoquée pour ne plus y revenir.

3.1. "Comparaison" de solutions EDIFACT XMLIl n'y a guère de sens à comparer XML et EDIFACT, d'autant que, dans un cas, il s'agit d'une grammaire sans presque aucun langage stabilisé et située dans un vaste chantier, dans l'autre d'un langage sans grammaire, avec un environnement pratique divers mais relativement important. Les éléments de comparaison qui suivent ne portent donc pas sur EDIFACT et XML mais sur les solutions construites sur ces deux techniques.

En tout état de cause, les caractéristiques du monde XML ne sont que très transitoires et les comparaisons valent pour quelques mois. En revanche, des tendances claires permettent d'indiquer des évolutions de long terme.



3.1.1. L'économie des produits et services

EDIFACT est né dans un environnement de rareté des télécommunications et de développements par de grandes structures. En outre, c'est une technique relativement isolée du reste de l'informatique. Les sociétés, souvent petites, qui ont développé des logiciels, sont restées dans une économie de progiciels coûteux à l'achat. En outre, l'ergonomie et la finition de ces systèmes en rendent la mise en œuvre relativement difficile et exigent souvent un suivi spécialisé.

Une première différence, essentielle, dans les coûts, provient des liaisons télécom. Sur les RSVA, les connexions dédiées entraînent des prix élevés, pouvant dépasser 100 F par message. Les coûts liés à Internet sont beaucoup plus bas, et de toutes façons la liaison Internet va être rentabilisée sur de multiples usages. L'effet général d'Internet se fait sentir à plein. Cependant, il s'agit d'une comparaison conjoncturelle : EDIFACT peut, tout aussi bien que XML, circuler sur Internet.

Les traducteurs et les logiciels sont peu nombreux, leur prix se situe, pour les produits les plus simples, dans des fourchettes de 10 à 30 KF. Dès que le logiciel est capable de fonctions plus avancées, notamment de s'interfacer avec des bases de données, son prix est en moyenne supérieur à 100 KF.

Il n'est pas possible de traiter aujourd'hui du coût des produits XML. D'une certaine manière, les seuls produits stables et industrialisés de haut niveau sont les outils SGML, qui, souffrant des mêmes limites que les logiciels EDIFACT, ont eux aussi une réputation méritée de coût élevé et de mise en œuvre difficile.

L'avenir se dessine déjà pour XML : c'est la gratuité pour les stations clientes, à l'intérieur de tous les produits du marché. Soit les produits seront gratuits, soit ils seront inclus dans des suites bureautiques et de communication, sans en élever le prix.

Sur les serveurs, de grands logiciels multi-usages vont apparaître, qui seront capables de gérer XML en interne et externe (cas par exemple des serveurs Biztalk de Microsoft). A la différence des traducteurs et outils du monde EDIFACT, ces produits seront intégrés avec d'autres fonctions, dans des systèmes de commerce électronique, des ERP (Enterprise Resource Planning - systèmes de gestion intégrés), portails etc. Ainsi, le serveur EDI dans le monde EDIFACT était dédié et son prix pouvait se trouver dans des fourchettes de 60 à 600 000 F. En revanche, les EDI XML seront gérés sur des serveurs Web qui, en assurant de multiples fonctions, sont nettement moins coûteux (de 6 000 à 40 000 F).

Globalement, XML va donc se développer dans une économie très différente, caractérisée par l'ouverture, la normalisation et la concurrence. Beaucoup des produits



gratuits qui existent aujourd'hui, et qui sont encore au stade de prototypes et de logiciels de recherche non industrialisés vont se diffuser, habillés par les grands offreurs et intégrés dans leurs produits, mais souvent dans une approche de "logiciels libres", dont le succès est maintenant patent. Les flux économiques se déplacent vers les services associés, les travaux de modélisation etc. Les outils payants les plus coûteux sont d'ailleurs les meta-outils, par exemple de modélisation, comme Rational Rose, mais là encore le niveau de prix a beaucoup chuté par rapport au passé.

Une des raisons de fond de ces évolutions est que le marché de XML est très large et que de très nombreux acteurs vont intervenir, et que les informaticiens compétents vont bientôt être très nombreux, ce qui n'était pas le cas pour EDIFACT.

En outre, l'engouement pour XML dans l'ensemble du monde de la recherche met à disposition des développeurs une très riche bibliothèque d'outils gratuits. Avec l'approche objet et la réutilisation de composants, ce partage d'un fonds commun, caractéristique de l'économie "open source", abaisse beaucoup le coût de développement et de maintenance des logiciels.

Développer des applications XML à l'intérieur des entreprises est d'ores et déjà une pratique assez courante et relativement légère.

3.1.2. Une vue d'ensemble

S'il faut malgré tout comparer les usages possibles des deux langages, il est possible de noter que XML permet une bien plus grande souplesse, surtout avec l'introduction des Schémas et avec l'utilisation des Namespaces et celle des systèmes de renvoi et de pointeurs. En EDIFACT, le message une fois constitué, surtout compte tenu de la manière dont travaillent la plupart des outils, est relativement rigide. La séparation entre les définitions de structures et le message confère une grande souplesse au système de conception XML.

Le risque avec XML tient précisément à la souplesse et au risque d'un usage abusif des libertés que donnent les outils de conversion d'arbres (XSLT) et les Namespaces. La méthode de conception d'EDIFACT impliquait l'intégration de la sémantique métier dans le processus de création de messages. Cette discipline est indispensable avec XML mais elle doit être suivie volontairement.

Les principaux éléments de la comparaison entre les mondes EDIFACT et XML actuels sont rappelés dans le tableau suivant.



Caractéristiques EDIFACT XML

Le langage :

Structure Syntaxe Métalangage

Grammaire Non formel Formel

Dictionnaires associés Oui Non

Lisibilité (par l'homme) Non Oui

Stabilité Oui Non

Maturité Oui Non

Les outils et technologies associées :

Niveau technologique Bas/Moyen Haut

Offre Complète En développement

Interface Base de Données Peu/Pas Oui

Interactivité Non Oui

Support de l'industrie informatique Faible Fort

Stabilité Fort Faible

Adapté à l'EFI (WebEDI) Moyen Fort

Prix Moyen/Elevé Faible

3.1.3. Qualité et conditions de mise en œuvre

Très grossièrement, il est possible de présenter les logiciels EDIFACT comme de niveau technologique relativement faible (cf. II EDI) mais très solides et stabilisés, face à des logiciels XML en rapide développement – et extrêmement nombreux.



Cependant, dès maintenant, les logiciels XML sont beaucoup plus ambitieux. Par exemple, ils visent l'échange inter-applicatif appuyé sur une gestion de base de données, alors que les logiciels EDI travaillent souvent avec des interfaces rigides, message par message. Or, cette différence, une fois encore, ne tient pas aux syntaxes mais aux moyens et aux perspectives des développeurs et des sociétés offreuses de l'EDIFACT.

L'offre de logiciels EDI, en effet, principalement les traducteurs, émane le plus souvent de petites sociétés, aux budgets d'investissement limités, ce qui peut expliquer leur niveau technologique. Ces logiciels ont très souvent constitué l'offre produits des grands du logiciel et du service.

A l'opposé, les produits logiciels proposés autour de XML sont développés par les grands donneurs d'ordre de l'informatique - Microsoft, Sun, IBM, SAP, …En outre, ils s'appuient sur un terreau extrêmement riche, parce que les développements XML se produisent dans toutes les grandes universités et centres de recherche de la planète, ce qui n'a jamais été le cas avec EDIFACT. C'est ce qui explique la très grande richesse du catalogue de fonctions à la disposition des développeurs dans les entreprises.

Cependant, toute cette floraison d'outils et de fonctions ne s'accompagne pas encore d'une offre suffisante de progiciels industriels, seule à même de permettre l'utilisation courante d'XML dans l'inter-entreprises et surtout pour les PME. C'est la raison pour laquelle EDIFACT est aujourd'hui encore retenu pour des développements nouveaux, par exemple pour l'automobile ou, en France, par les experts comptables. Ces derniers souhaitent en effet une sécurité garantie par une norme. Or, si les développements sont en cours pour XML au W3C (cf. infra), le transport des certificats X509 n'est pas standardisé, alors qu'il l'est dans la V4 d'EDIFACT (que l'Ordre va donc sans doute recommander à ce stade).

Inversement, il convient de ne pas surestimer l'homogénéité et la normalisation du monde EDIFACT. En fait, comme cela a été rappelé, l'absence de modèle et la nécessité de définir des subsets de messages pour les implémentations concrètes peuvent conduire à de fortes divergences.

3.2. XML et le commerce électroniqueCe sont les besoins du commerce électronique qui sont le moteur du développement d'XML.

Cependant, il faut distinguer les besoins.



XML peut être utilisé pour transporter les messages du commerce. Il peut aussi être utilisé pour définir les conditions de la relation commerciale, c'est-à-dire pour savoir quelles sont les conditions de livraison ou de paiement, les règles de l'échange avec un partenaire. Il peut fournir des informations techniques sur les produits et créer des catalogues. Il peut transporter la signature ou les informations de paiement etc.

L'EDI est l'une des principales applications concernées.

De très nombreux groupes ont entrepris de proposer des standards en matière de commerce électronique. Leur diversité exprime à la fois les différences entre les problèmes ou entre les secteurs et les oppositions d'acteurs concurrents.

Certains groupes ont été évoqués dans la première partie (dans les structures de normalisation), notamment OASIS et ebXML.

3.2.1. Des applications verticales

De nombreux domaines sont concernés, avec une avance particulière pour les secteurs des technologies de l'information.

RosettaNet : PIPs (Partner Interface Processes)

www.rosettanet.org

Ce groupement des acteurs de l'informatique vise au départ la standardisation de la chaîne des approvisionnements dans le secteur. Ses avancées pratiques sont jugées importantes.

Cependant, l'origine et les ambitions des promoteurs les ont amené à concevoir des mécanismes qui peuvent largement être repris pour d'autres secteurs.

L'apport le plus intéressant est le Partner Interface Process. Un PIP est une spécification XML qui permet d'harmoniser et intégrer les systèmes des partenaires de commerce. Il ne s'agit donc pas des messages de commerce eux-mêmes mais de modèles de données et de process et de documents qui vont permettre aux développeurs d'implémenter des interfaces elles-mêmes définies par RosettaNet.

ECIX (Electronic Component Information Exchange)

www.si2.org/ecix

Ce groupement de l'électronique regroupe tous les grands (Intel, IBM, Motorola, Lucent, Philips, Texas, HP, Hitachi). Le projet traite de la création, de l'échange et de


http://www.si2.org/ecix

http://www.rosettanet.org/


l'utilisation de l'information sur les composants électroniques. Les spécifications concernent notamment un dictionnaire pour l'information sur les composants.

3.2.2. Des applications spécialisées

Basda

http://www.basda.org

BASDA, Business and Accounting Software Developers Association, a été créé en 1993 à Londres et regroupe environ 200 membres représentant l'industrie du logiciel. Son initiative eBIS-XML se compose actuellement de deux messages XML pour la commande et la facture. L'ambition est de permettre l'échange de ces messages entre différents progiciels par Email ou Internet sans recourir à l'EDI "classique" ni réseau à valeur ajoutée. Cette initiative est reconnue par l'UN/CEFACT, OASIS et ebXML et est soutenue par Microsoft dans le cadre de son offre Biztalk.

Les schémas des deux messages sont téléchargeables à partir du site de Microsoft www.biztalk.org.. Sans préjuger de la qualité du travail réalisé, il semble que ces schémas soient issus d'une démarche purement empirique et réalisés à l'aide d'un logiciel X-Tract XML Script d'une société anglaise. Ce travail s'inscrit dans la tendance actuelle des vendeurs de logiciels qui cherchent à imposer des formats d'échange plutôt qu'à proposer, conformément aux recommandations du TMWG (instance technique du monde EDIFACT), une approche méthodologique de la conception de DTD ou de Schemas répondant aux attentes des futurs utilisateurs.

Il serait souhaitable que toute publication de DTD ou de Schema soit faite avec le modèle UML dont ils sont issus. Produire des DTD ou des Schemas hors d'un contexte méthodologique ramène au problème de la cohérence et de l'interopérabilité des solutions.

Open Buying on the Internet

OBI est un vaste consortium, dont un acteur central est American Express.

Le but est l'établissement de standards pour les achats des entreprises hors de leur activité principale (par exemple fournitures de bureau). Il s'agit d'un ensemble de fonctions et de messages permettant d'identifier un acheteur dans une entreprise, un fournisseur, de proposer des choix, de permettre le paiement par un employé pour de petits montants.

OBI est maintenant réécrit en XML.


http://www.biztalk.org./


Open Trading Protocol

Ce protocole traite du paiement électronique et s'appliquera aussi au commerce B2C.

3.2.3. Projets généraux

Commerce XML (cXML)

www.cxml.org

cXML est un ensemble de propositions de messages pour les relations acheteurs fournisseurs, et protocoles associés permettant l'interrogation de sites Web des fournisseurs depuis les logiciels de gestion des achats des entreprises. Un protocole de demandes – réponses peut alors se dérouler. Le process visé est celui des achats, jusqu'au paiement. L'acheteur reçoit des paramètres, pour les produits et les prix, correspondant à son profil.

Commerce XML est un regroupement d'acteurs du commerce électronique autour d'Ariba et Sterling Commerce, le premier étant une société jeune et très en pointe du monde du commerce électronique , proposant un portail et des outils (cf. infra), l'autre un acteur ancien de l'EDI aux Etats Unis (maintenant dans Computer Associates).

Microsoft a signé un accord avec cXML, qui sera supporté par le langage Biztalk.

CBL (CommerceOne)

Ensemble concurrent autour d'une société qui est un leader, avec Ariba, des outils et portails de commerce. Microsoft a signé des accords avec CommerceOne et Biztalk supportera CBL.

CBL est une collection de schémas XML qui définissent des process courants comme la commande, la facture etc. Pour faire face à la diversité des langages de schémas, CBL est écrit selon trois langages, celui du W3C (pas encore un standard), celui de Biztalk (qui devrait finalement se conformer au précédent, selon Miicrosoft) et le langage développé par Commerce One, SOX (une des premières propositions, Schema for Object Oriented XML).

CommerceNet

www.commercenet.com

Créé en avril 1994 aux Etats Unis, CommerceNet regroupe plus de 500 sociétés et organisations dans le monde avec peu ou pas de représentant français en dehors de


http://www.oasis-open.org/

http://www.cxml.org/


France Télécom. L'objet de CommerceNet est de "transformer Internet en une vaste place de marché électronique.

CommerceNet va donc développer des propositions de normes pour l'interopérabilité.

L'ambition est de développer un cadre général et générique pour le commerce, qui pourrait englober les diverses propositions de protocoles, langages, messages.

Ce cadre, eCo Framework, cherche à permettre l'interopérabilité des différents systèmes en proposant des définitions génériques des éléments et des documents du commerce électronique, donc en se plaçant à un niveau de définitions sémantiques, et en complétant par la définition des transactions.

Le principe est donc, devant l'existence de plusieurs langages et procédures pour un même objet , de remonter au niveau des modèles et des dictionnaires, ce qui est un principe général pour rétablir l'interopérabilité. Des outils peuvent alors être construits pour passer d'une forme à une autre de messages particuliers.

L'enjeu est important mais l'objectif est difficile à atteindre. Cependant, à terme, ce type de proposition est envisageable parce que tous ces échanges concurrents sont écrits dans des langages XML, donc dans une grammaire commune.

CommerceNet est une association déjà ancienne, qui a travaillé sur l'interprétation des paramètres des différents types de commerce et de produits dès le début du développement du Web, et avant qu'XML ne soit envisagé. Une partie des membres s'est organisée pour définir eCo Framework, dont les ambitions sont presque aussi larges que celles d'ebXML. La principale différence est que CommerceNet comprend essentiellement des acteurs de l'informatique nouvelle avec de grands utilisateurs, et non les communautés EDI américaine ou européenne, entre autres, ni les anciens réseaux. Par ailleurs, ebXML va plus loin dans le projet de définir une architecture.

A terme, et comme pour Biztalk, soit un ensemble de concepts et de schémas s'imposera, soit des sous ensembles se constitueront, pour des fonctions et secteurs différents, et des passerelles seront établies – qui ne posent pas de problèmes difficiles si les modèles sous-jacents de l'échange sont les mêmes, ce qui est par définition indispensable pour échanger.



BIZTALK

www.biztalk.org

p.m. L'organisation créée par Microsoft vise un spectre large puisqu'il s'agit de définir un langage de schéma, d'enregistrer ensuite des schémas pour les différents éléments et messages du commerce électronique et de proposer un répertoire.

Biztalk peut-être présenté comme une initiative de Microsoft même si l'organisation Biztalk regroupe un ensemble d'industriels tels que SAP, CommerceOne, Boeing. L'objectif est de proposer un cadre (framework) permettant de développer, fédérer, proposer des formats de référence ou Schemas XML pour faciliter les échanges commerciaux.

La stratégie de Microsoft est de développer une plate-forme universelle EDI appelée "Biztalk Server". Cette plate-forme gère les échanges EDI de toute nature grâce à une architecture de traduction qui permet de passer de n'importe quelle structure de format de fichiers, notamment EDIFACT, à n'importe quelle autre structure en transitant par une structure pivot XML respectant un Schema.

Microsoft essaie dans une certaine mesure de faire de l'association autour de Biztalk un équivalent d'OASIS, en tout cas un acteur capable de peser lourd dans le développement des futurs répertoires.

OASIS - ebXML

p.m (cf. I et voir les développements sur ebXML ci-dessous). L'association leader du développement de XML pour le commerce électronique et l'EDI est en fait en concurrence avec le groupe Biztalk, pour ce qui concerne la définition d'un ensemble de répertoires – même si Microsoft est un membre d'OASIS. Il s'agit plutôt d'une course pour établir plus rapidement des ensembles et des définitions de schémas, qui devront converger à terme.

3.3. La normalisation EDI, ebXML

3.3.1. Impact d'XML sur les travaux de normalisation EDI

La normalisation EDI est un mécanisme riche et plutôt efficace. Elle a permis le regroupement de communautés d'utilisateurs importantes par domaines au niveau des pays, des zones du monde et au niveau international. La première réaction de ces


http://www.oasis-open.org/


communautés à l'émergence d'XML a parfois été la méfiance. Cependant, le CEFACT a vite adopté des positions très constructives, et il reste maintenant à intégrer, et très certainement unifier les process. Le problème est en fait de repositionner la normalisation des EDI dans une normalisation informatique en pleine évolution sous l'effet de la détermination de nouveaux découpages et de nouvelles frontières.

Le patrimoine UN / EDIFACT est-il en danger ?

Le patrimoine ne sera menacé que si des groupes adoptent une position frileuse, se contentant de maintenir les applications existantes et refusant de travailler avec les nouveaux outils et avec XML.

Le patrimoine est d'abord constitué par les groupes d'utilisateurs eux-mêmes et les pratiques de travail en commun et de concertation.

Il peut éventuellement être constitué par les modèles, mais il faut rappeler que beaucoup de messages EDI ont été constitués sans référence à une modélisation, dans une démarche message par message en fonction des besoins.

Les dictionnaires de données et d'éléments constituent un capital important – le seul ensemble de données largement coordonné à un niveau trans-sectoriel et international – aux réserves près qui ont été faites ci-dessus sur la réelle universalité des données et leur interprétation unique. Un autre atout très fort est constitué par le dictionnaire des listes de codes approuvées dans la norme.

Les recommandations du CEN ISSS au groupement ebXML en ce qui concerne les répertoires et référentiels

Le CEN a pris position sur le problème des répertoires pour la gestion des référentiels sémantiques pour les EDI business à business et formulé des recommandations ayant trait à l'utilisation du Basic Semantic Register ISO et à son utilisation dans un environnement ebXML.

Des extraits résumés en sont présentés ici.

• La gestion du répertoire doit être confiée aux représentants des différents secteurs concernés. Il faut une Autorité d'enregistrement distribuée. Les différents groupes de normalisation, techniques (EDIFACT, XML/EDI..) et sectoriels doivent se coordonner autour du BSR.

• Il doit être possible de faire correspondre tout élément utilisé dans les messages ebXML avec une structure du BSR, en utilisant des éléments correspondants aux composants du BSR.



• L'autorité responsable du répertoire central – dont l'unicité est l'objectif final – prendra en compte les besoins de répertoires particuliers locaux et sectoriels. Elle développera des règles pour identifier les "propriétaires" d'un ensemble de données (la communauté qui les développe), les données multi-sectorielles devenant communes.

• Les définitions seront établies en conformité avec la norme ISO 11179 – Spécification et normalisation d'éléments de données. Les paires Nom/Contexte seront utilisées pour résoudre les ambiguïtés.

• Les utilisateurs doivent pouvoir interroger le répertoire à tout niveau. Il faut pouvoir identifier les DTD ou Schémas enregistrés et utilisant un élément donné.

• Toute proposition d'extension du répertoire doit être validée dans un délai de 30 jours. Le processus doit être non bureaucratique….

• (d'autres recommandations sur un organisme gestionnaire et le besoin de règles)

• Le répertoire de guides d'implémentation de messages EDIFACT maintenu par le CEN / ISSS devrait, chaque fois que c'est approprié, former la base des DTDs XML/EDI et les DTDs correspondantes devraient être enregistrées comme faisant partie du répertoire des guides d'implémentation. "Cela permettra aux personnes cherchant des types de message existants de choisir d'utiliser soit le guide d'implémentation UN/EDIFACT soit la DTD XML/EDI."

• Les DTDs devraient être dérivées de messages EDIFACT existants à partir de la sémantique incluse dans le répertoire plutôt qu'en reproduisant le message EDIFACT avec une syntaxe XML. Il faut une correspondance entre les données EDIFACT, les objets du répertoire et les éléments XML/EDI. S'il n'est pas possible de trouver une structure adéquate, il faut en définir une en utilisant autant que possible les composants sémantiques déjà enregistrés. Ceci ne signifie pas une correspondance bi-univoque entre les éléments XML/EDI et les composants du BSR. Un élément XML peut être plus ou moins complexe. En outre, les messages XML comme EDIFACT contiennent des éléments uniquement destinés au contrôle – de tels éléments EDIFACT deviennent en XML des attributs de l'élément signifiant.

L'atelier XML EDI du CEN

Les objectifs ont été rappelés ci-dessus (I). Le business plan indique précisément les orientations du groupe. Il combine en fait les différentes approches, de court et long terme.



Des aspects du business plan

- Identifier les meilleures méthodes pour développer un EDI interactif sur Internet

- Développer des guides pour le développement de messages XML correspondant aux messages EDIFACT ; cf. à ce sujet le débat sur le mapping exact des messages ou la refonte à partir du modèle – mais le groupe distingue bien les deux démarches puisque…

- Démontrer des méthodes pour développer des messages XML à partir de modèles d'information

- Définir un mécanisme pour valider les messages XML EDI et créer un répertoire de DTDs validées.

Le groupe de travail souhaite diffuser des recommandations et produire un système démonstrateur qui permettrait aux utilisateurs de :

- Créer des messages XML conformes à des DTD ou à d'autres technologies (schémas, dictionnaires) (en mettant à leur disposition une base de données)

-Recevoir et interpréter des messages en tenant compte des difficultés propres aux PME, par exemple en gérant les problèmes de langue

- Gérer des processus composés d'ensembles de messages (scénarios) et les contraintes correspondantes de traçabilité et conformité au scénario

3.3.2. Les principaux problèmes pour faire de l'EDI en XML

Ce sont d'abord les problèmes de définition de tous les éléments de l'EDI en général :

- Définition des aspects techniques des accords d'interchange en tenant compte des contraintes informatiques, et moyen de les automatiser- Protocoles de l'échange, scénarios- Structure des enveloppes de routage : structure de l'enveloppe qui indique les caractéristiques émetteur, destinataire etc.- Contenu des enveloppes de routage : adresses, sécurité etc.- Structures de messages- Sémantique- Codes- Gestion de la relation entre les couches transport, les enveloppes et les contenus- Méthode pour transporter le éléments non textuels dans ou par les messages- Traçabilité, notarisation



Les nouveaux problèmes concernent les moyens d'utiliser la flexibilité d'XML et des nouvelles techniques – ou pour en parer les effets.- Accord sur les langages et messages par groupes suffisamment importants- Négociation automatique des processus d'échange- Personnalisation, ciblage dynamique des messages- Normes d'accès aux répertoires- Implémentation de scénarios et messages dynamiques- Choix du niveau d'intégration avec le partenaire

C'est tout cet ensemble d'éléments qui constitue l'objet de travail des groupes qui veulent établir des normes pour les EDI, en particulier ebXML.

3.3.3. ebXML : les fondements

L'objectif d'ebXML est d'établir une infrastructure mondiale pour le commerce électronique. Il n'est pas de définir des schémas ou des DTD, ni des sémantiques pour tel ou tel domaine. EbXML travaille à un niveau plus élevé et définit une architecture.

L'intensité et la rapidité du travail d'ebXML en 2 000 sont véritablement impressionnants. Le groupement veut une norme pour juin 2 001.

Objectifs et principes

Les objectifs d'ebXML reflètent bien ce que sont les contraintes à prendre en compte pour le développement d'un véritable système de commerce électronique.

Le but est de développer un ensemble unique de spécifications techniques acceptées internationalement. Les applications qui satisferont à ces spécifications pourront interopérer, et le groupement devra simultanément assurer une voie de transition à partir des standards actuels de l'EDI.

Au cœur des travaux apparaît le souci constant de s'appuyer sur des modèles indépendants des syntaxes, puis de passer systématiquement des modèles aux schémas (échange de modèles, passage entre UML et XML de façon biunivoque) ainsi que la volonté, à tous les niveaux, de rester fonctionnellement et sémantiquement compatible avec l'EDI existant (X12, EDIFACT, HL7 en particulier).



Les exigences de base, publiées par ebXML, comprenaient entre autres :

- le support des modèles existants- le développement d'un méta-modèle qui permettrait de renvoyer aux différents modèles spécifiques, utilisable notamment par les opérateurs intermédiaires- une spécification générale pour le développement des schémas- des composants objets principaux indépendants des syntaxes, utilisables par les intermédiaires (portails)- le support de métadonnées correspondant aux en-têtes des messages EDI- un mécanisme pour spécifier les sémantiques

Les exigences d'architecture comprennent le support de règles communes pour la sécurité et pour les protocoles de transport des données. Le groupe Transport d'ebXML travaille sur les en-têtes de messages et la description du contenu, qui doit être indépendante des contenus et même des syntaxes (cf. problème du multimédia et des documents binaires) ; il travaille également sur le transport des signatures et le cryptage.

L'une des préoccupations importantes est la gestion des répertoires.

Une démarche pragmatique

Une préoccupation importante est le pragmatisme. Il ne s'agit pas de réinventer tout le fonctionnement des échanges ou d'Internet. C'est ce qui a conduit par exemple à décider de conserver MIME pour l'enveloppe de transport de messagerie (cf. infra).

En fait, ebXML vise à permettre le transport de formats divers, et non seulement de ceux qui vont être développés en XML. Dès lors, XML n'est obligatoire que pour l'en-tête des messages, qui est l'élément clé permettant aux systèmes de reconnaître et traiter l'information.

Organisation et axes de travail

EbXML est organisé en groupes de travail :

- Technical Architecture Specification (définition d'ensemble, dictionnaires des agents, objets, entités ebXML)(définition d'ensemble, dictionnaires des agents, objets, entités ebXML)- Repository and Registry Specification- Transport, Routing and Packaging Specification- Business Process Modelling Specification- Core Components Specification



ebXML en dehors du commerce ?

Dans les systèmes EDI, c'est pratiquement toujours le commerce – au sens restreint du mot – qui a orienté les développements initiaux. EDIFACT est né de la volonté de simplifier les procédures du commerce international, et d'abord du commerce de marchandises. Ensuite seulement, et avec difficultés, il s'est étendu à des échanges de données non commerciales, dans le secteur social ou sanitaire en particulier.

De même, le développement d'XML pour l'EDI connaît une accélération impressionnante en raison de l'engouement pour le commerce électronique. Cependant, dans le cas d'XML, il faut toujours noter que de toutes autres applications exploitent la même technique.

Quoi qu'il en soit, la question se pose donc de l'opportunité non d'utiliser XML mais de se référer aux groupements qui, comme ebXML ou Biztalk, semblent d'abord partir de préoccupations de commerce.

Toutes les observations indiquent bien que non seulement XML est adapté à de tous autres échanges mais que, dans beaucoup de cas, il peut répondre à des besoins vraiment très difficiles à satisfaire avec les syntaxes précédentes. C'est le cas en santé, où les informations médicales répondent à une logique de structure forte mais avec une organisation et des formats très variables. Les expériences puis les développements dans

3.3.4. Le transport des messages XML via Internet

Il ne s'agit pas ici seulement de définir un moyen de transport, lequel pourrait être défini immédiatement avec la même méthode que celle suivie pour EDIINT (EDIFACT ou X12 sur Internet) : un en-tête supplémentaire MIME, un cryptage de l'ensemble du message et son transport en pièce jointe.

Il s'agit de repréciser les règles d'un échange professionnel (sécurité, traçabilité etc.), les protocoles, les scénarios et types de messages (message normal, AR, erreurs etc.). Le transport et les outils pour exprimer les règles doivent être interopérables et indépendants par rapport à tout système et langage.

La reprise des règles du monde EDI est ici essentielle, mais à un niveau d'abstraction permettant des implémentations diverses.

Le système prévoit la prise en compte des modèles et des scénarios. Il définit une "choreographie" des services et sub-services, qui indique les séquences d'exécution des services et permet l'intégration des messages dans les scénarios.



Pour ce qui concerne la couche "d'enveloppe" au cours du transport sur Internet, le débat a fait rage au début de 2000, au sein d'ebXML : une couche d'enveloppe pur XML ou l'utilisation du système qui permet à la messagerie Internet de reconnaître la nature des pièces jointes, MIME (Multimedia Internet Mail Extension). La réponse a été MIME parce que c'est ce qui est prêt et qui marche. Si XML permet de réaliser l'enveloppe ultérieurement, l'option sera offerte. MIME permet sans action spéciale de transporter tout type de fichier, notamment sans encodage spécial – problème des caractères réservés XML). Il faut noter que le choix d'autres groupes a été différent : des en-tête XML spéciaux sont utilisés par Biztalk, RosettaNet, SOAP. Le propos d'ebXML est de permettre la généralité la plus grande.

Le problème s'était posé de façon similaire pour la relation X400 - EDIFACT (cf. II EDI).

Le groupe transport d'ebXML a précisé en mars 2000 la composition d'un message et sa relation avec la couche transport (ce document détaille les contenus des différents éléments présentés ici).

Transport Envelope

Message EnvelopeHeader

Envelope

Message Body

MessageBody Part

MessageBody Part

MessageBody Part

...

MessageHeader

MessageRouting Info

MessageSignatures

Other Mess-age Headers



Un message consiste en :

- une enveloppe de transport externe, comme HTTP et SMTP (donc l'enveloppe des protocoles de base),- une enveloppe de message MIME qui va annoncer le message conforme ebXML- le "header" ebXML- le corps du message.

Le header, indépendant du transport, doit permettre le traitement du document / message par les logiciels qui vont le router vers les destinataires. Il permet d'identifier le contenu, de gérer un premier niveau d'erreurs, d'assurer les accusés de réception et de livrer le message. Il comprend lui-même plusieurs éléments :

- un en-tête comprenant les données d'identification qui vont permettre l'adressage et le traitement dans un système donné, par un destinataire donné,- un ensemble optionnel d'informations de routage qui indique le chemin que devrait prendre le message ou qu'il a pris (optionnel parce que ces éléments sont déjà pris en compte aux niveaux inférieurs des protocoles),- une signature, optionnelle (ce qui ne s'oppose pas à ce que le message lui-même supporte une signature),- d'autres en-têtes spécifiques.

Le groupe transport étudie donc aussi le transport des signatures et la manière d'utiliser S/MIME, PGP et les signatures électroniques définies par l'IETF et le W3C, entre autres.

Il considère aussi les services entourant le transport et les messages correspondants, comme la demande de statut d'un message, la demande de l'état de disponibilité d'un service, la demande d'information sur les paramètres d'un service, l'établissement de processus de type Publication – Abonnement, la trace (audit trail), l'utilisation de XML pour créer des documents retraçant les échanges.

Le schéma montre la réception d'un message par un outil conforme à ebXML. Le logiciel EDI retourne les messages de service. Seul le header est obligatoirement en XML et il est analysé par confrontation à une DTD ou un schéma pour un transfert correct aux applications. Comme les autres éléments du logiciel EDI, le parseur peut retourner des informations de service (erreurs, acquittements). Le schéma rappelle que les applications peuvent elles-mêmes retourner des réponses applicatives de service (erreurs etc.) et générer un message retour.



autre message(scénario applicatif)

erreur

OK

erreurs

AR

Sauve Contrôlestructure

AnalyseHeader

Analysecontenu Traite

Logiciel EDI conforme ebXML Application

Référence : Schéma ou DTD XML

La réception d’un message ebXML

3.3.5. Registres et répertoires

C'est un élément clé. Le projet d'ebXML, et ce qui le différencie de tous les autres groupes, est d'aller jusqu'à une architecture complète, qui comprend concrètement l'établissement d'un réseau de répertoires capables de renseigner le développeur ou l'entreprise sur les conditions d'échange avec un partenaire. Ce système, à la différence par exemple de celui d'EDIFACT, ne sera pas centralisé mais réparti en toile (cf. ci-dessus "Enjeux"). Par ailleurs, il sera accessible par des automates et non seulement par des opérateurs humains, au travers de la normalisation des URI et des Namespaces.

Aussi, le groupe travaille à exprimer les règles de constitution et de gestion des répertoires XML qui supporteront les règles des business, les sémantiques etc.

L'ensemble du système d'interactions entre les répertoires est représenté dans un modèle exprimé en UML Le passage à XML se fait par une expression XMI du modèle.

L'objectif est la production automatique d'interfaces XML pour échanges entre répertoires et entre répertoires et documents. Le groupe travaille à la définition de rôles, d'acteurs, autorités d'enregistrement, services, applications etc. Le modèle exprime les interactions entre humains, humains et répertoires ainsi que, automatiques, entre



applications et répertoires. Le système devrait permettre à terme l'adaptation automatique de messages.Un meta système met à jour les répertoires qui définissent les règles de l'échange. Il définit des règles de messagerie, des règles pour les systèmes d'intégration avec les systèmes d'information des entreprises.Le schéma indique la relation entre le système de gestion des répertoires, le système de messagerie ebXML, le système qui intègre l'ensemble EDI aux applications de l'entreprise. Deux parties (partie 1 et 2) se réfèrent à leurs répertoires internes, eux-mêmes capables d'interroger un répertoire externe (ou en fait l'univers des répertoires, éventuellement).

Composants

Règles de business

Types de documents

Règles demessagerie

RépertoireRègles d’intégration

Partie 1

Partie 2

Système demessagerie

Systèmed’intégration

Applications

message

Systèmes de gestiondes répertoireset messages associés

Répertoire maître(secteur, parties)

Le jeu entre les répertoires (internes, publics)et le système d’intégration des échanges

avec les applications de l’entreprise



3.3.6. Modèle et sémantique

ebXML doit permettre la mise en relation de modèles et sémantiques divers. Pour cela, il faut définir un meta-modèle général, ainsi que des composants fondamentaux communs.

Le méta modèle décrit les rôles des différentes parties dans la définition d'un échange. Il permet d'exprimer et définir pour un secteur, un groupe etc. les classes, les scénarios, les messages. Il permet de construire le système d'organisation des répertoires et de mise en œuvre de l'architecture de messages. Il comprend

- Resources and Contracts - Markets and Communities- Business Processes and Rules- Business Information Flow and Communication

Le mapping d'un modèle et des objets dans le méta-modèle va permettre d'exprimer et assurer la conformité à ebXML et de garantir l'interopérabilité

Pour les composants communs, ebXML ne veut définir qu'un ensemble minimal permettant l'interopérabilité. Se retrouvent les problèmes des éléments de données (TDED), des codes et références d'organismes, des identifiants d'acteurs, des langues.

3.3.7. La vision du commerce électronique de ebXML

Le principe est d'aller vers un EDI ouvert, ou tout au moins vers un EDI qui pourra être mis en œuvre très aisément une fois la décision prise d'engager des relations. L'essentiel n'est donc pas de figer tel ou tel message dans un certain espace, mais de définir les règles, de connaître les procédures, les langages, les sémantiques du partenaire concerné.

Avant une série d'échanges, le dialogue largement automatique entre les systèmes devra permettre la définition d'un processus précis d'échange, qui pourra être reproduit tant que les conditions ne varieront pas.



Le schéma ci-dessous est largement emprunté aux travaux du TMWG (CEFACT) et d'ebXML. Il illustre la vision nouvelle de mise en place de messages EDI.

Référentiel interne

Bibliothèque d’objets en ebXML

Bibliothèque de process exprimés en ebXML

1

2

3

“Repository ebXML”en fait : un répertoire particulier ou l’ensemble desrépertoires liés

La société X et la société Y vont faire de l’EDI...Y travaille déjà en ebXML,X a des interfaces XML mais n’a pas encore échangé

demande les spécifications ebXML

profils et scénarios bien reçusdemande à charger ses caractéristiques

profils

scénarios

En avant !

envoi

3.3.8. Un exemple de scénario

(présenté par ebXML)

- Echange entre des sociétés qui n'ont jamais travaillé ensemble : un agent de voyages met à jour un fichier client sur les sites d'une compagnie aérienne et d'un loueur de voitures.- Déchargement d'un modèle UML d'un répertoire.



- Production d'une DTD définissant les messages nécessaires.- Entrée des informations par l'utilisateur- Lancement du scénario d'échange

Ce scénario ressemble à la mise à jour de références d'un administré / personne couverte par un système social etc. dans les services non commerciaux…

agent

LoueurCieaérienne

Références

nav.agent

mod.UML

mess.XML

agent

demande

échanges :mise à jour

1

2

3

3.3.9. Des développements

L'emploi des balises ebXML pour lier des EDI automatiques et des communications humaines

La démarche ebXML se situe dans la perspective d'intégration qui est celle d'Internet et des EDI aujourd'hui (cf. évolution de l'EDI) : les process supposent souvent une partie humaine et une partie automatique – qu'il s'agisse de la recherche d'un produit dans un catalogue pour lancer ensuite une commande ou qu'il s'agisse d'une procédure administrative.

Dès lors, la normalisation ebXML va aussi chercher à permettre l'établissement de la chaîne de relations dès le stade de la recherche d'un produit ou d'un service sur le Web. La normalisation ebXML esquisse alors une démarche qui n'existait en EDIFACT que pour les listes de codes : plusieurs codifications possibles, avec donc une information en cascade (segments 3031 – 1155) indiquant la nature du code et l'autorité responsable de



la liste de code employée. En outre, évidemment, avec ebXML, les informations seront réparties sur Internet ou les réseaux IP en général. Surtout, la démarche s'applique désormais à la sémantique, avec l'utilisation systématique des Namespaces.

En résumé, il est proposé que, par exemple, un catalogue de produits, ou des informations commerciales, portent quelques balises du namespace ebXML permettant d'identifier le secteur et la nature du produit. Ces informations permettraient à des moteurs de recherche spécialisés d'identifier l'information commerciale recherchée et de la caractériser. Ensuite, le système pourrait afficher le reste du document commercial. Ainsi se retrouve toujours le principe de la cascade de répertoires : le répertoire central renvoie sur un répertoire sectoriel, par exemple, qui indiquera les noms de balises pour l'espace considéré (par exemple la santé en France) et l'outil pourra alors affiner son indexation ou sa recherche.

tpaML : la voie vers l'accord d'interchange automatisé

Trading Partner Agreement - tpaML (proposition d'IBM à OASIS et donc ebXML, qui rencontre un fort intérêt) est l'expression en XML d'un contrat d'interchange. Il permet de définir :

- les rôles, - les conditions, - les protocoles et règles de communication et de sécurité, les services à utiliser- les règles de business (scénarios de l'échange, actions requises)- le langage employé (OBI, Biztalk, tel langage sectoriel etc.)- les messages

Le TPA définit donc des conditions de mise en œuvre des différents niveaux de l'échange - du transport à la couche des scénarios. Les administrateurs du système vont pouvoir créer le contrat électronique en utilisant ce langage.

Le contrat pourra alors être intégré dans les logiciels qui dirigeront les échanges.

Le schéma suivant illustre la nouvelle vue de l'EDI. Il ne s'agit plus de systèmes surajoutés à ceux des entreprises mais intégrés au workflow, c'est-à-dire aux flux informationnels internes des différents intervenants – qu'il s'agisse du flux d'activité de production, d'activité commerciale, d'activité sociale. Les échanges sont déterminés par ce workflow et par les règles et procédures que l'entreprise ou l'organisme concernés fixent pour les échanges externes. Dans le schéma, les partenaires de la relation envisagée s'informent mutuellement grâce aux échanges tpaML. C'est ce qui permet la



création des messages et des scénarios. Le déclenchement des messages est quant à lui dépendant des workflows (et en même temps les modifie).

Un EDI de nouvelle génération est un couplage entre des process indépendants.

EDI

RèglesProcédures

Appl.

workflow

EDI

RèglesProcédures

workflow

Appl.

tpaML

messages

Quelle que soit la forme finalement retenue pour le standard, un système de ce type paraît indispensable.

Ainsi, un donneur d'ordre de l'automobile pourra transmettre un TPA à un sous-traitant. Celui-ci le complètera et le retournera. Des outils génèreront les logiciels d'intégration appliquant les caractéristiques particulières de ce contrat.

Dans le domaine administratif social, ce type de fonctionnement pourrait être mis en œuvre entre des organismes qui se transmettent des informations à fin de règlement, ou entre une grande entreprise et des organismes sociaux, ou entre des concentrateurs qui veilleraient au suivi des process et les organismes. Net-Entreprises pourrait être le dépositaire des TPA.

La capacité à produire des accords électroniques implique des intermédiaires de notarisation de ces accords. Elle suppose aussi sans doute, dans le cas le plus général, des serveurs middleware qui vont assister les partenaires dans la réalisation des accords, résoudront les inévitables difficultés de mise en œuvre (l'informatique n'apporte jamais qu'une automatisation presque totale), proposeront des formules types etc. Ici encore, le rôle des intermédiaires assurant le middleware sortira renforcé de la diffusion des nouveaux outils.



3.3.10.Une avance rapide

ebXML s'est donné un calendrier qui l'oblige à marcher à un train d'enfer. Créé à fin 1999, ebXML a pratiquement tenu son rythme. Au printemps 2 000, les groupes de travail ont publié un ensemble de documents qui marquent une étape importante. Il reste encore des points d'ombre mais le calendrier semble devoir être tenu : avoir des spécifications stables en juin 2 001.

3.4. La sécurité des échangesPour que les échanges professionnels puissent se développer sur Internet de façon aussi explosive et générale que l'accès public au Web, il faut des normes et des accords sur les règles de sécurité et en particulier sur la signature électronique.

Les enjeux sont énormes. Les problèmes sont avant tout politiques et juridiques. Les différents acteurs dans les pays et surtout les différents pays devront s'accorder, d'abord au niveau de l'Europe en ce qui concerne la France, puis au niveau mondial, en particulier pour le commerce.

En France, la Loi permettant la signature électronique a des conséquences importantes sur l'ensemble des droits, et c'est ce qui rend difficile l'élaboration des décrets d'application et leur mise en œuvre pratique. Les textes correspondants sont évidemment fondamentaux, en particulier, pour le secteur social.

En dehors de la reconnaissance nationale et internationale de procédures, il est possible aux parties à l'échange de s'accorder sur un système de signature et de certificats, et c'est ainsi que procèdent, utilisant des systèmes propres ou des systèmes du marché, les entreprises qui dialoguent d'ores et déjà.

3.4.1. Signature XML

En raison de l'importance de la signature et de la compétence nécessaire à la fois en XML et en sécurité et cryptographie sur Internet, l'IETF et le W3C sont associés pour le groupe de travail qui traite de l'expression de la signature en XML.

La syntaxe permettra d'exprimer la relation entre les signatures cryptées et tout objet sur le Web (tout ce qui peut être référencé par une URI). Le standard en discussion fournira aussi les procédures pour traiter et vérifier les signatures XML. La signature pourra être



attachée avec l'objet signé, cryptée ou non avec lui, mais elle pourra aussi référer à tout autre objet, non contenu dans le document / message XML lui-même.

3.4.2. PPP : Platform for Privacy Preferences

Cette spécification du Web Consortium permet aux sites Web d'exprimer leurs pratiques en matière de protection de la vie privée. L'utilisation pour ce faire d'un langage normalisé (écrit en XML) va permettre à tout internaute mais aussi et surtout à tout automate de comprendre quelles règles sont appliquées par le site ou l'application concernés. Il s'agit évidemment de déclaration, non d'un moyen de prouver que le site respecte bien les règles qu'il annonce.

PPP est l'expression XML d'une structure RDF (cf. ci-dessus). C'est (en mai 2 000) une proposition en discussion au W3C (un draft).

3.4.3. La carte : SmartXML de la société GEMPLUS

SmartX est une technologie développée par Gemplus pour permettre à n’importe quelle application d’utiliser une carte à puce sans en connaître au préalable les caractéristiques techniques.

Pour Gemplus, la technologie SmartX doit permettre le schéma suivant :

une personne insère une carte à puce dans un terminal ; le terminal, s’il ne connaît pas cette carte, va se connecter à un serveur qui contient le dictionnaire de description de la carte ; le terminal télécharge le dictionnaire et va ensuite gérer l’ensemble des opérations requises par les applications en fonction du dictionnaire téléchargé.Sur un plan technique, smartX utilise le langage de description SML (SmartX Markup Language), une version de XML adaptée à la carte. Les industriels devront réaliser des dictionnaires en SML pour chacune de leurs cartes (Gemplus a déjà publié sur le site www.smartxml.com, les dictionnaires de certaines de ses cartes). Ces dictionnaires vont décrire la manière dont la carte gère certaines opérations (comme le débit, le transfert d’information depuis la carte…). Les dictionnaires sont ensuite publiés sur des serveurs Web ou téléchargés directement dans les terminaux.

SmartX présente de nombreux avantages :

Pour les développeurs, c’est un pas de plus vers des environnements cartes plus ouverts. Il n’y a plus besoin de connaître les protocoles spécifiques aux différentes cartes (APDU et TPDU) et aux différents industriels. SmartX sépare complètement la logique de l’application des protocoles utilisés. La logique de l’application correspond à



une application Java, une applet, ou, dans le monde Windows, à une application Win32 ou un contrôle ActiveX. En outre, SML s’appuie sur XML, un langage largement maîtrisé. Il est donc facile, pour un développeur, d’utiliser de nouvelles cartes ou de nouveaux terminaux sans avoir à modifier son application. Pour les fabricants de terminaux, smartX fournit une interface unifiée vers les différents types de cartes. En effet, les spécifications actuelles les plus ouvertes pour les terminaux (PC/SC, pour le monde Windows, ou Open Card Framework) obligent à télécharger de multiples API pour assurer la compatibilité des applications avec les différentes cartes. Or chacune de ces API prend entre 10 et 20 Ko de mémoire. L’avantage de smartX est de n’avoir pas besoin de disposer dès le départ des informations relatives à toutes les cartes. Le terminal (compatible smartX) va pouvoir aller chercher les dictionnaires des différentes cartes selon les besoins. En outre, SmartX est totalement compatible avec les lecteurs aux standard OCF et PC/SC. Pour les fabricants de cartes, smartX offre la possibilité d’utiliser des cartes propriétaires dans un environnement ouvert. Alors que JavaCard nécessite de mettre sur le marché de nouvelles cartes (plus puissantes, donc plus chères), SmartX permet d’utiliser les cartes actuelles (il suffit de créer des dictionnaires). En outre, Gemplus a l’intention de rendre libre l’utilisation de smartX, qui sera donc ouvert à ses concurrents.Malgré les atouts techniques de SmartX et le fait qu’il soit libre de droits, il n’est pas évident que les autres industriels de la carte l’acceptent aussi facilement. Deux questions majeures devront en effet être résolues avant que les industriels de la carte n’adoptent la technologie :

Qui va assurer l’évolution technique de smartX ? Il est fort probable que les industriels, comme c’est le cas pour JavaCard, PC/SC ou OCF, poussent à la création d’un organisme indépendant ou préfèrent recourir à un tiers. SmartX utilisant des certificats pour vérifier la validité des dictionnaires, il faudra mettre en place une autorité de certification qui va valider ces certificats. Là aussi, il est peu probable que les industriels acceptent que ce soit Gemplus qui tienne ce rôle. A ce jour, Gemplus est le seul industriel à avoir publié des dictionnaires pour ses cartes. Il est fort probable que les autres fabricants ne publieront des dictionnaires que sous la pression de leurs clients. Le kit de développement smartX (sXdk) fournit des outils pour créer des dictionnaires (définition des protocoles), vérifier la syntaxe des protocoles et convertir ces descriptions SML en Java ou C++.



3.5. XML et l'évolution de l'EdiL'émergence d'XML est inséparable d'un mouvement de transformation de l'EDI qui était en tout état de cause indispensable. Le Web consortium et les groupements spécialisés avancent à un rythme toujours aussi rapide pour répondre aux besoins.

XForms : le formulaire Web

Le W3C a publié au printemps 2 000 cette spécification qui permet la validation locale des contenus postés via un formulaire. Celui-ci en effet, s'il s'affiche en HTML (ou XHTML) est en fait une structure XML (supportée donc par les navigateurs) normée.

L'objectif n'est pas seulement les actuels formulaires de tous types mais aussi ceux qui vont apparaître pour contrôler les nombreux systèmes serveurs HTTP enfouis dans les appareils les plus divers – Webcams, appareils industriels, routeurs, appareils domestiques (voir les systèmes UPnP de Ms) etc. Un standard va éviter de développer des drivers particuliers pour chaque machine.

Actuellement, les formulaires présents sur les pages Web retournent une page HTML, c'est-à-dire des données non balisées et de multiples erreurs possibles lors de la récupération de la page par des applications et des bases de données – non seulement parce que HTML ne place aucune information sur la nature des éléments transmis mais parce que HTML tolère des imprécisions et des différences entre les implémentations. Des formulaires contrôlés peuvent permettre de simplifier la tâche sur les serveurs.

XForms vise à distinguer clairement la présentation, la structure logique du formulaire et un protocole de gestion des dialogues utilisateurs et des dialogues entre la page et le serveur. Il permet d'intégrer la validation locale du formulaire en normalisant les API nécessaires.

XForms peut être utilisé avec tous les langages développés en XML, donc tous les langages techniques ou sectoriels particuliers. En revanche, aucune compatibilité n'est respectée avec les anciens standards de formulaires HTML.

La distinction entre la logique et la présentation va permettre de transmettre le formulaire sur des machines diverses, qu'il s'agisse de Palm, de micro, de simples écrans de contrôle etc. Les informations reçues seront traitables par toutes les applications comprenant le standard. Dans les entreprises, les interfaces XML dont vont être dotées les bases de données s'associeront à XForms pour permettre des prises de commande et la génération, en général, des interfaces de saisie d'information et de transactions. L'ampleur du domaine couvert est donc très grande.



Un EDI beaucoup plus dynamique

En EDIFACT, un travail efficace, mais relativement lourd, conduisait à l'adoption d'un subset d'un message à l'intérieur d'une communauté, pour une application donnée. Le changement impliquait des efforts nombreux, et chacun devait sacrifier des spécificités, éventuellement.

La méthode de construction des messages XML, et surtout avec les schémas, va permettre assez rapidement une autre approche de l'EDI, dans laquelle c'est un modèle et des règles et scénarios d'échange qui sont stockés, ainsi que les sémantiques, localement ou sur des serveurs immédiatement accessibles. Le concept de message type va progressivement s'estomper, ou tout au moins une bien plus grande variabilité des éléments fins du message va être possible, la grammaire garantissant la validité de messages produits à la volée.

EDI et modélisation, dialogue entre process

Comme cela a été indiqué (cf. tpaML ci-dessus), un EDI de nouvelle génération est un couplage entre les process des différents partenaires.

L'EDI progresse vers l'intégration au sein des différentes entreprises, notamment l'intégration avec les systèmes de gestion automatisés, les ERP.

Dans le même temps, les groupes EDI de tous secteurs évoluaient vers une démarche systématique de modélisation. Par définition, ces groupes travaillent avec de multiples entreprises et ont encore plus besoin que d'autres d'une représentation de modèles unique. Le succès d'UML a été immédiat, et l'UN EDIFACT et les autres instances de l'EDI ont officiellement fait de cette notation leur standard.

L'EWG (organe technique de la normalisation EDI), souhaitant faire évoluer ses méthodes de travail et plus particulièrement mettre un peu d'ordre dans la conception des messages EDIFACT, a mis en place un groupe de travail appelé TMWG, Techniques and Methodologies Working Group. Les travaux du TMWG ont débouché sur la recommandation d'utiliser UML dans le cadre de la modélisation lors de la conception de nouveaux messages, et plus largement pour des développements EDI/CE. Cette recommandation devrait être effective pour début 2001 (cf. document essentiel du TMWG, N090 – trouvable à http://www.harbinger.com/resource/klaus/tmwg).

Depuis, le TMWG poursuit ses travaux pour expliciter l'utilisation d'UML dans le cadre d'XML et proposer des règles de conversion pour passer d'une représentation UML à des structures de DTD ou de Schema. Ces règles permettent d'automatiser la production et la gestion de DTDs et de Schemas. De



tels logiciels répondent pleinement à la problématique de préservation de la sémantique et de la définition d'objet métier et de structure XML métier.

Ces travaux vont dans le même sens que ceux de l'OMG relatifs à XMI, XML Metadata Interchange pour proposer un support générique pour l'échange de modèles UML (cf. ci-dessus). Il est essentiel que les travaux autour de l'EDI, d'XML et du commerce électronique passent d'une période de développements empiriques à une phase de développements structurés faisant appel aux méthodologies de l'informatique. Sans sous-estimer les difficultés à faire adopter et utiliser largement ces méthodes de modélisation par de nombreux acteurs des groupes de travail de l'EDI et d'XML peu familier de ces approches conceptuelles, il est impératif d'en faire la promotion et d'en imposer l'usage afin de garantir la cohérence et l'interopérabilité des futurs systèmes à mettre en œuvre.

Vers l'intégration d'objets métier et des niveaux progressifs d'EDI

Le problème, en ce qui concerne le passage vers une nouvelle méthode d'échanges, est de ne pas s'arrêter à mi chemin et de s'engager dans une voie pérenne.

Or, l'évolution en cours n'est en fait qu'amorcée.

De plus en plus, et cela se voit dans les différents secteurs, le simple transfert instantané de données entre applications ne suffit plus. Ce sont des scénarios, des process qui s'intègrent, aussi bien dans l'entreprise ou l'institution qu'entre elle et ses partenaires et clients. Les contraintes de rapidité, d'efficacité et de simplicité y poussent.

Dès lors, il s'agit souvent de mettre en relation des applications de façon beaucoup plus étroite, de permettre des intégrations et donc des appels de procédures, des relations plus directes entre les objets métier.

C'est pourquoi SOAP (ou ses successeurs) est certainement un des éléments de l'EDI de demain – notamment lorsqu'il s'agira de réaliser l'EDI interactif (cf. II EDI).

Il est à supposer que l'entreprise pourra développer des intégrations plus ou moins étroites avec des partenaires – et avec ses filiales, ses distributeurs etc. Dans le cercle privé, comme en interne, elle pourra utiliser des couplages inter-applicatifs par liaisons d'objets métier, et dans ce cas elle utiliser SOAP, sur un Intranet ou un Extranet par exemple. Elle laissera alors l'XML ordinaire à des dialogues plus généraux avec des correspondants moins directement partenaires.



Le schéma évoque une possibilité de transition depuis le couplage interne très évolué par un logiciel spécial d'intermédiation entre objets (Object Request Broker). Les partenaires sur l'Intranet mettent leurs applications en relation par XML-SOAP, tandis que les échanges sur Internet se font par simples échanges de données XML. Il ne s'agit que d'un exemple de scénario (vraisemblable) : SOAP peut parfaitement être utilisé sur Internet, et avec des correspondants moins fréquents.

Internet

Extranet

Intranet

ORB

XML

SOAP

XML

app. A

app B

app CEntreprise

Partenaire

L’EDI par degrés



Un facteur d'organisation !

C'est sans doute un paradoxe, mais c'est aussi une certitude. XML, par sa souplesse, permet de développer toutes sortes de langages spécialisés. Le risque d'une tour de Babel dans les langages du commerce est apparu immédiatement. La liberté de définition des balises allait ajouter aux concurrences sur les syntaxes pour produire une cacophonie redoutable.

C'est précisément ce qui contraint à un impressionnant effort de coordination. La création d'un invraisemblable ensemble de groupes scientifiques, techniques, professionnels, autour de langages et de sémantiques spécialisées, l'apparition rapide de MathML comme de SMIL, de la signature électronique ou de SOAP, les résultats obtenus en peu de temps par ebXML, montrent qu'XML est l'occasion d'un gigantesque effort de développement coordonné des échanges, qui prolonge le développement continu d'Internet et du Web.



4. L'état d'un immense chantier

4.1. Une prolifération de logiciels en développement

4.1.1. Des fonctions

Elles sont rappelées ci-après.

Les fonctions de base sont l'édition XML et le parsing.

L'édition permet de produire des documents XML directement, ou de reprendre des documents produits automatiquement, par exemple par l'extraction d'une base de données ou par la création automatique par un logiciel bureautique.

Le parseur est un logiciel de validation. Il confronte le document XML soit à la grammaire générale, soit à une DTD, soit à des schémas et assure la validité ou retourne des erreurs.

Enfin, les convertisseurs sont importants dans un espace de communication. Ils assurent, grâce notamment à l'emploi de fichiers XSLT, la conversion entre les différents langages XML ou entre XML et d'autres langages et syntaxes.

Les autres outils sont des utilisations de XML qui exploitent des interfaces de production ou de manipulation. C'est ainsi que les outils bureautiques vont produire ou interpréter des documents, les outils de gestion de données, les portails vont s'interfacer à des systèmes d'information, vont rechercher dans les documents, les manipuler etc.

4.1.2. Des catalogues

Le site www.xmlsoftware.com est le site de référence des progiciels xml. Ce site présente, dans un classement fonctionnel, un très grand nombre de logiciels XML, dont certains sont gratuits. Le xmlsoftware.com propose des liens vers les sites des développeurs de ces logiciels.

Le tableau ci-dessous reprend partiellement les informations du site xmlsoftware.com.


http://www.xmlsoftware.com/


Catégories de logicielsApplication à application Logiciels de développement d'applications B to B ou plates-formes

interapplicatives d'échanges d'informations utilisant XML comme format d'échange.Références des produits tels qu'un générateur XML/Cobol ou la plate-forme Biztalk de Microsoft.

Navigateur XML Logiciel de présentation de documents XML. Les navigateurs XML sont généralement couplés à des feuilles de style. Ils sont basés sur des arbres ou des applications spécifiques.Références des produits tels que le navigateur Mozilla de Netscape, IE5 de Microsoft, XML Viewer d'IBM et d'autres utilisables sous Windows, Linux, …

Outil de conversion Outil générique ou spécifique de conversion d'un format depuis et/ou vers XML.Références des produits : De transfert de données entre des documents XML et des

bases de données relationnelles et inversement, De transformation d'un document XML basé sur une DTD en un

document basé sur une autre DTD, De transformation de messages EDI en document XML.

Système de gestion de base de données

Système de gestion de base de données avec un support spécifique d' XML avec utilitaires.Références de produits : eXcelon de Excelon Corporation, Tamino de Software AG,

Oracle XSQL servlet, Système de gestion de documents / Contenu Système de gestion de documents et de contenu basé sur XML.

Editeurs/Logiciels pour DTD Pour la création, l'édition, le traitement et la modification de DTD.Références de produits xmlspy de Icon-Information systems, DtdE, Visual DTD, XML Master, Visual XML Tools

d'Alphaworks, IBM,



Editeurs XML Logiciel de création et d'édition de documents XML. De nombreux éditeurs XML peuvent prendre en compte des DTDs pour aider à la production de documents valides. Références de produits : XMetal de SoftQuad Software Inc, XML Notepad de Microsoft, xmlspy de Icon-Information systems.

Parseur/Processeur XML Un parseur/processeur XMLest un analyseur syntaxique. Il est utilisé pour lire les documents XML et pour accéder à leur contenu et à leur structure. Un processeur XML effectue son travail pour le compte d'un autre module, appelé l'application, souvent à l'aide d'une interface standard telle que SAX (Simple API for XML) ou DOM (Document Object Model). La spécification XML 1.0 du W3C décrit le comportement requis d'un processeur XML, c'est à dire la manière dont il doit lire des données XML et les informations qu'il doit fournir à l'application.Les processeurs validateurs peuvent en outre, au gré de l'utilisateur, signaler les violations de contraintes exprimées par les déclarations de la DTD et les violations des contraintes de validité précisées par ce standard.Références de produits : XML4C d'Alphaworks, IBM, Java Project X de Sun, XML parser for Java, for C, for C++, for PL/SQL d'Oracle, Microsoft XML parser,

Publishing Systems Full-blown systems for web publishing using XMLUtilitaires/Outils/API Utilitaires et outils associés aux parseurs XML (pouvant être inclus)

et proposant des traitement ou des services additionnels. Présentation d'une quarantaine d'utilitaires gratuits !

Outils Xlink/XPointer Outils Xlink/XPointerEditeurs XSLT Logiciel d'édition de feuilles de style XSLT.

Références de produits : Stylus d'eXcelon Corporation Inc. Visual XML Transformation Tool, XSL Editor d'Alphaworks, IBM

Formateur XSL Outils de traitement d'objets de mise en forme XSLMoteur XSLT Outils de traitement d'objets de mise en forme XSLT

Références de produits : Koala XSL Engine de l'INRIA,

Utilitaires XSLT Différents types d'utilitaires relatifs à XSLT



Utilitaires XPath Différents types d'utilitaires relatifs XPathMoteurs de recherche Logiciel d'indexation de documents XML, de recherche et

récupération du contenu de documents XML.

4.1.3. Une communauté mondiale de développeurs et des systèmes industrialisés

XML se développe fortement à partir de tous les centres universitaires et centres de recherche de la planète, et ces développements sont maintenant renforcés par ceux d'innombrables entreprises offreuses ou utilisatrices.

Dans un mouvement qui est sans conteste celui du "logiciel libre", des outils techniques multiples circulent. Des bibliothèques se créent. Des réseaux ouverts à tous permettent de s'informer et fournissent gratuitement des logiciels – par exemple le réseau Alphaworks d'IBM.

En même temps, une première génération de logiciels arrive effectivement sur le marché – ou sont diffusés gratuitement.

C'est évidemment d'abord le cas pour les navigateurs. Internet Explorer 5, de Microsoft, est un véritable parseur qui est capable de valider un document par référence à un schéma (mais pas une DTD – ce qui ne saurait être grave à relativement court terme). IE5 est capable également d'indiquer si le schéma est valide. En utilisant le schéma et une feuille de style, il est possible d'ouvrir les fichiers XML et de les afficher le document dans la présentation souhaitée.

C'est aussi le cas pour de premier systèmes de portail ou de gestion de données qui utilisent pleinement XML. Parmi les premiers, Tamino (Software AG) ou les produits d'intégration de WebMethods ou Sequoia. Ce dernier propose notamment un outil d'indexation et de recherche de documents XML, Xdex.

Tous les serveurs de commerce vont aussi de façon plus ou moins accélérée vers le support d'XML, quand ils n'en font pas le centre de leurs nouvelles offres, et notamment, bien sûr, Microsoft avec ses serveurs Biztalk attachés aux serveurs de commerce et aux serveurs Web.

Pour l'EDI, des générateurs de messages vont se multiplier, car en XML, ce n'est pas tant le message qui sera stocké et rigide que des méthodes et des dictionnaires. Il ne faut pas confondre ces outils avec ceux qui, comme XEDI Translator, sont capables de



convertir à la volée les transactions EDIFACT ou X12, par exemple, en XML et réciproquement, encore que de tels outils soient très utiles pendant toute une période.

Les outils peut-être les plus importants, en tout cas pour l'EDI, sont ceux qui vont exploiter la modélisation et être capable de produire des messages XML à partir de flux modélisés – et de la référence aux répertoires normalisés. De tels outils doivent être capables de produire des documents XML mais aussi d'autres syntaxes. Des logiciels apparaissent effectivement, qui génèrent, depuis une description fonctionnelle issue d'un modèle, soit des implémentations de messages EDIFACT à partir des messages normalisés, soit des DTD ou des schémas en se référant aux dictionnaires disponibles. De tels outils existent et vont se développer dans l'avenir. Ils devraient d'ailleurs aussi permettre d'opter entre différents dialectes XML.

En fait, progressivement, toute l'industrie informatique intègre les interfaces et les outils XML (par exemple les offreurs de bases de données), de telle manière que, en dehors des éditeurs et parseurs spécialisés, il ne sera bientôt plus pertinent de distinguer les logiciels XML.

Même, si Excel – ce qui va être le cas – est capable de produire à la demande un format XML, est-ce un éditeur ?

4.2. Impact d'XML sur l'informatisationComme toute cette partie le montre, XML aura à terme un impact très important sur toute l'informatique et les systèmes d'information.

4.2.1. Un impact actuel fort mais caché

L'internaute qui découvre qu'il a reçu un document XML mais n'a pas le navigateur capable de le lire voit pour la première fois de l'XML sur son écran (et, faut il espérer, pour la dernière fois).

En fait, XML est déjà intégré, même dans son état peu stabilisé, dans de multiples serveurs et services, ainsi que dans des systèmes internes aux organisations, notamment pour la mise en relation d'applications. L'internaute lui-même l'a, entre autres, utilisé avec le push, puis avec les canaux d'Explorer ou Netscape, puis avec la personnalisation de son profil dans de nombreux sites.

En revanche, son utilisation dans des progiciels micro pour les professionnels et le public reste encore très limitée. XML reste sur les serveurs – et y restera peut-être



longtemps – et c'est HTML qui circule entre le serveur et l'utilisateur.

Même dans les échanges inter-entreprises, aucun des groupes qui travaillent pour certains depuis plusieurs années n'a produit autre chose que des implémentations test (par exemple HL7 a fait une démonstration d'interopérabilité). En effet, c'est tout l'ensemble des outils qui doit être développé et harmonisé, des schémas aux systèmes de signature ou aux requêtes à des répertoires. Seul un transfert commercial entre Intel et un fournisseur fonctionnait, en mai 2 000, en suivant les standards de RosettaNet.

4.2.2. Impact économique

Il serait erroné d'attribuer à XML le développement, qui est commencé, de l'accès des petites et très petites entreprises à la communication électronique. XML fournit l'outil à une demande que le Web et en général l'évolution sociale et technique ont suscitée.

En 2 000, plus de la moitié des petites entreprises ont accès à Internet, et déjà plus de 20% ont mis en place un Intranet, plus de 10% sont reliées à un Extranet.

Les taux d'équipement croissant à un rythme lui-même accéléré, le problème n'est plus l'utilisation des réseaux, mais ce qui passe dessus. L'EDI sera la une des demandes les plus fortes des années 2 000, parce que c'est la communication qui est essentielle désormais, avec ses clients, ses fournisseurs, partenaires etc.

Le point clé pour ces entreprises est que les outils XML seront progressivement intégrés gratuitement dans les outils courants de l'informatique, qui eux-mêmes seront souvent gratuits. Les briques de base seront donc bientôt en place.

4.2.3. Impact sur l'organisation de l'informatique

La grande opportunité d'XML, c'est la cohérence de la démarche entre des fonctions diverses

Les dictionnaires de données et de structures, un grand nombre d'éléments, les langages dans de nombreux cas seront communs ou partiellement communs entre les applications internes, les gestions de bases de donnés, les échanges internes et externes, les référencements, la diffusion sur le Web etc.

Les passerelles entre les différents systèmes ou les passages seront réalisés grâce aux Namespaces, à des feuilles XSLT et à des feuilles XSL.

Pour les développeurs et gestionnaires de systèmes d'information, c'est un atout très important, alors que jusqu'ici une équipe EDI avait peu de points de communication



avec une équipe base de données ou une équipe de publication HTML. L'organisation du travail va s'en trouver profondément modifiée. Les approches par modélisation et dictionnaires de données peuvent être beaucoup plus systématiques, et le dialogue avec les utilisateurs peut aussi être maintenu de façon beaucoup plus simple et intelligible. XML permet à des langages simples et humainement compréhensibles de se diffuser dans de vastes communautés.

L'impact sur l'organisation de l'informatique, dans les entreprises comme dans les sociétés de l'offre, va être fort et renforcer celui de l'approche objets. La séparation sera claire entre des ateliers informatiques et les unités de conception de systèmes et d'application. Les premiers produisent des modèles, des objets et des dictionnaires, les seconds sont dirigés par des utilisateurs et produisent des spécifications, y compris avec des outils de modélisation "transparents".

A terme, c'est bien toute une conception nouvelle de l'information qui se diffuse, l'informatique repassant en arrière-plan. Dans ce mouvement, des systèmes aussi installés que le micro, par exemple, seront remis en cause, l'important devenant l'accessibilité à des informations et des services depuis tout point de travail. La réflexion sur l'organisation et sur les sémantiques, qui peut être menée par des non informaticiens – à condition seulement de connaître les possibilités offertes -, est de plus en plus stratégique.
