Ah ! Je ne suis pas d'accord avec ce texte, c'est une excellente
occasion pour dire Bonjour à Claude Chiaramonti :-)
Le 20 Feb 01, redacteurs@xmlfr.org a écrit :
>
> La question est : " readable par qui ? " Surement pas par les
> utilisateurs pour qui une arborescence XML apparaitra tout autant
> illisible qu'un message Edifact ! Par ceux qui mettent au point un
Et pourquoi donc ?! Pourquoi une facture devrait se transformer en
un message obscur à cause d'une arborescence XML ?
XML ou pas, le message deviendra illisible s'il est trop long, ou si
l'arborescence est trop complexe.
Dans les échanges réguliers avec un nombre trés important
d'informations, comme dans le cas Edifact, il est clair que la
lisibilité humaine n'apporte rien, mais il n'en est pas de même pour
les flux d'échange à caractère ponctuel. Pour eux, plus le nombre
d'intervenants est élevé, plus les informations sont diversifiées, plus
les enjeux sont importants, plus il faut que ces échanges soient
lisibles à toutes les étapes de la transaction.
Cette clarté permet de diminuer le risque inhérent aux contextes
ponctuels.
Edifact devrait être employé pour les contextes stables ou
répétitifs, les communications à la mode XML devraient être
utilisées pour les contextes ponctuels ou fluctuents, comme les
projets, par exemple.
> schema XML , alors ? Mais ces " designers " seront plutot agaces par des
> balises (tags) leur rappelant sans cesse en clair ce qu'ils sont en train
> de manipuler !
>
Pas du tout, au contraire. Les informaticiens ont depuis longtemps
appris à commenter leurs programmes, à expliciter les règles de
nommage, à rechercher la bonne appellation pour leurs références,
même pour les instructions les plus usitées. Cela n'empeche pas
une bonne concision du texte. Concision et développement sont
deux démarches complémentaires qui font l'essentiel du travail des
informaticiens.
Ce n'est pas pour rien qu'ils se donnent des "setText", "setTitle",
"setTooltipText", et qu'ils n'hésitent pas même avec des
"ArrayIndexOutOfBoundException"... Il n'y a aucune raison que
cela soit différent pour les échanges de données.
C'est toujours pareil : tant que vous faites vos programmes dans
votre coin, pour votre petit (ou gros, d'ailleurs) intranet dont
personne d'autre que vous ne connait le fonctionnement exact, cela
passe. Mais dès que vous devez en sortir, impliquer plusieurs
personnes dans le développement, cela casse. Pour réussir, la
seule façon est que toutes les étapes du développement soient
lisibles.
Certes, et bien sûr, certains disent utiliser des outils de
développement extrêmement élaborés (ie : "graphique" est
l'expression consacrée) grâce auxquels ils prétendent pouvoir se
passer des commentaires. Là encore, dès qu'ils doivent travailler
en collaboration avec des personnes qui n'ont pas ces outils, ou
plus habituellement qui en ont d'autres, incompatibles avec les
premiers, cela casse.
Ce sera la même chose avec les messages. Lorsque le contexte
transactionnel est stable et fermé, comme avec Edifact, il n'y a pas
de problèmes. Vous pouvez être aussi obscur que vous le
souhaitez. S'il est ouvert et dynamique, la lisibilité à toutes les
étapes, particulièrement dans son état "brut", est très importante.
Elle est l'une des conditions de la réussite, parce qu'elle permet
une vérification sans ambiguité.
> En fait, la separation dans XML entre structure et presentation devrait se
> retrouver dans les balises definissant chaque element : au niveau
> structure, un code serait suffisant pour les balises d'un schema ou
> message XML , le libelle de ces balises etant trouve, par exemple grace a
> une transformation XSLT , dans autant de feuilles XSL (accompagnant au
> depart les schemas) que de langues, francais notamment.
>
Hum... Il serait donc possible de transformer un document en
allemand
en un document en espagnol par une simple transformation XSLT
!? Il suffirait d'un
dictionnaire commun et d'une structure commune !? Et cela
simplement parce
qu'on est dans le domaine du B2B !? Ce serait un jeu de
balises arborescentes ?
> Les concepteurs de messages Edifact se debrouillent tres bien du
> caractere code des donnees et de leurs listes de codes, les
> utilisateurs, eux, disposant du couple code-libelle en clair dans les
> guides d'utilisation. Il devrait en etre de meme pour XML .
>
Mais alors à quoi sert donc XML ?
Avec XML l'enjeu, à mon avis, n'est pas d'inventer le 50 millième
repository central, qu'il soit proposé par le directeur général
d'Edifrance ou pas, mais de faciliter la transformation d'un système
à un autre.
Autrement dit, que le codage inventé par la sous-secrétaire de
troisième catégorie stagiaire puisse être facilement transformable
en celui mis en oeuvre par le sous prefet aux champs de la
circonscription voisine. Si un effort de clarté n'est pas fait à tous
les niveaux, cela sera impossible.
Ce n'est pas la relation avec un repository central que XML facilite,
cela, effectivement, Edifact le fait très bien, Edifact doit continuer à
la faire, XML n'ajoute rien.
C'est la transformation d'une référence à une autre référence que
vise la technologie XML.. Dans un contexte transactionnel ouvert et
dynamique, le repository central ne sert à rien. Il est en
permanence dépassé. Seules servent les transformations que vous
faites d'un référentiel à un autre.
> Ce codage des balises XML , n'aurait donc pas d'inconvenient mais
> pourrait comporter des avantages :
>
> - les codes Edifact pourraient etre utilises, selon une proposition
> de Marc Langlois , Delegue General d' Edifrance , ce qui
> assurerait automatiquement la reprise de la semantique Edifact dans
> XML ;
> - les balises seraient moins longues et couteuses a transmettre lors
> de chaque message ;
Non, cela n'a rien à voir. Les techniques de compression sont une
bonne réponse au cout de transmission pour les messages XML.
> - un code pour chaque element XML renvoyant a un repertoire central,
> par exemple un TDID commun Edifact - X12 , serait plus efficace que
> les " namespaces " disperses et pouvant etre vides ;
C'est là toute la question. Moi, je crois que non. Je me trompe peut
être.
Il est exact que les namespaces doivent être perfectionnés, ou
revus, ou je ne sais quoi d'autre.
En tous cas, vous avez tout a fait raison en disant que le référentiel
EST dispersé, et qu'il PEUT ETRE vide.
C'est comme ça, Edifact ni aucun repository central n'y peuvent
rien, c'est comme ça. On est même sûr d'une chose, c'est que si
les namespaces ne sont peut être pas la bonne réponse, Edifact
ne l'a pas été non plus.
> - l'alignement general sur l'anglo-americain serait battu en breche a
> la condition de disposer d'un referentiel multilingue du type BSR
> permettant de verifier, pour une balise codee, qu'un libelle francais
> et un libelle anglais se referent bien au meme concept et que donc
> aucune ambiguite n'est a craindre.
... encore une fois, si c'est si simple, dans ce genre de problèmes,
pourquoi Edifact
n'y est pas déjà arrivé ? Pourquoi XML y arriverait mieux ?
La clef pour y arriver, c'est le contrôle humain, et donc la lisibilité.
Je ne vois pas d'autres solutions. Ces vérifications n'empêchent en
aucune façon l'automatisation, la réactivité, etc.
Le résultat auquel on parviendra si l'on ne fait pas un effort de
lisibilité dans chaque contexte, est que l'on aura remplacé des
systèmes Edifact qui fonctionnent actuellement très bien dans
certains cas et mal dans d'autres, par des systèmes XML qui
fonctionneront très bien dans les mêmes cas et très mal dans
toujours les mêmes cas que Edifact ! (entre temps, les sociétés de
service informatique s'en seront mis plein les poches si je puis me
permettre).
La solution proposée par la mouvance XML (et d'autres) est de
mieux documenter la transaction, pour pouvoir plus facilement la
localiser dans un premier temps, la transformer dans un deuxième.
Il s'agit de mieux la documenter non pas par rapport à un référentiel
central, mais par rapport à son propre référentiel local. Le "pari" est
de dire que si on connait bien le couple "Transaction / Contexte de
la transaction", alors il est plus facile de le transformer et de le
transmettre. Pour bien connaitre ce couple, il faut - entre autres -
que son expression soit "human readable".
C'est de cette façon, soit dit en passant, que travaillent les
interprètes anglais / allemand / chinois etc. Ils ne travaillent pas
avec un repository commun et une feuille de style XSLT. Les
tentatives de langues communes styles esperanto sont restés des
exercices de style intéressants, c'est tout. Pour réussir, pour que
la traduction soit bonne, il faut connaître le contexte de chaque
interlocuteur, son patois, son accent... son odeur, des fois même.
Voilà, j'espère que cette réponse est "human readable" :-)) J'ai
conscience que mes interventions sont souvent
incomprehensibles, et j'en suis sincèrement désolé.
J'en profite pour remercier Claude Chiaramonti pour ses
"VendrEDI", que je lis toujours avec plaisir.
--
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 Tue Feb 20 11:02:42 2001
