Le 2 Mar 01, Jacques Talbot a écrit :
>
> - il est indispensable de définir des dialectes spécifiques car le
> nom des tags et des objets métiers est totalement ambigu;
> il y a néanmoins des continuités: un accident de voiture
> implique des garagistes, des assureurs, des constructeurs autos
> qui n'appartiennent a priori pas au même segment d'industrie.
> Commment réconcilier ces contraintes?
>
Pour moi, ces contraintes devraient être résolues par XSLT.
Lorsque vous avez un dialecte spécifique, bien adapté à un
contexte, il faut écrire une transformation pour le faire passer d'un
contexte à un autre.
Tant que l'on reste dans des métiers proches, les transformations
peuvent être des équivalences. A la limite, elles peuvent être
réglées par des espaces de noms.
Mais plus les métiers s'éloignent, plus les transformations sont
difficiles, et ne peuvent devenir que de simples modèles.On se
rapproche alors de la notion de "template", que les informaticiens
utilisent depuis belle lurette avec bonheur.
Peut être est-ce un "background Edifact" qui rend ces principes
choquants. Chaque contexte pourrait-il faire ce qu'il veut ?
Théoriquement, oui. Il s'agit, sauf erreur, d'un des objectifs du W3C
quand ils ont monté la norme XML.
Pour moi l'apport d'XML n'est pas de refaire Edifact, mais de
faciliter les transformations d'une communauté d'affaire à une autre.
A mon sens il faut d'abord repérer la communauté, qu'elle soit
intranet, locale, départementale ou autre, anglaise, chinoise, puis
lui donner les tags et structures de message qui lui sont adaptés.
Cela se fait sans se préocuper de savoir si on est conforme à une
norme ou non. La conformité se fait par une transformation XSLT.
Cette position est "à vérifier", certes, à assouplir certainement,
mais il me semble que le principe est clair.
Bien sûr, par exemple, on peut envisager l'inverse, à savoir partir
d'une norme internationale existante, et par transformation XSLT
l'adapter à une communauté. Simplement, cette voie necessite la
connaissance de la norme, ce qui, vu leur poids en kilogramme,
est plus difficile.
> - quelle va être la dimsension géographique d'un dialecte XML?
> le monde, les US, l'Europe, la France?
> Tout dialecte non limité à la France mais l'incluant sera
> de-facto "en anglais"; est ce acceptable (on est ramené à la lisibilité du
> XML par un être humain). Tout dialecte franco-français semble bien étroit;
> l'Europe semble être le bon cadre avec la dérégulation du marché des
> assurances par exemple.
>
Je ne vois pas pourquoi vous voulez choisir. Il faut que la dimension
géographique correspondent aux acteurs de l'échange. Si les
intervenants sont en France, pourquoi ne parleraient-ils pas
français ?
La question de fond c'est : à qui s'adresse ces dialectes XML ?
Une fois cette question résolue, la langue de travail découlera d'elle
même.
> - quel est le rapport de force qui va établir un dialecte comme le
> standard d'un segment d'industrie? Existe t il une chambre des assureurs
> euroéeens, ou francais, qui a vocation à abriter ces travaux? Faute de
> standards europeens, on peut craindre de voir les standards verticaux
> américains dominer, ce qui favorisera l'implanatation des entreprises
> américaines en Europe.
>
Tout a fait exact.
> Tout assureur un peu en avance techniquement va pousser son dialecte. Ca
> me semble de bonne guerre, c'est comme ça que ca se passe en informatique.
> Les autres acteurs doivent ils s'y oppser ou s'y rallier? Souvent des
> petits acteurs sont plus dynamiques et même, moins menacants, peuvent
> servir de point de ralliement technique. Est ce que avoir défini tel ou
> tel dialecte XML donne un réel avantage concurrentiel? J'en doute un peu
> si les autres acteurs suivent trés vite.
>
Moi je ne crois pas. Il me semble que vos idées sont justes dans
le cas où la dominante technique est forte (flash, pdf, php, et
autre). Dans ces cas, c'est le contexte, en fait, qui s'adapte.
Mais lorsque des responsabilités sont en jeu, le contexte s'adapte
beaucoup plus difficilement. Cela fait belle lurette que l'on sait
informatiquement échanger des messages internationaux, sans
qu'il soit besoin de se disputer sur l'anglais ou le français. Ce qui
fait difficulté, c'est qu'il faut que ces échanges se produisent de
façon à ce que chacun assume ses responsabilités.
On le voit, par exemple, dans le domaine du médical. Il n'y a ici
aucun besoin de faire des protocoles internationaux, du moment
qu'ils fonctionnent en France, tout le monde est content.
Informatiquement il n'y a aucune difficulté.
Ce qui est difficile, c'est que chaque médecin, et autre acteur,
reçoive et transmette les informations utiles au moment de son
action, en fonction, ce qui est pour le coup extrêmement difficile
dans le milieu médical, des rapports de force en présence.
Le principe sous-jacent d'XML, à savoir la proximité avec les
intervenants plutot que le respect d'une norme encyclopédique,
peut aider à résoudre ces questions, me semble-t-il, à condition
bien sûr que l'on ne passe pas les 3/4 du temps à refaire Edifact.
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Received on Fri Mar 2 11:53:32 2001
