Bonjour,
 
Ci-dessous VendrEDI n° 63 pouvant être imprimé pour un meilleur confort de lecture (cocher les pages 2 à 3).
 
Edisanté organise le 11 juin prochain à Bobigny une journée de formation et d'information sur l'utilisation d'XML dans les échanges du secteur socio-sanitaire, à partir des travaux de ses différents groupes techniques. Cela peut être intéressant pour tous : pour connaître les conditions d'inscription, téléphoner au 01 40 22 91 87 ou télécharger programme et bulletin d'inscription sur le site d'Edisanté.
 
Réponse à une question de lecteur concernant les sigles en majuscules ou non : je suis la règle consistant à écrire en majuscules les sigles épelés lettre à lettre, comme S, N, C, F ou E, D, I, mais laissant minuscules les sigles prononcés comme s'il s'agissait de mots, Afnor, Edisanté etc. Cas limite, Onu peut aussi se prononcer O, N, U, mais pas dans le cas du Cefact-Onu qui ne s'épèle pas Cefact-O, N, U. Exception amusante à cette règle : j'écris ISO alors justement qu'il ne s'agit pas d'un sigle mais du mot grec "iso" signifiant "égal" ! Mais je trouve que Iso TC 154, par exemple, fait bizarre alors que ISO TC 154 paraît "normal" ;-)
 
Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
Cordialement
 
Claude Chiaramonti
 
 
 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
        Numéro 63       16 mai 2003
 Le Cefact-Onu 
 
Multilinguisme :
à la croisée des chemins !
balises codées ou en anglais ?
L'ONU comporte des Commissions économiques régionales. Celle pour l'Europe, la CEE-Onu située à Genève, inclue les USA, le Canada et la Russie, suite à la 2ème guerre mondiale. Cette CEE-Onu comporte une Division du trade : c'est là, en tant qu'outil de la trade facilitation,qu'y est né en 1987 l'EDI et son standard Edifact. Mais double pro-blème : d'une part la simplification du commerce international ne se résume pas à l'EDI et d'autre part cet EDI concerne bien d'autres domaines que le trade ! Et au lieu de laisser la norme Edifact se développer à l'ISO (comme le préconisait la France dès 1990) et la trade facilitation rejoindre l'OMC, on essaye depuis 10 ans de maintenir tant bien que mal une synergie entre les deux !
Les changements de procédures (VendrEDI n° 29), ont limité la prépondérance des utilisateurs, natio-naux  comme internationaux, privés comme publics,
ce qui avait  pourtant permis le succès d'Edifact. En particulier depuis le PACS avec Oasis ayant en-fanté ebXML, l'équipe dirigeante du  Cefact-Onu, cherche une efficacité "consortium" pour laquelle les technocrates US trouvent les règles de l'Onu bien trop contraignantes.
Une réflexion confidentielle a étudié les scénarios possibles d'une "émigration" de l'e-business qui laisserait seule la trade facilitation à la CEE-Onu Mais, juste avant la réunion plénière de cette semaine du Cefact, le service juridique de l'Onu a accepté l'idée de service providers et d'un trust fund pour recueillir les moyens des registries prévus pour ebXML. Cependant, des points n'étant pas clairs, des explications seront demandées au service juridoque. Si besoin, une réunion plénière exceptionnelle sera convoquée en novembre. 
En tout cas, à la CEE-Onu ou ailleurs, l'essentiel sera de laisser la technique aux consortiums et de permettre aux utilisateurs de diriger la transposition en XML leurs standards de contenu e-business à partir de leurs langages et processus métiers. Sinon, le Cefact-Onu ne pèsera pas bien lourd face aux consortiums !  Voir Oasis dont les groupes de travail se mettent à doubler ceux du Cefact, comme UBL ou le tout récent sur l'Electronic Procurement Standardization qui veut associer public et privé !
 
La version bilingue franco-anglaise des répertoires Edifact n'est plus maintenue par Edifrance depuis longtemps, faute d'intérêt de la part des utilisateurs. Et pourtant les guides d'utilisateurs francophones des messages Edifact sont bien rédigés en français ! Pourquoi alors n'ont-ils pas eu besoin d'être basés sur une référence officielle qui soit bilingue ?
Il semble qu'il faille bien identifier les besoins :
1/ Disposer de définitions des données à échanger qui soient libellées en français, pour être sûr de les "mapper" sans ambiguïté avec les données des applications internes aussi libellées en français.
2/ Identifier ces données à échanger sans ambiguïté d'un pays à l'autre, indépendamment de la langue.
En Edifact, les répertoires de données ne sont publiés par l'Onu qu'en anglais, mais comme l'identi-fiant des données est numérique, le nom et la défini-tion d'une donnée en anglais ne sont que des attri-buts auxquels ont peut très bien ajouter d'autres attributs en français ou autre langue.
On peut de même souhaiter pour les schémas XML (cf VendrEDI n° 33) des balises chiffrées identifiant les données de manière codée non significative (6325 etc.), avec autant de transforma-tions XSLT que d'attributs dans chaque langue. D'ailleurs, Alain Chapdaniel (Actimum) rappelle qu'un identifiant numérique a été ajouté aux règles de nommage (en anglais seulement) d'ebXML, et qu'avec ou sans balises codées, les correspondances entre langues s'organisent avec l'outil BSR.
Pour Rémy Marchand (API*EDI), l'essentiel est le travail sémantique qui part de l'anglais, considéré comme langue de travail, avec traduction dans les langues concernées. Sans balises codées, n'ayant d'intérêt que pour réduire la longueur des balises en clair, ce qui n'est plus un problème en haut débit.
En tout cas, balises codées ou en anglais, il faudra bien organiser le multilinguisme : on ne peut laisser des entreprises francophones, confrontées à des données en allemand, finlandais ou grec, se de-mander en permanence s'ils parlent bien de la même chose que leurs partenaires ! Car si le multilin-guisme ne s'organise pas, ne serait-ce que pour les formalités administratives européennes, l'anglais finira par faire oublier les langues vernaculaires dans l'e-business !
Pour que "le message passe" il faut bien être d'accord sur le sens des données à transmettre

      La convergence :  
 
Migrer l'EDI en XML : 
      Semantic Web et Services Web 
 
oui, en gardant la sémantique
Le Semantic Web a comme ambition d'automatiser au niveau sémantique, non seulement  le lien entre bases de données et le partage des informations entre  applications, mais aussi la combinaison de Services Web. Face à des critiques lui reprochant de négliger la standardisation des Services Web au profit du Semantic Web, le W3C répond donc que Semantic Web et Services Web sont complé-mentaires. L'un ayant en charge le contenu sémantique des données et leur intégration, les autres la transmission de ces données, comme HTML pour contenu et HTTP pour transmission.
D'ailleurs, le Directeur Général du W3C, Tim Berners-Lee, considéré comme le créateur du Web, a expliqué, lors d'une récente conférence Gartner, que les réflexions du W3C sur le Semantic Web, qualifiées par certains de "théoriques", pou-vaient parfaitement être aussi très utiles pour les performances des Services Web.
En effet, le Semantic Web est basé sur les assertions RDF, qui permettent de modéliser et décrire le monde réel, pas seulement des documents, et ainsi faciliter les liens qui enrichissent un Service Web. Par exemple dans le commerce de l'automobile, la modélisation Semantic Web reliant les différents types d'objets permettrait à l'application de trouver facilement le lien entre véhicule et conducteur, entre n° d'immatriculation et permis de conduire, entre photo du véhicule et adresse du propriétaire etc. Et cela en remplaçant les arborescences classiques entre objets théoriques par un Web, une toile, reliant choses, lieux et personnes du monde réel. Pour Tim Berners-Lee, "your life is a Web, your data is a Web" !
Oasis ayant pris la tête pour la standardisation des Services Web, le W3C poursuit donc la mise au point des outils du Semantic Web en poussant vers le stade de recommandation RDF et OWL. Pour lutter contre l'image trop futuristic or eccentric du Semantic Web, le W3C organise le mois prochain une tournée d'information gratuite en Europe.
Car, pour que ça marche, il faut qu'un grand nombre de contenus  aient été décrits au préalable avec les assertions RDF (triplet nom, objet, verbe) pour leur permettre d'être "compris" automatiquement par une autre base de données, application ou Service Web. Le Semantic Web commencera seulement alors à exister. Vaste programme quand on voit déjà que XML pourrait se diffuser plus vite. Mais il est vrai que cette automatisation du mapping et de la liaison entre données et programmes, ambition de toujours de l'informatique, serait impressionnante !
 
Qu'il s'agisse de simple traduction en XML des messages EDI ou de modélisation des échanges redéfinissant tous les processus, il faudra s'efforcer de sauvegarder la sémantique déjà définie.
Pour les usagers de XML souhaitant rejoindre une communauté Edifact, l'ISO  TS 20625 préconise des règles pour la génération de schémas XML W3C (XSD) à partir de guides d'implémentation de messages (MIGs). L'identifiant numérique des données (et codes) des répertoires Edifact peut être mentionné, aussi bien que leur intitulé anglais en clair. Bien qu'adoptée contre l'avis du Cefact, cette Technical Specification permet de relier EDI et XML sans attendre la refonte de l'existant !
A noter qu'un schisme est apparu sur la manière de transposer en XML le message comptable INFENT pour le B2A. Soit définir autant de schémas XML que d'imprimés, avec référence à une sémantique type ebXML quand elle sera là. C'est simple pour une formalité prise isolemment. Soit ne définir qu'un schéma XML de transmission (le message inXent) qui identifie la séquence des données transmises pour chaque formulaire, mais sans sé-mantique détaillée, impossible à rassembler pour tous les pays et, de plus, changeant parfois chaque année. C'est sans doute la manière la plus simple de traiter des centaines de formalités, mais apparaît comme une usine à gaz pour une formalité isolée ! Et faut-il vraiment un registry ebXML de Core Components pour les innombrables données admi-nistratives de n pays quand la déclaration des formalités reste nationale pour l'essentiel ?
Quand une sémantique unifiée a un sens, voir le X12 Reference Model for XML Design, de l'Ansi X12, standard EDI US. Ce modèle repose sur une CICA, Context Inspired Component Architecture, grammaire  XML équivalente de la syntaxe X12, mais qui couvre l'implementation, c'est à dire l'adaptation aux différents contextes possibles. La CICA va ainsi de la modélisation des rôles à la sémantique où elle suit les CCTS, les spécifications ebXML pour les Core Components. La CICA a sept niveaux de granularité depuis le template jusqu'à la primitive, occurrence d'un component. Une hiérarchie de namespaces commencerait par renvoyer aux sous-comités sectoriels d'Ansi X12, puis aux langages métiers utilisés dans chacun d'eux, comme l'a fait un projet-pilote sur la finance.
L'avantage de la CICA étant alors de fournir un cadre souple permettant de réconcilier le foisonnement XML et l'acquis sémantique de l'EDI classique.
Ce numéro 63 de VendrEDI a été adressé à 1093 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés zippés à    http://www.actimum.com/acvendredi.htm