Jacques Talbot wrote:
>
> On Fri, 2 Mar 2001, Pierre Glaser wrote:
> Nous Bull sommes plutôt des fournisseurs d'infrastructures XML et sommes
> donc plutôt focalisés sur les offres XML horizontales
> c'est à dire les protocoles style UDDI, SOAP, ebXML ...
> les outils parseur ...
> Néanmoins, nous aimerions mieux comprendre la dynamique ou l'écologie
> du monde des dialectes verticaux de XML, par secteur d'industrie.
> Voilà donc plutôt une liste de choses sque nous croyons
> avoir compris, ou de questions que nous nous posons, en profitant
> du message de Mr Glaser pour prendre des exemples
> dans le monde de l'assurance.
>
> - 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?
Sur un plan technique, il me semble qu'une des clés pour résoudre ce
problème est la gestion du typage des données.
Jusqu'à présent (peut-être à cause des DTDs qui n'ont pratiquement pas
de notion de types de données), XML s'est penché sur le problème des
structures XML et l'on sait facilement transformer la structure des
documents, notamment grâce à XSLT.
Il semble donc relativement facile de prendre une information concernant
une voiture dans un constat d'accident et de la placer dans un document
qui décrira un véhicule, à condition que l'on sache dire qu'il s'agit du
même type de donnée ou que l'on sache transformer ces types, ce qui
n'est pas le cas avec les outils XML actuels.
N'est-ce pas un des problèmes que cherche à résoudre ebXML ?
> - 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.
Si ce problème est posé seul, je pense qu'il est facile d'imaginer des
solutions (comme celle proposée lors de la discussion [1] avec Jean-Marc
Destabeaux sur cette liste) pour assurer la traduction des noms
d'éléments et d'attributs.
Si on pose le problème conjointement avec la question précédente, on
peut être tenté de résoudre les deux problèmes par une approche de type
ebXML qui revient à dire que les noms des éléments sont là à titre
décoratif et qu'on utilise un autre mécanisme pour identifier les
informations.
> - 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 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.
Effectivement, il y a là un mécanisme qui tend à s'auto compenser.
D'un côté, il est classique d'utiliser les nouvelles technologies pour
rechercher un avantage concurrentiel et développer un standard qui
permet de faciliter les échanges avec ses clients et fournisseurs ne
devrait pas échapper à cette logique.
D'un autre côté, pour que ce standard soit utilisé, il faut également
convaincre ses concurrents de l'utiliser, ce qui réduit ou annule
l'avantage concurrentiel.
Il reste une légère avance et un effet sur l'image des sociétés ayant
développé le standard (on en revient à l'accusation de Pierre Glaser
qualifiant INSpML d'habillage marketing).
> Tout ça est loin d'être exhaustif, c'est pour nourrir le débat.
Merci d'avoir partagé ces réflexions et interrogations.
Cordialement,
Eric van der Vlist
[1] http://xmlfr.org/listes/xml-decid/2000/index.html#121
> --
> Jacques Talbot Bull 1 rue de Provence BP208 38432 Echirolles CEDEX France
> Mailto:Jacques.Talbot@bull.net Internet: http://www.bull.com/unix
> Intranet: http://intranet.frec.bull.fr/personal_page/talbotj/public
> Tel: 04 76 29 75 19 Intl Phone: +33 4 76 29 75 19 FAX: 04 76 29 77 00
>
--
See you in Austin (Knowledge Technologies 2001)
http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.com
http://xmlfr.org http://4xt.org http://ducotede.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 09:31:59 2001
