Bonjour !
 
Ci-dessous VendrEDI n° 59 en html que chacun devrait pouvoir afficher et imprimer. Avantages : plus de pièce jointe à ouvrir, liens indiqués actifs et  copier-coller possible.
 
Comme d'habitude, me signaler par retour des adresses de nouveaux lecteurs ou unsubscribe :
 
A part cela, pour les Parisiens, sparklingPoint continue ses rendez-vous mensuels conviviaux autour d'un verre à 19h au centre de Paris (vérifier) avec exposés et discussions. Prochains RV :
 
13 février : J.J. Thomasson (modélisation XML) et F. Rivard (EAI) ;
13 mars : E. van der Vlist (schémas XML) et E. Jarry (intégration B2B).
 
Détails sur : http://xmlfr.org/sparklingpoint/networkg.html
Inscription : en précisant prénom, nom, société.
 
Cordialement
 
Claude Chiaramonti
 
PS : si l'affichage ci-dessous pose problème, télécharger un logiciel gratuit de messagerie du type Outlook Express.
 
Si VendrEDI s'affiche, mais sans les polices habituelles, je peux adresser les fonts correspondant à Dom Casual pour le titre VendrEDI et Lucida Handwriting Italique pour les sous-titres des articles. Les copier dans C:/ Windows/Fonts. Sinon, les titres d'articles sont en Arial et tout le reste en Times New Roman.
 
Si l'affichage est correct, l'impression devrait l'être aussi. Pour n'imprimer que VendrEDI, cocher pages 2 à 3.
 
En cas de difficulté persistante, me le signaler par retour et je renverrai une image Word habituelle.
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
       Numéro 59        7 février 2003
W3C oecuménique  
Catalogues EANnet.fr
pour danser tous ensemble ! 1/ synchroniser les données
Grand ordonnateur du Web, monde virtuel global, le W3C, Word Wide Web Consortium, est lui-même virtuel, puisque sans existence légale au dessus de ses trois piliers : le MIT aux USA, l'Université Keio au Japon et, remplaçant l'INRIA depuis le début de l'année 2003, l'ERCIM, European Research Consortium for Informatics and Mathematics.  
Virtuel ou pas, le W3C est reconnu par tous, puisque s'y côtoient Microsoft, IBM ou Sun avec des grands utilisateurs comme Boeing ou EDF, des Universités et bon nombre de PME. Le coût de participation est de 5750 $ par an, soit la même somme en €, avec un engagement de 3 ans. Et les grandes entreprises (plus de 50 millions de $ de gross annual revenues) doivent payer dix fois plus ! Cela peut valoir le coup si on tient à être informé en avance pour s'adapter aux tendances (on peut être invité si on est expert et à la condition de respecter la propriété intellectuelle du W3C).
Cet oecuménisme quant à la participation à la mise au point initiale des recommandations est suivie par une certaine transparence puisque les drafts sont ouverts aux commentaires, comme les listes de discussion sont publiques, notamment pour RDF ou le Semantic Web. Les recommandations sont ensuite gratuites, au contraire des normes officielles.
Oecuménisme et transparence peuvent autoriser le W3C à jouer les juges de paix. Le W3C n'y avait pas réussi pour la bataille des navigateurs. Mais il devrait y parvenir pour les Web Services : le W3C vient en effet de créer un Web Services Choreography Working Group qui pourrait jouer les chefs d'orchestre et aider à réconcilier BPEL4WS (de Microsoft, IBM et BEA) avec l'initiative BPML ou encore BPSS d'ebXML, qui ont tous développé leur propre choreography. Sans garantie d'interopérabilité.
Or si l'on veut vaincre l'attentisme ambiant vis à vis des Web Services, le W3C devrait en effet montrer
que tout le monde peut danser avec la même choreography, et avec une partition neutre et libre ! 
                             On peut rêver !
 
Pour Pierre Georget, Directeur Général adjoint de Gencod EAN France, après le code à barres et l'EDI, l'enjeu technologique est la synchronisation des données de base sur les produits.
En effet, avec la complexité de l'offre, le produit ne sera visible sur la scène du commerce que si ses données le sont. Le rôle 1/ du catalogue est donc d'abord de stocker les données de base sur les produits, dispersées dans toute l'entreprise. Data pool d'abord interne pour la gestion de la documentation produit, le catalogue électronique peut ensuite devenir un instrument de distribution de l'information vers l'extérieur.
Mais l'échange des données produit entre partenaires du commerce sera bien sûr facilité si tout le monde adopte les mêmes formats. D'où le réseau EANnet.fr de Gencod EAN France pour connecter les catalogues fournisseurs, les places de marché ou les services d'opérateurs spécialisés. Une condition : être certifié conforme aux standards XML EAN-UCC pour que chaque fournisseur ait la garantie que ses fiches-produits seront lisibles par tous les distributeurs et réciproquement.
En plus de la réduction des coûts de 0,5 % du prix de vente au consommateur, l'ambition d'EANnet.fr est de permettre à l'offre française d'être en tête dans la mondialisation. D'où l'adhésion de nombreux grands fournisseurs et distributeurs, L'Oréal, Nestlé, Colgate, Carrefour, Auchan, Casino, Groupement des Mousquetaires, Galeries Lafayette.
Quelques mois après son lancement, la taille critique d'EANnet.fr est en vue, d'une part avec la certification d'éditeurs d'e-catalogues ou d'outils d'alimentation : après Equadis, VerticalWine, Le Parangon et Catalogic, sont candidats EDT, Influe, Seres etc. et bientôt Microsoft et IBM. D'autre part avec l'adhésion de centrales d'achat comme celles de Leclerc, de Système U etc.
La gestion par la plate-forme EANnet.fr des demandes d'information s'apparente déjà à un Service Web. Pourquoi pas alors, un jour, envisager une étape 2/ offrant des registres UDDI pour des transactions et services standardisés ?
 
Pour que "le message passe" il faut bien être d'accord sur le sens des données à transmettre


UDDI progresse   "Demat" : ça traine
d'intranet en extranet vers le U   mais pas du fait de la DGI !
Décidément, les modèles top down des premiers temps de l'EDI ne correspondent plus aux outils eXtensible basés sur XML ! C'est le cas d'UDDI (UniversalDescriptionDiscoveryandIntegration) défini pour être, dès le départ, un registre Universel. A l'inverse de SOAP et WSDL qui entrent dans les mœurs, UDDI, le 3ème mousquetaire (s'il en faut un 4ème, Microsoft semble candidat...;-) des Web Services, a été considéré comme Utopique.
Et de fait, si la dernière version UDDI 3.0 offre des fonctionnalités permettant de progresser dans cette direction du U, les implantations d'UDDI se font plutôt selon un modèle bottom up très prudent !
C'est d'abord à l'abri du pare-feu, en interne, que les entreprises trouvent une utilité à répertorier leurs services et à les invoquer facilement. Puis de ces intranets, on passe à des extranets sécurisés entre partenaires réguliers (comme en EDI). Cette expectative devant le U s'explique en effet par un souci de sécurité mais aussi par la nécessité de permettre cette évolution intranet>extranet>Web.
Les bindings, points d'accrochage, d'UDDI 3.0 vont ainsi maintenant du n° de téléphone aux protocoles processables, les tModels, associés à chaque service offert. UDDI 1.0 reposait sur le triptyque d'origine : pages blanches (identification), jaunes (nomenclature des produits offerts) et vertes (services, protocoles et tModels). UDDI 2.0 avait ajouté les public assertions par lesquelles des partenaires s'engagent, par exemple quant à la qualité d'un service. UDDI 3.0 a ajouté l'operational info, mise à jour automatique d'un registre UDDI à partir d'autres. A la condition que soit réglée la question du versioning.
Désormais, la confection par un utilisateur d'une "clé" identifiant, par exemple, un de ses nouveaux services sera plus souple. D'une part, UDDI 3.0 vérifie que cette "clé" (l'UUID, Unique Universal IDentifier, dite aussi GUID avec Globally) est bien unique "globalement", et sinon en confectionne une qui le soit. Aux anciennes uuidKeys s'ajoutent maintenant les domainKeys, plus lisibles et basées sur des noms de domaine Internet. A partir de ces diverses keys, on peut créer des derivedKeys, ce qui, au total, devrait faciliter la gestion.
Enfin, le nouveau comité d'Oasis sur XRI (eXtensible Resource Identifier) devrait permettre d'aboutir à fournir aux registres UDDI des URI qui soient mieux adaptés que ceux qui sont en http://  
Un progrès possible vers le U !
 
Alors que plus de 90 % des données figurant dans une facture proviennent d'un traitement infor-matique, seulement 4 % des factures seraient dématérialisées aujourd'hui en France. Cela, malgré le coût élevé que représente la facture papier, de l'ordre de 8 € à l'émission et le double à la réception.
En tout cas, ce n'est plus depuis 1998 à cause des possibles vérifications fiscales de la DGI qui se contente depuis  lors d'une simple déclaration préalable de la "démat". A la condition naturellement de respecter ses prescriptions d'indexage et d'archivage. Et la directive européenne de fin 2001 n'a pas bouleversé le dispositif français.
Au départ, seules les entreprises "bouclant" leurs échanges en EDI, pouvaient passer à la "démat". Aujourd'hui, il y a d'autres solutions techniques valables, y compris l'e-mail, du moment que la "démat" envoyée par le fournisseur est bien reconnue par le progiciel de gestion du client et que l'archivage est bien identique des deux côtés.
La généralisation de la "démat" viendra donc d'une interopérabilité des ERP ou de l'externalisation à des tiers de confiance (e-billing).
UBL réinvente la roue
avec retour à la case Edifact !
Le groupe d'Oasis mené par Jon Bosak (Sun) vient de publier une première version d'UBL (Universal BusinessLanguage) portant sur les 7 e-transactions les plus courantes, de commande à facture. Cet UBL0p70 comprend les documents papier correspondants, comme ceux de l'ONU : UBL se retrouve ainsi au point de départ  des messages EDI, à savoir le document papier à dématérialiser. Pas facile de trouver une référence dans UBL0p70 à la modélisation ou à la choreography !
Par contre, maintien de l'approche top down d'Edifact où le message INVOIC, par exemple, est l'enveloppe de tous les types de facture imaginables. Là, il y aurait plutôt des Core components avec une déclinaison par contexts. Mais à quoi bon ? La facturation provenant du cœur de métier, les factures spécifiques télécom, distribution, pétrole, hôpital etc. ne seront jamais utilisées par la même entreprise. Alors, autant laisser chaque secteur avoir son schéma spécifique pour son type de facture ! Jon Bosak, éditeur de XML, en
a oublié la nature eXtensible !
                                   Je disjoncte !
Ce numéro 59 de VendrEDI a été adressé à 1051 abonnés      Écrire à
Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com