L'idée d'utiliser des URI pour les namespaces était fruste, à l'origine : il s'agissait simplement de distin-guer, grâce à des URI différents, deux balises de même libellé coexistant dans le même schéma  ou, à l'inverse, d'être certain que, dans deux schémas différents, des balises se réfèrent bien au même concept puisqu'elles ont le même URI. Mais cette URI pour une "balise x" n'était souvent qu'une URL vide du type "xmlns= http://www.balise-x", soit une adresse fictive (d'où l'erreur 404 Not Found quand on cliquait sur une telle URL vide) qui ne pointait donc pas sur un contenu réel, par exemple donnant des informations sur la signification sémantique de la "balise x" en question.

Pour "donner du sens" à ce mécanisme fruste, dès 2001, le langage RDDL, Resource Directory Des-cription Language, a été proposé, pour que le mécanisme des URI de namespaces soit porteur d'informations sur les balises identifiées, grâce à un langage lisible aussi bien par l'homme que par une application. L'URL doit alors pointer non pas simplement sur une page Web ou un schéma XML, mais sur un directory of resources. Basé sur XHTML, donc accessible par les navigateurs, le langage RDDL permet d'avoir accès, sous un même namespace, aux définitions diverses d'un domaine de business. Par exemple le namespace réalisé par Eric van der Vlist pour les données de base de l'INSEE (cf VendrEDI n°75).

La version 2.0 de RDDL a été publiée pour discus-sion au début de l'année avec comme objectif de simplifier encore le langage. Mais Eric van der Vlist, grand promoteur de RDDL, observe dans son Weblog que cette simplification réduit en fait l'intérêt de cette version  par rapport à la précédente. Plus simple oui, mais pas simpliste ! Il est donc souhaitable qu'un consensus se dégage pour un RDDL qui puisse répondre aux attentes : s'il semble impossible de corseter l'usage de XML, encore peut-on essayer de le rendre "lisible". C'est à dire que si une démarche top down du type ebXML ne paraît  pas réaliste pour enregistrer quelque part toute la sémantique des balises des schémas XML, encore faut-il un outil permettant de décrire et lire cette sémantique accessible à  tous grâce aux URI de namespaces.

Le discovery est le maillon faible des Services Web (SW), comme de ebXML, avec de nouveaux parte-naires inconnus.  Si l'on ne voit pas encore de  registres de CPP-CPA ebXML, il y a beaucoup de registres UDDI (Universal Description, Discove-ry & Integration) pour les SW. Mais si on utilise UDDI comme un registre de SW à l'intérieur d'une entreprise ou entre partenaires habituels, on ne peut encore parler de discovery puisqu'on est déjà en terrain bien connu.  Selon la Web Services Archi-tecture  du W3C, le discovery est en effet : "the act of locating a machine-processable descrip-tion of a Web service that may have been previously unknown and that meets certain functional criteria". Qu'il s'agisse d'une découverte humaine ou d'une discovery "entre applications", il faut dans tous les cas, puisque le SW recherché peut être inconnu, que le registre qui le localise et le décrive comporte bien toutes les informations nécessaires pour une mise en oeuvre confiante. Et de fait, en plus du basique "qui assure tel SW et comment ?", les registres UDDI peuvent comporter de nombreuses informations permettant de décou-vrir, et ensuite aussi "suivre" la fourniture d'un SW. Voir la spécification de UDDI v3, très complète et comportant de nombreuses fonction-nalités comme les relations entre registres et les clés identifiant un service (cf VendrEDI n°59), ou la signature électronique des offreurs de services pour authentifier ainsi leur catalogue. Voir une note résumée dont les éditeurs sont de Microsoft et Sun ;-) sur la UDDI Version 3 Features List.

De plus, une  note technique d'Oasis montre ce que l'on peut attendre d'une utilisation de WSDL (qui décrit un SW) dans un registre UDDI : par exemple, la qualité ou le versioning d'un SW donnant aux offreurs de SW l'assurance que UDDI sera bien à même d'exposer toute la spécificité et l'évolution de leurs prestations. D'autres notes techniques pour-raient, par exemple, proposer l'enregistrement des access permissions à chaque SW, car c'est bien la question de la sécurité qui sera déterminante pour que les entreprises développent des SW pouvant être "exposés" et "découverts" par tous.

Mais si on imagine bien la "découverte" de SW basiques, cours de Bourse ou catalogues de produits à jour, la discovery de SW complexes d'e-business ne paraît pas encore proche : comme au temps de l'EDI, il faudra bien se mettre autour d'une table avant de lancer du applica-tion to application automatisé.