new Blog( perso );

Quand on manipule des services web, des schémas XSD et des louches entières de XML, on rencontre des développeurs qui sont complètement perdus dans les concepts de namespaces. Une idée trop largement répandue est que le namespace donne l'emplacement du schéma considéré, idée basée sur l'utilisation courante d'URL pour définir ces namespaces, lesquelles pointent effectivement assez souvent sur le schéma considéré.

Petit rappel donc.

En XML, les namespaces permettent de mixer plusieurs grammaires dans un même document, on associe donc un identifie chaque grammaire (schéma XSD) un namespace, auquel on associe un préfixe utilisé dans les balises du document XML.

Le namespace est un identifiant de la grammaire XSD. Techniquement parlant, c'est une URI, soit un identifiant unique répondant à des contraintes assez simple, mais en aucun cas un lien pour la consulter.

Une URI (Uniform Resource Identifier [FR]) est juste un formalisme commun pour l'écriture d'identifiants portables. La principale chose à en retenir est qu'elle commencent pas "préfixe:", ce que la norme appelle le 'scheme" -- "programme" , ou "plan", d'après google translate, parfois traduit par nom de shéma, mais alors on peut confondre avec le schéma XSD ...

Les URL (Uniform Resource Locator) sont une forme particulière d'URI qui permettent de définir une localisation pour une ressource (les fameux liens hypertexte du web). On PEUT donc les utiliser comme identifiant pour les namespace XML, et c'est d'ailleurs pratique pour faciliter la vie des développeurs si ce lien pointe en effet vers le schéma XSD, seulement rien ne l'impose.

Une autre option, ce sont les URN (Uniform Resource Name), une autre variante des URI qui permettent de définir un nom, et non un emplacement, qui par définition peut changer.

Que choisir ?

L'intérêt apparent des URL comme namespace introduit une incompréhension qui n'est pas bénéfique. Par ailleurs, le risque de voir l'URL ne plus pointer vers le schéma pour X raison (changement d'hébergement, changement de nom de domaine ...) est perturbant.

Les URN sont a priori plus adaptées, mais pas très courantes. Il est pourtant plus sain de définir un schéma comme
  urn:schema:monprojet.org:Domaine/1.0
que comme
  http://monhebergementpourlemoment.free.fr/xsd/Domaine_1.0.xsd

Pour aider le développeur (via son éditeur XML préféré) il suffit d'exploiter le mécanisme de localisation des schémas lui aussi prévu par la norme :


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schema:monprojet.org:Domaine/1.0
                    http://qqpart.org/xsd/Domaine_1.0.xsd"

Vous noterez en passant que les namespaces choisis pour les normes XML sont des URL, ce qui participe très activement à la confusion...


Pas convaincu ? lisez cette (traduction de la) note officielle du W3C : http://www.yoyodesign.org/doc/w3c/uri-clarification/

Java 5 apporte son lot de nouveautés, entre autre l'autoBoxing. Sauf qu'il ne s'agit pas d'une évolution au sein de la JVM mais uniquement au niveau de la syntaxe et du compilateur, donc écrire :

Double d = ...;
truc.setValue( d ); // signature : public void setValue( double );

se traduit (en pseudo-code) dans le .class compilé par

Double d = ...;
truc.setValue( d.doubleValue() );

Je serais le 11 mai au ParisJug pour présenter en compagnie de mon Arnaud Héritier préféré une synthèse rapide des nouveautés de Maven 3. Rapide parce que le ParisJug ne nous laisse que 30 minutes, aussi nous avons choisi pour notre sujet une formule ... inhabituelle.

Si vous avez aimé le bouquin, le ton que nous allons (essayer de) donner à cette intervention devrait vous plaire. Et pour ceux qui ne peuvent se contenter de 30 minutes, un petit détour par la troisième mi-temps devra combler ce manque.

Infos, inscriptions, et toute ce genre de choses sur ParisJug.org.

Depuis quelques années, je travaille à mettre en place des outils de "forge logicielle", mutualisés ou dédiés à un projet; voici les outils que j'aimerai assembler pour fournir un environnement clé en main sur projet :

• une machine dédiée (ou une VM) sous Ubuntu, système facile à installer, bien documenté. Le passage sur un Linux permet déjà de tester toutes les problématiques d'encodage de caractères et de séparateurs de fichiers;
• un SVN, un Git ou Mercurial, selon les goûts; 
• un Nexus pour la conservation des artefacts et l'économie de bande passante;
• un serveur Hudson, qui s'installe via un paquet DEB que c'est tellement simple que ça fait pleurer;
• un build Maven (sans blague ?);
• idéalement, une conf magique pour que le build n'ait pas accès au Net, par exemple via http.proxyHost. L'idée est d'empêcher le parser XML de récupérer les schémas XSD sur le Net - si, ça arrive !
• un serveur de démo/test/perfs, sur lequel la dernière version NIGHTLY est déployée automagiquement;
• un job dédié pour alimenter un Sonar en build nocturne; Je préfère prendre Sonar avec sa conf par défaut puis voir ce qui en émerge et comment ça évolue, pour voir là où l'équipe doit progresser et réduire la gravité des règles qu'elle considère inutiles APRES les avoir violées trop régulièrement (au moins, on s'est posé la question). En général, les indicateurs de complexité s'envolent rapidement ;)
• un wiki projet, j'aime bien xWiki qui est puissant et colle bien dans cette forge "tout java". Les plugins Eclipse et Office (pas testé) peuvent aussi aider à faire apprécier le principe du Wiki même aux plus classiques d'entre nous;
• un gestionnaire de tâches/bugs. Sauf à avoir un JIRA en centralisé, il peut être intéressant de le conserver sur la machine projet avec le reste et de gérer les sauvegardes d'ensemble de la forge. Je n'ai pas de préférence faute d'avoir pu tester autre chose que cette bouze de Quality Center;
• pourquoi pas un serveur iceScrum pour ceux qui pratiquent;
• un outil de revue de code, dans l'esprit de Crubicle, et dans l'idéal intégré à l'IDE... je n'ai pour l'instant rien trouvé;
• un environnement de dev prêt à installer. Pour l'instant je fais un gros ZIP d'Eclipse + JDK + Maven + Tomcat + ... mais c'est pas le top, surtout pour gérer les mises à jour.

Je suis sûr qu'il manque plein de briques intéressantes à rajouter à cette wishlist, j'attend vos suggestions ;)