xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: Pourquoi XML?
Auteur: abella free (fabella@free.fr)
Date: 27/08/2001 - 03:22
-----Message d'origine-----
De : xml-decid-bounce@xmlfr.org [mailto:xml-decid-bounce@xmlfr.org]De la
part de Herve AGNOUX
>
>Mais alors c'est vous qui faites Test&Go ? D'après "[xml-decid] INFO
>: TEST&GO en XML", à http://xmlfr.org/listes/xml-decid/2000/0085.html
>vous auriez réalisé un parser XML pour valider des documents TDS,
>produit jugé satisfaisant par la CNAV. C'est de cette expérience à
>laquelle vous faites référence aujourd'hui, pour dire que pour les
>gros fichiers il vaut mieux en rester à des fichiers plats ?
Effectivement c'est notre société qui produit le logiciel Test&Go.
Concernant l'article de Claude Chiaramonti (auquel vous faites allusion), il
fait simplement référence au fait que nous sommes capables de parser tout
types de fichiers (XML, A PLAT...) et que nous avons pour client entre autre
la C.N.A.V. qui a intégré notre technologie pour la conformité des
informations chez les entreprises. En ce qui concerne nos tests, ils sont
basés sur une autre norme (pour info TDS doit disparaitre à cours terme).
>Au niveau technique (je reviens ensuite au niveau de la reflexion
>générale), pour les gros fichiers, le W3C suggère de faire le
>transfert de fichiers XML compressés. Mais, pour les gros fichiers,
>justement, j'ai peur que le temps de compression / décompression soit
>important. L'avez-vous essayé ? Qu'en pensez-vous ?
Nous avons effectivement réalisé un benchmark (part de notre savoir faire).
Je peux par contre vous indiquer que globalement les resultats sont
moyennement satisfaisant.
>Ensuite vous parlez de l'utilisation de SAX, mais aussi de XDOM. Mais
>pourquoi avez-vous utilisé DOM ? Cette technologie est effectivement
>très lourde et très couteuse en temps, particulièrement pour les gros
>fichiers. Pourquoi n'avez-vous pas pu faire vos validations
>uniquement à partir du lecteur SAX ?
Le choix de la mise en place soit d'une gestion mémoire compléte XML à
travers DOM ou évenementielle à travers SAX dépend du choix stratégique des
régles de gestions afférentes aux contrôles.
>Pour la reflexion générale, j'imagine que vous serez d'accord avec
>moi : l'EDI est stratégique pour le XML, le XML est stratégique pour
>l'EDI. Et s'il est un domaine parmi les domaines stratégique pour
>tous, c'est bien celui des données sociales. Et si l'on commence à
>s'engager dans un dialogue XML / TDS pour les "petits" fichiers, un
>dialogue fichier plat pour les gros, j'ai peur que l'on perde
>complètement au niveau de l'interopérabilité.
>
Je suis d'accord sur le concept mais etant plus en addéquation avec le
marché je pense qu'il existera une multitude de possibilité offerte aux
éditeurs & entreprises pour transferer leurs données XML/EDIFACT/fichier A
PLAT/VARIABLE....suivant leurs besoins mais par contre un seul logiciel
concentrateur qui analysera l'ensemble de ces flux pour ensuite les
convertir en un flux à norme unique. En fait je suis en train de decrire
notre produit :-)
>Certes la réflexion de Eric était de dire qu'il existe d'autres
>systèmes de langage que le XML, ce qui est vrai, mais pas pour le
>couple EDI / XML. Ce couple là réussira ensemble ou ne réussira pas.
>D'où mon souci de fouiller un peu les contingences techniques...
>
Je suis moins binaire dans ma réflexion puisque je considére XML comme un
outil parmi d'autres à disposition du schéma directeur des systèmes
d'informations. La ou je suis plus prudent, c'est dans le passage à cours
termes des flux stratégiques vers XML
--
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.4 le 29/07/2002 - 15:14 UTC
webmaster@xmlfr.org
| 
