| 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
ce ux 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
fou rnir 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 |