xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: INFO : ebXML face au pragmatisme
From: Herve AGNOUX (herve.agnoux@diaam-informatique.com)
Date: 25/09/2002 - 21:46
Le Mardi 24 Septembre 2002 12:12, Eric van der Vlist a écrit :
>
> C'est bien le but des core components de définir des composants de base
> de "granularité zéro" qui, comme une date, soient utilisables dans tous
> les schémas...
>
Je trouve abérant que ce soit encore un "but" ! Il existe déjà quantité de
core-components, depuis bien avant XML, et s'il faut encore en inventer
d'autres, c'est bien que ces core-components sont des arlésiennes.
Sauf erreur (je ne suis pas historien), avant l'arrivée d'XML il y avait déjà
des normes, des conventions, certaines comme le Dublin Core ("Core",
justement) se sont adaptées à XML sans que cela pose de problèmes
philosophiques interminables.
Pourquoi pour l'EDI est-ce si difficile ? Je n'en sais rien (ou je ne veux
pas le savoir), et je le déplore. C'est comme ça.
Cela n'empêche pas qu'il y ait d'excellents candidats. Mais QUE des candidats.
Donc le pragmatisme commande de considerer que les core-components viendront
peut être un jour, et que en attendant ils n'existent pas. La seule solution
pragmatique est de faire attention aux transferts d'un modèle de
core-component local à un autre modèle de core-component local.
Sans un core-component unique, les transformations EDI deviennent un monde
très intéressant, puisque avec des exigences particulières : exigences de
rapidité face à de gros volumes à traiter, exigences sur la compréhension des
processus concernés, sur la modélisation, sur les responsabilités en cause
(que deviennent les signatures après une transformation ? ), etc.
Et surtout il faut concevoir les systèmes EDI en imaginant qu'ils pourront
communiquer avec des systèmes complètement différents, sans qu'ils soient
"couverts" par un système général et uniformisateur. Le défi technologique
est immense. En l'abscence de core-components, comment faire ?
>
> Je pense aussi que ces "micro transformations" sont importantes et c'est
> dans ce sens que va ma proposition "xvif" qui propose de les intégrer
> dans les schémas!
>
> http://xmlfr.org/index/object.title/xvif/
>
Je n'ai vu qu'un article ? (très bien, d'ailleurs) Aucun lien vers le xvif
soit même, ai-je mal vu ? Le xvif ferait des transformations si petites qu'on
ne le voit pas ?
Notez que si je prends simplement ce que je lis dans l'article, je vois un
schéma avec des micro-transformations. Avant de faire la validation opérée
par le schéma, on fait des micro-transformations de façon à adapter des
particularismes sans être obligé de refaire un schéma à chaque fois. (dites
moi si je me trompe).
Mais si le schéma de base s'attend à recevoir telle information à tel format
(date ISO, pour reprendre votre exemple), qu'une transformation préalable à
la validation transforme une date française en date ISO pour que le test soit
OK, il faut bien que dans le flux de transfert la date française soit
réellement transformée en une date ISO, sinon tout est perdu.
Donc, à une transformation coté schéma correspondra la même transformation du
coté de la transmission. Si le destinataire s'attend à recevoir une date ISO,
puisqu'il l'a placée dans son schéma, ce n'est pas pour recevoir une date
française, même validée par une micro-transformation !
Donc (encore) il faut un parralèlle entre la validation et la transformation.
Comment faites-vous ? A ma connaissance, cela n'existe pas ?... Encore une
bonne raison pour s'intéresser aux transformations dans le monde EDI !
Cordialement.
--
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)
Archive générée par hypermail 2.1.3 le 27/09/2002 - 09:22 UTC
webmaster@xmlfr.org
| 
